LINUX - IS IT SECURE ?

 https://www.linux-magazine.com/Online/News/Linus-Says-No-Backdoor-in-Linux

Brief dust-up in the kernel community leads to an illuminating look at random number generation.

After the Snowden documents revealed that the NSA deliberately incorporates bugs into encryption software and hardware systems, some users and cryptography experts are taking a closer look at algorithms and processor instructions for generating random numbers.
Rdrand is an instruction for Ivy Bridge processors that returns a hardware-generated random value. According to Intel, the random number generator is compliant with the standards NIST SP800-90, FIPS 140-2, and ANSI X9.82 . Some experts speculate that NIST SP800-90 might contain a backdoor. Dual_EC_DRBG, one of the algorithms used by NIST SP800-90, is based on Elliptic Curve Cryptography and is three times slower than other alternative approaches. At the Crypto conference in August 2007, Dan Shumow and Niels Ferguson voiced allegations that the algorithm contains weaknesses that could be described as backdoors.

Kyle Condon from the UK filed a petition with Change.org to remove the support of Rdrand from the kernel. The petition states, "Please remove RdRand from /dev/random, to improve the overall security of the linux kernel."

However, the real story is a bit more complicated. Ted Ts’o announced last week on Google Plus that he was glad not to have given in to pressure from Intel. Intel had requested that the random number generation of /dev/random should rely exclusively on Rdrand, but Ts’o refused. Linus Torvald's answer to the petition follows his characteristic negative tone, stating the random number generation in the kernel does not depend on Rdrand alone:

"Where do I start a petition to raise the IQ and kernel knowledge of people? Guys, go read drivers/char/random.c. Then, learn about cryptography. Finally, come back here and admit to the world that you were wrong. Short answer: we actually know what we are doing. You don't. Long answer: we use Rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if Rdrand were to be back-doored by the NSA, our use of Rdrand actually improves the quality of the random numbers you get from /dev/random. Really short answer: you're ignorant."

Linus's caustic posts often have the effect of closing down the debate. In this case even seasoned kernel developers might not be eager to jump into the discussion unless they are experts in cryptography. To be fair, the headline for the petition at the Change.org site was a bit caustic also and probably started the whole thing off on the wrong footing: "Linux: A NSA Approved Partner."

As of now, the petition is closed with only five signatures, but at least one cryptography specialist has taken up the challenge to "go read drivers/char/random.c" and, although agreeing with the basic concept for using Rdrand, has offered a suggestion that might someday lead to improvements in the way Linux handles random number generation. Such is the way of the kernel – after all the politics, the real story comes down to programmers studying source code and looking for improvements.

The NSA backdoor in "Linux"

https://www.barkdull.org/blog/the-nsa-backdoor-in-linux

Considering that the Linux kernel (the only component Linus has any kind of control over), the software from the GNU Project, and all of the most popular third-party software available for GNU/Linux is all free and open source, it is ridiculous that people can even believe the notion that Linus Torvalds, solely, could put a backdoor in "Linux."

Free and open source software obviously makes a clandestine backdoor very difficult.

There's also the fact that any kind of backdoor in a kernel wouldn't amount to much when most user-space software that initiates kernel actions wouldn't be affected. It's important to remember that Linux can't do most tasks without user-space software, let alone those necessary for a backdoor. For example, the ext4 filesystem libraries and the GNU C Library, as well as the -- often proprietary binary blob -- networking, SATA and video drivers, are all necessary components for a backdoor and would all have to be affected.

Which, again, would not only be a very difficult task, but also one that Torvalds would play a minuscule role in.

I would be more concerned about another possible, more likely, and more viable backdoor vulnerability. That being user-space software. It would be easier to put a backdoor in something like OpenSSL (when it wasn't well maintained), and it would be far more useful to put a backdoor in something like the various filesystem libraries, the GNU C Library, GCC, GIMP, Firefox, or Webkit, as those are used not only on desktop GNU/Linux, but on Android, OS X, BSD, iOS, and Windows as well.

Let's not forget about SELinux, the Linux kernel module developed and maintained by the NSA that sees very wide use across distributions. Since most people already use SELinux, the NSA wouldn't even have to approach Torvalds to get a backdoor into Linux. However, again, SELinux is free and open source, the NSA couldn't put a backdoor in it without people noticing.

All of this is inconsequential, anyway, as Torvalds clarified in September of last year that he was, in fact, joking.

The NSA never actually approached him. Despite what his father says.

Suomynona

7 years ago

They can, they will..
My guess is that it would already be implemented in the hardware, isolated from the applied 'OS'.. So with standard technologies the only way out is through my never used packetsniffer. To bypass that, I guess the rush for global dominion have put extra threads in my ethernetcable where my limited tools and knowledge for DSprocessing fails.
Of course the NSA, SÄPO or whomever could always call me for delicious information about PHP, chocolaterecipies or tuned mopeds ;o)
However, humanity has probably been owned for thousands 'millions?' of years, it is probably not a backdoor in there, it has always been at your frontdoor or lawn.

Since this commentsystem is probably going to be implemented at my latest project, socializing, knowledgebasing and promoting masonists/bricklayers/chimneyconstruction'ers here in Sweden, could we not provide an API for infoleakage so that anyone interested could take part of backstage encrypted posts?
Or better yet, maybe 'they' have API's readily available, so the post-object could store at my server and also push to kgb.com?

So, feature request that is ;o)

../greets from an all open 'but somewhat terrified' heart @snowyLandscapes( 'that-is-awsome' );

LINUX BACKDOOR RELATED LINKS:

https://www.bleepingcomputer.com/news/security/nsa-linked-bvp47-linux-backdoor-widely-undetected-for-10-years/

https://www.reddit.com/r/linux/comments/54in5s/the_nsa_has_tried_to_backdoor_linux_three_times/

• Ever since i heard about Intel Active Management Technology (AMT) and AMD's alternative, i wonder why would NSA even bother with backdoors now. Most of us already have a backdoor up and running.
• Doesn't AMT explicitly have to be enabled in BIOS/firmware? So you would need a CPU that supports it, a motherboard that exposes it, and for it to be enabled. It's not some magic backdoor.
• We need FOSS cpu's for next year. Sick of this shit.
• I think the reason we hear nothing about IME hacks is because the NSA would prefer to keep it that way. The IME potential is way more insidious, and they don't have to show their code to anyone.

• Between that and the hardware blobs, we don't have to worry about Linux bring hacked, but rather our hardware itself.