kerneltrap.org/node/view/1584
The CVS logs erroneously credited kernel hacker David Miller for the changes. Examining the two lines of inserted code a little closer, it became quite apparent that this was a blatent attempt to insert a back door into the Linux kernel that could have been used to illegitimately become the root superuser on a Linux server. Andreas Dilger pointed out that had the change gone undetected it might have taken a good while to find . Linux creator Linus Torvalds was quick to point out that the distributed design of BitKeeper helps to make it a fairly secure solution. In describing the reasons why, he said, One of them is that if somebody were to actually access the BK trees directly, that would be noticed immediately: when I push to the places I export from, the push itself would fail due to having an unexpected changeset in the target that I dont have on my local tree. He went on to add, I think its telling that it was the CVS tree and not the BK tree that somebody tried to corrupt. Larry then explained how the BitKeeper-to-CVS gateway is designed to prevent accidental or intentional modifications. He described a four step process that includes making an internal duplicate of the CVS tree and running a checksum on all modified files to compare and verify. He adds, Its worth mentioning that it would be close to impossible to add the same change to BK unnoticed. Its possible but the accountability would be a lot better and the bad user could be tarred and feathered. He went on to suggest that a new feature of allowing one to sign changesets with GPG will be added soon, so that you can at least be assured that all the stuff in BK is either flagged trusted or untrusted.
Dave looked at the machine and it looked like someone may have been trying to break in and do it. Weve fixed the file in question, the conversion is done back here at BitMover and after we transfer the files we check them and make sure they are OK and this file got flagged. The CVS tree is fine, you might want to remove and update exitc to make sure you have the current version in your tree however. The problem file is kernel/exitc which has a few extra entries like so: revision 1121 date: 2003/11/04 16:44:19;
The retval is dead code because of the next line, but it looks like an attempt to backdoor the kernel, does it not? From: Larry McVoy email blocked Subject: Re: BK2CVS problem Date: Wed, 5 Nov 2003 15:03:50 -0800 > Setting current->uid to zero when options __WCLONE and __WALL are set? The > retval is dead code because of the next line, but it looks like an attempt > to backdoor the kernel, does it not? This function is sys_wait4 so by passing in __WCLONE__WALL you are root.
One of them is that if somebody were to actually access the BK trees directly, that would be noticed immediately: when I push to the places I export from, the push itself would fail due to having an unexpected changeset in the target that I dont have on my local tree. And thats likely to be true of all other BK users too: the public trees are just replicas of the trees people actually _work_ on, so if the public tree has something unexpected, trying to update them just wont work. You just cant push to a tree that isnt a subset of what you already have. So any BK corruption would have to come from the private trees, not the public ones. Which tend to be better secured, exactly because they are private ie they dont have things like cvspserver etc public servers. I suspect most of us have firewalls that just dont accept any incoming connections - I know I do. I think its telling that it was the CVS tree and not the BK tree that somebody tried to corrupt. Linus From: Larry McVoy email blocked Subject: Re: BK2CVS problem Date: Wed, 5 Nov 2003 19:01:25 -0800 On Wed, Nov 05, 2003 at 06:57:13PM -0700, Andreas Dilger wrote: > First of all, thanks Larry for detecting this. Your paranoia that made > you add extra checks on the export of data also evident in the BK > checksums everywhere probably saved Linux as a whole a lot of grief. Thanks for noticing that, it makes the extra work worth it, it really does.
Ive verified 30 seconds ago that the change is not in in Linus BK tree. We run these comparisons every night and Im going to increase that after we reinstall the machine. So I noticed this this morning and had the tree fixed this afternoon; I suppose people could complain that it should have been sooner but I was running tests to make sure it was not some problem in the BK2CVS exporter code. Even with the delay, the problem was identified and corrected in less than 24 hours. That doesnt leave a lot of time to have the problem get into the real release tree.
I couldnt agree more, weve thought about this and have a design, but credit where credit is due, Ted Tso is the driving force behind this idea. He and I have had long discussions about this and we have a plan to do exactly that in BK. Ive already told Linus that we can add that to BK, and will, in the free version, so that you can at least be assured that all the stuff in BK is either flagged trusted or untrusted. We think that is an excellent idea, we want to do it, but we were waiting for some event to trigger it. Weve been berated publicaly for each and every change weve made to the free version of BK so now we wait for people to ask for changes and then well make them.
|
http://csua.com/feed/