Slashdot Mirror
Ask Slashdot: Linux Security, In Light of NSA Crypto-Subverting Attacks?
New submitter deepdive writes "I have a basic question: What is the privacy/security health of the Linux kernel (and indeed other FOSS OSes) given all the recent stories about the NSA going in and deliberately subverting various parts of the privacy/security sub-systems? Basically, can one still sleep soundly thinking that the most recent latest/greatest Ubuntu/OpenSUSE/what-have-you distro she/he downloaded is still pretty safe?"
You can not add security, later.
In Unix systems, there’s a program named “login“. login is the code that takes your username and password, verifies that the password you gave is the correct one for the username you gave, and if so, logs you in to the system.
For debugging purposes, Thompson put a back-door into “login”. The way he did it was by modifying the C compiler. He took the code pattern for password verification, and embedded it into the C compiler, so that when it saw that pattern, it would actually generate code
that accepted either the correct password for the username, or Thompson’s special debugging password. In pseudo-Python:
def compile(code):
if (looksLikeLoginCode(code)):
generateLoginWithBackDoor()
else:
compileNormally(code)
With that in the C compiler, any time that anyone compiles login,
the code generated by the compiler will include Ritchie’s back door.
Now comes the really clever part. Obviously, if anyone saw code like what’s in that
example, they’d throw a fit. That’s insanely insecure, and any manager who saw that would immediately demand that it be removed. So, how can you keep the back door, but get rid of the danger of someone noticing it in the source code for the C compiler? You hack the C compiler itself:
def compile(code):
if (looksLikeLoginCode(code)):
generateLoginWithBackDoor(code)
elif (looksLikeCompilerCode(code)):
generateCompilerWithBackDoorDetection(code)
else:
compileNormally(code)
What happens here is that you modify the C compiler code so that when it compiles itelf, it inserts the back-door code. So now when the C compiler compiles login, it will insert the back door code; and when it compiles
the C compiler, it will insert the code that inserts the code into both login and the C compiler.
Now, you compile the C compiler with itself – getting a C compiler that includes the back-door generation code explicitly. Then you delete the back-door code from the C compiler source. But it’s in the binary. So when you use that binary to produce a new version of the compiler from the source, it will insert the back-door code into
the new version.
So you’ve now got a C compiler that inserts back-door code when it compiles itself – and that code appears nowhere in the source code of the compiler. It did exist in the code at one point – but then it got deleted. But because the C compiler is written in C, and always compiled with itself, that means thats each successive new version of the C compiler will pass along the back-door – and it will continue to appear in both login and in the C compiler, without any trace in the source code of either.
http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/
"Flyin' in just a sweet place,
Never been known to fail..."
No, but there's no reason to think that Linux is worse than anything else, and it's probably easier to fix.
If I were Linus I'd be putting together a small team of people who have been with Linux for years to begin assessing things. From Gilmour's posting it seems clear that IPsec and VPN functionality will need major change. Other things to audit include crypto libraries, both in Linux and the browsers, and the random number generators.
But certainly some examination of SELinux and other portions are also needed.
I don't see how anyone can answer the original question without doing some serious assessment. However I'm a bit skpetical whether this problem can actually be fixed at all. We don't know what things have been subverted, and what level of access the NSA and their equivalents in other countries have had to be code and algorithm design. They probably have access to more resources than the Linux community does.
Backdooring a CPU wouldn't actually be that difficult. You'd need it to recognise a specific command sequence (128-bits long should do it) when reading memory to trigger the backdoor - that way you could activate it by sending a network packet, or reading external media, or routing traffic. And all the backdoor needs to do is run a simple 'set instruction pointer to immediately after this trigger.' It'd be impossible to defend against short of using an un-backdoored CPU to filter the trigger out, and even then it could be snuck through in an SSL session or a fragmented packet.
And best of all, it would *never* be detected. The schematics for a CPU are practically impossible to reverse-engineer from the masks, and both schematics and masks are strictly internal company property. Plus the number of people who could understand them in enough detail to spot a backdoor without years of specialist study could probably fit in one conference hall.
One of our advanatages is that I'm sure the Russians don't want NSA backdoors in Linux, and the NSA doesn't want Russian backdoors in Linux and neither want Chinese Backdoors and simalarly the Chinese want neither NSA or Russian backdoors. After all of this "Spy vs. Spy" Linux is unlikely to have backdoors. If your requirements are great enough that unlikely isn't good enough your probably shit outa luck because nothing will be good enough for you.
Apocalypse Cancelled, Sorry, No Ticket Refunds
I'd like to find a more recent report of what they found.