[GUFSC] Linux: Kernel "Back Door" Attempt

[Rafael R Obelheiro]

[http://kerneltrap.org/node/view/1584]

Linux: Kernel "Back Door" Attempt
Posted by jeremy on Wednesday, November 5, 2003 - 23:54

In a post earlier today to the Linux kernel mailing list, BitMover
founder Larry McVoy [interview] commented, "Somebody has modified the
CVS tree on kernel.bkbits.net directly. Dave looked at the machine and
it looked like someone may have been trying to break in and do it."
The modified file was 'kernel/exit.c', modified directly on the CVS
mirror of the 2.6-test development kernel tree [forum]. 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 don't have on my local tree." He went on to add, "I
think it's 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, "It's worth mentioning that it would be close to
impossible to add the same change to BK unnoticed. It's 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."

[...]