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?"
I think there's even a law for this kind of reply...
The big worry is not building from source, but builds delivered by companies like Ubuntu, which you have absolutely no guarantee are actually built from the same source that they publish. Ditto Microsquishy, iOS, Android, et. al.
The big concern is back doors built into distributed binaries.
I do not fail; I succeed at finding out what does not work.
You can sleep soundly if your computer is off and/or unplugged. Otherwise, you should always be on your guard.
Keep your confidential data behind multiple levels of protection, and preferentially disconnected when you are not using it. Never trust anything that is marketed at 100% safe. There will always be bugs to be exploited, if nothing else.
A healthy level of paranoia is the best security tool...
morcego
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..."
There was recently a bit of a kerfuffle over RdRand.
Matt Mackall, kernel hacker and Mercurial lead dev, quit Linux development two years ago because Linus insulted him repeatedly. Linus called Matt a paranoid idiot because Matt would not allow RdRand into the kernel, because it was an Intel CPU instruction for random numbers that could not be audited. Linus thought Matt's paranoia was unwarranted and wanted RdRand due to improved performance. Recently Theodore T'so has undone most of the damage, but call RdRand still exist in Linux. I do not understand exactly if there are lingering issues or not.
The last time that the NSA weakened an algorithm they recommended was by shortening the key for DES. Snowden confirms that properly implemented crypto still works, and Rijndael (AES) still seems strong. The problem aren't the algorithms, because the mathematics still check out. The thing to fear are the implementations. Any implementation for which we are not free to inspect its source is suspect.
It's possible the NSA did something bad to the code, but it's not likely and it won't last.
For the "not likely" part, code accepted into Linux projects tends to be reviewed. The NSA can't be too obvious about any backdoors or holes they try to put in, or at least one of the reviewers is going to go "Hey, WTF is this? That's not right. Fix it.". and the change will be rejected. That's even more true with the kernel itself where changes go through multiple levels of review before being accepted and the people doing the reviewing pretty much know their stuff. My bet would be that the only thing that might get through would be subtle and exotic modifications to the crypto algorithms themselves to render them less secure than they ought to be.
And that brings us to the "not going to last" part. Now that the NSA's trickery is known, the crypto experts are going to be looking at crypto implementations. And all the source code for Linux projects is right there to look at. If a weakness were introduced, it's going to be visible to the experts and it'll get fixed.
That leaves only the standard external points of attack: the NSA getting CAs to issue it valid certificates with false subjects so they can impersonate sites and servers, encryption standards that permit "null" (no encryption) as a valid encryption option allowing the NSA to tweak servers to disable encryption entirely, that sort of thing. There's no technical solution to those, but they're easier to monitor for.
Every encryption protocol you use has been sabotaged to be readable by them. You dont really think they will try 200 trillion keys to break your stream do you?
No. They modified the protocols, (to make them more secure) and of course never explained the changes. They just mandated it.
Even the almighty NSA with it's insanely high budget can't crack all the encryption. But it does make me wonder if I should avoid everything they recommend.
I suspect the NSA has developed custom hardware for the more common encryption types. Custom hardware was shown to work extremely well on DES by deep crack. http://en.wikipedia.org/wiki/EFF_DES_cracker
The big concern is back doors built into distributed binaries.
And what about the hardware? And how can you be sure the compilers aren't putting a little something extra into the binaries. There are so many places for NSA malware to hide it's scary. Could be in the BIOS, could be in the keyboard or graphics firmware, could be in the kernel placed there by a malicious compiler. Could be added to the kernel if some other trojan horse is allowed to run. And just because the kernel, etc. are open source doesn't mean they have perfect security. The operating system is incredibly complex, and all it takes is one flaw in one piece of code with root privileges (or without if a local privilege escalation vulnerability exists anywhere on the system, which it surely does), and that can be exploited to deliver a payload into the kernel (or BIOS, or something else). Really, if the NSA wants to see what you're doing on your Linux system, rest assured, they can.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
The last time that the NSA weakened an algorithm they recommended was by shortening the key for DES.
Minor correction: They strengthened the DES algorithm by substituting a new set of S-boxes which protected against an attack that wasn't publicly known at the time. They shortened the key space which made it more susceptible to brute forcing the key. Full strength DES has held up very well against attacks overall until its key length became a problem. It lasted much longer in use than intended.
I seem to recall that DES was never approved for protecting classified data, but that AES does have that approval.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
if the whole world goes for one cipher, then nsa can concentrate on creating and improving a single ASIC design for breaking it. we should be using hundreds of different algorithms. then they'd have to design hundreds of types of ASICs, build 100x more datacentres, increase taxation in USofA to 10x what it is now, yanks would rebel and overthrow that government and then there would be no more evil NSA. simples
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.
I believe you can trust OpenBSD totally but it lacks many of the features and much of the convenience of the main Linux distros. It is rock solid and utterly secure though, and the man pages are actually better than any Linux distro I've ever seen.
Three points:
1) See the above discussion: you cannot trust anything that you did not create and compile yourself. With a compiler you wrote yourself. On a machine you created yourself from the ground up, that is not connected to any network in any way. OpenBSD does not make any difference if your compiler or toolchain is compromised.
2) Speaking of which, I cannot but note that OpenBSD had a little kerfuffle a while back, about a backdoot planted by the FBI in the OS? (Source 1) (Source 2). I am willing to bet that (a) it's perfectly possible (though not likely), (b) if it was done, it was not by the FBI and (c) that the dev @openbsd.org are, right now, taking another long and hard look at the incriminated code.
3) Finally OpenBSD lacking features and convenience? Care to support that statement? I have a couple of computers running OpenBSD here, and they are just as nice - or even nicer - to use than any Linux. Besides, you don't choose OpenBSD for convenience - you use it for its security. Period.
The possibly bigger problem is that no matter what OS you use you can't trust SSL's broken certificate system either because the public certificate authorities are corruptible. And before someone says create your own CA, sure, for internal sites, but you can't do that for someone else's website.
This goes way beyond a simple question of OpenSSL certificates - think OpenSSH and VPN security being compromised, and you will have a small idea of the sh*tstorm brewing right now.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Is there any particular reason why people don't strengthen AES (or any other symmetric encryption) by just reencrypting 1000 times? Perhaps interleaving each encryption with encrypting with the first 1, then 2 etc. It would make next to no difference for the end user, who's going to decrypt just once, but I imagine it would add a lot more time to the cracking of the encrypted data than increasing the size of the key.
Exponents are actually what protects information, multiplication just makes people feel good.
We are being told - and some of us suspected as much for a very long time - that the NSA &Co track everything we do, and have the ability de-encrypt much of what we think is secure; whether through brute force, exploits, backdoors, or corporate collusion.
Surely we should also assume that there are other criminal and/or hacker groups with the resources or skills to gain similar access? Another case of "once they know it can be done, you can't turn back."
I honestly believe that we're finally at the point where the reasonable assumption is that nothing is secure, and that you should act accordingly.
Three Squirrels
One Bruce Schneier is a (loud) advocate for increasing the number of rounds in AES. Currently it's set at 16, and he advocates increasing it to much more. His main reason for this is that there's a differential crypto-analysis attack against known plaintext data encrypted with reduced rounds AES implementations. In short: If you know or control some of the encrypted data, you can extract bits of the key by comparing changes between encrypted known data. The bits you gain reduce the keyspace you need to search. AES according to the guidelines isn't vulnerable for this. Yet.
I think that depends on what keeps you up at night.
In one of the earlier stories today there was a post making all sorts of claims about compromised software, bad actors, and pointing to this paper: A Cryptographic Evaluation of IPsec. I wonder if anyone bothered to read it?
IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result. We are not alone in this opinion; from various discussions with the people involved, we learned that virtually nobody is satised with the process or the result. The development of IPsec seems to have been burdened by the committee process that it was forced to use, and it shows in the results. Even with all the serious critisisms that we have on IPsec, it is probably the best IP security protocol available at the moment. We have looked at other, functionally similar, protocols in the past (including PPTP [SM98, SM99]) in much the same manner as we have looked at IPsec. None of these protocols come anywhere near their target, but the others manage to miss the mark by a wider margin than IPsec.
I even saw calls for the equivalent of mole hunts in the opens source software world. What could possibly go wrong?
Criminals, vandals, and spies have been targeting computers for a very long time. Various types of security problems have been known for 40 years or more, yet they either persist or are reimplemented in interesting new ways with new systems. People make a lot of mistakes in writing software, and managing their systems and sites, and yet the internet overall works reasonably well. Of course it still has boatloads of problems, including both security and privacy issues.
Frankly I think you have much more to worry about from unpatched buggy software, poor configuration, unmonitored logs, lack of firewalls, crackers or vandals, and the usual problems sites have than from a US national intelligence agency. That is assuming you and 10 of your closes friends from Afghanistan aren't planning to plant bombs in shopping malls, or try to steal the blueprints for the new antitank missiles. Something to keep in mind is that their resources are limited, and they have more important things to do unless you make yourself important for them to look at. If you make yourself important for them to look, a "secure" computer won't stop them. You should probably worry more about ordinary criminal hackers, vandals, and automated probe / hack attacks.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
Yes, it's "pretty safe". It's not absolutely safe or guaranteed to be safe. But if your other alternative is a hidden-source OS, especially one in US jurisdiction, then OSS is "pretty safe."
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
10000 laptops are stolen at airports every year. Presumably, they are off when that happens.
The NSA is not your problem; you are not important enough to be a target. When thinking about security, thieves are your problem. Theft happens, and happens often. Your computer is far more likely to get stolen than to be inflitrated by the NSA. And the solution is to encrypt your hard drive. Without encryption the thief will have access to everything you normally access from the computer - like your bank account. You wouldn't want that, would you? Today's CPUs all have AESNI support, so there is no excuse for not encrypting your laptop's hard drive. Do it today and get some financial peace of mind.
they destroyed my trust in anything, i dont trust any operating system and software anymore, i dont trust the internet or any encryption method, the US Govt and all its elements have been proven to be a criminal gang of fascist kleptocratic totalitarian warmongering pigs.
Politics is Treachery, Religion is Brainwashing
Pick a government. If you trust the Russians use GOST. If you trust the Japanese use CAMILLA.
Then use all three of them in sequence and hope it would be quite difficult to have them all cooperate to break your encryption.
you are not important enough to be a target.
Wrong. You may become important in the future. So you are important enough to target. They are collecting data on everyone, and holding on to it. They just might not be actively going through all the data from everyone (or they might be, if they have enough computing power). But if it's recorded it doesn't really matter if they do it today or in 20 years. They've got you. "If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him." --Richelieu
Seven puppies were harmed during the making of this post.
I'd like to find a more recent report of what they found.
For the Linux kernel, that's how development is done already, for quality control and bloat reduction. Nobody can commit by themselves, it takes at least three people to get a change into mainline. Each developer has their own copy of the tree into which changes are pulled, so they can see all changes that are made, and who made them.
For each part of the kernel, there are a number of people particularly interested in that bit who watch it and work on it. For example, the people making NAS and SAN devices and services keep a close eye on the storage subsystems. Myself, I watch the cm storage stack generally, more specifically LVM, and even more specifically snapshots. There are a few dozen people around the world with special interest in that particular part of the code. No backdoors will come in without some of us spotting it. What COULD happen is that some code could come in that isn't quite as secure as it could be.
It just so happens that I'm a security professional who uses advanced Linux storage systems for a security product called Clonebox, so that's at least one security professional closely watching that part of the code. Thousands of others watch the other parts.
It's convenient that a lot of the development is done by companies like Netapp, Amazon (S3) and Google. You can bet that when Amazon submits code, Netapp and Google are looking closely at it. When RedHat submits something, Canonical will point out any reasons it shouldn't be accepted.
Digitial Forensics for Prosecutors presentation suggests Truecrypt has a backdoor.
http://www.techarp.com/showarticle.aspx?artno=770&pgno=0
The entire link inadvertently explains why cloud storage shouldn't be used, and that mobile devices are your worst enemy.
The only mention of TrueCrypt is this sentence:
"Currently available for major software - Microsoft bitlocker,
FileVault, BestCrypt, TrueCrypt, Etc" (sic)
It does have these gems
"The Patriot Act allows for the use of backdoors for counter terrorist investigations"
The use of backdoors cannot be detected or proven.
Vendors are legally and commercially prevented from acknowledging their backdoors.
Defense will not be able to prove their existence.
The files can be described as "forensically obtained"
Users of mobile devices and cloud storage sign off on their rights to data scanning.
There is no opt our option.
Lots more...
PDF can be downloaded here:
http://www.techarp.com/article/LEA/Encryption_Backdoor/Computer_Forensics_for_Prosecutors_(2013)_Part_1.pdf