Thwarted Linux backdoor hints at smarter hacks (2003)

http://www.securityfocus.com/news/7388

by mikevm • 13 years ago

85 52 13 years ago

jgrahamc• 13 years ago

Here's the actual code: http://lwn.net/Articles/57135/ Made use of the difference between == and = in C.

This was done by going around the normal channels to get code into the kernel. Someone attacked the CVS server directly and modified the code: http://lkml.indiana.edu/hypermail/linux/kernel/0311.0/0621.h...

JoachimS• 13 years ago

Was the culprit found and outed?

brudgers• 13 years ago

That the attack came through the CVS server shows how far down the stack vulnerabilities could be exploited - had the attacker compromised the CVS first, this exploit might not have been caught so easily...or... Wouldn't subverting Subversion impact the success of subsequent subterfuge substantially?

njharman• 13 years ago

I don't think that is easily overlooked. Maybe, if there had only been one conditional, but the different '==' and '=' are jarring to me.

OTOH, I'm a pretty slow code reader and look at "pattern" and "flow" of code at least as much as I attempt to understand meaning. Probably why I'm so anal about style, indentation, and vertical white space.

snicklepuff• 13 years ago

This is why they use git - subversively inserting code into git is not possible like it is with CVS

kamjam• 13 years ago

Except the article is from 2003 when Git did not exist (of course, you may have meant this is why they use git now...)

whateverdude• 13 years ago

If I recall correctly, this particular backdoor was put in place by an eastern european guy going by the nick sky- in #phrack on the Eris Free Network. He killed a very valuable zeroday exploit in the process, causing both grief and anger among fellow hackers. Good times, though.

harrytuttle9• 13 years ago

And this is why you write it like this when you use C:

   (0 == current->uid)

Rather than

   (current->uid == 0) // or (current->uid = 0) in this case.

Impossible to make an assignment to a numeric lvalue. Easy to spot, easy to audit in a diff.

Fuxy• 13 years ago

Good point i always wondered why people write it like that it makes it harder to read.

mikevm• 13 years ago

Makes one appreciate languages like Pascal which differentiate between the equality operator '=' and the assignment operator ':='.

I wonder why the decision was made in C to use '=' and '=='? I'm betting it has something to do with the laziness of the programmers :).

dchest• 13 years ago

The problem is not in == vs =, it's in allowing assignment as an expression. Go fixes this, for example, by now allowing them: if a = 0 {} gives compile error.

James_Duval• 13 years ago

Thanks for this.

I don't actually use C, although I know a few languages with C-like syntax (Java, JS, AS2.0) and I'm learning Go & planning to learn D.

This small change will be really helpful in all these languages. Even if I never make this error again it will help stop people who alter my code from making this error.

Perhaps they should teach it in more programming textbooks, as I've not come across it in anything from HeadFirst to online tutorials to Deitel & Deitel.

zwp• 13 years ago

FYI, sometimes called "Yoda condition". I _think_ I was taught to do this when I learnt C (~20 years ago). Wikipedia indicates that the name at least has been around since 2005.

hyperpape• 13 years ago

It's not necessary in Java (though it's still a common habit). Assignment to a non-boolean is impossible in an if statement in Java, and you can make the compiler warn you about accidental assignments.

eksith• 13 years ago

This is the same procedure (or rather should be) in PHP. Also, better to switch to === or !== for exact comparisons since that also checks type.

(I'll leave out the other warts of PHP since that's been discussed here and elsewhere ad nauseum)

bello2• 13 years ago

Please don't do that...

ndr• 13 years ago

That what? Why not?

konst13• 13 years ago

You don't do that because it makes the code less readable. If you codebase is really big you have to read the code all the time and it takes more brain power to translate your version. Also gcc has a warning vor assignments in if, which are imho a bad habit.

huhtenberg3• 13 years ago

And this is why you write it like this when you use C:

Sure, if you are in habit of releasing code that compiles with warnings.

This sort of pointless code twisting is intensely annoying. It solves a rare problem with a wrong tool and in a very intrusive way.

Zero is constant. You compare to it.

harrytuttle9• 13 years ago

Huh?

   $ cat test.c
   int main(int argc, char *argv[]) {
       if (0 == argc)
           return 1;
       return 0;
   }
   $ CFLAGS="-Wall -ansi -pedantic" make test
   cc -Wall -ansi -pedantic    test.c   -o test

Nope, no warnings there.

colanderman• 13 years ago

Or run a linter or static checker which disallows assignments in conditionals as part of your build and/or checkin process. They'll catch this and other fun C "gotchas" without relying on human vigilance.

harrytuttle9• 13 years ago

That's the failsafe (one I believe heavily in as well). But getting it right up front is still the best approach.

liopleurodon• 13 years ago

I see what you're saying, but (0 == current->uid) still makes my eyes bleed

harrytuttle9• 13 years ago

I agree with you, but it works and it's saved me hours and hours of crying in front of gdb.

hamidpalo• 13 years ago

Not familiar with Linux kernel development practices, but wouldn't have any semi-capable static analysis tool caught this?

icebraining• 13 years ago

Yes, nowadays gcc warns you about assignments in conditionals if you enabled it (e.g. with -Wall). But it probably didn't in 2003.

alextingle• 13 years ago

This assignment is wrapped in parentheses. GCC will not issue a warning.

DanBC• 13 years ago

wouldn't have any semi-capable static analysis tool caught this?

Using tools to find "errors" can be problematic. see, for example, the Debian random number bug. (https://www.schneier.com/blog/archives/2008/05/random_number...)

These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL.

bladurga• 13 years ago

Original thread: http://marc.info/?t=106806555100004&r=1&w=2

balabaster2• 13 years ago

Great to see that this has devolved into a religious argument about code syntax... well done the pedantic few, but you guys are missing the bigger picture

Like:

1). Have there been any other backdoors surreptitiously slipped in that nobody has noticed?

2). Is Linux Kernel really as secure as everyone thinks it is?

I'd spend more time scouring the code looking for other backdoors and securing those than worrying about a holy war on the merits of Yoda Comparisons [Which by the way I think suck. Use a compiler that errors out or warns on assignment found where comparison is expected, code is meant to be human readable, so make it so.]

The joy about Linux being open source is that you can get your fingers and minds in the code and even if Torvalds had put in a back door at the behest of some government entity or other, it wouldn't matter - you guys have the power (and ability) to close that door. So if I were you, I'd spend more time doing that and less time bitching about other coders' syntax preferences that may not match your own.

drzaiusapelord• 13 years ago

Linus doesn't have to put government collusion in the source. Look how he strong-armed using the hardware Intel RNG recently. That's microcode you'll never see. Is this collusion? Who knows, but trusting hardware makes code reviews useless.

lasermike026• 13 years ago

Correct me if I'm wrong but /dev/random gathers entropy from a number of sources including CPU RNG. If your CPU was owned it wouldn't matter. I run entropy gathering daemons especially for virtualized systems. VMs don't have enough hardware entropy and software like vpn clients will get stuck waiting for data from /dev/random.

There are a number of ways to add entropy. I've used egd and haveged. Use them. It can't hurt.

I suppose you could not load microcode on boot. I've never tried.

balabaster2• 13 years ago

Yes but the code is open, you could easily remove that block of code from the kernel locally and recompile... or fork and not allow anything that you can't verify in your own fork. Just because Linus strong-armed it in to the general release kernel, doesn't mean you're required to use it. What we need I think is an open source hardware RNG made by a company that's dedicated to open source principles.

Thwarted Linux backdoor hints at smarter hacks (2003)

Related Stories