EditorsAbout the SiteComes vs. MicrosoftUsing This Web SiteSite ArchivesCredibility IndexOOXMLOpenDocumentPatentsNovellNews DigestSite NewsRSS

10.16.13

Linux Backdoors Revisited (New Revelations and Old Revelations)

Posted in GNU/Linux, Kernel, Security at 10:43 am by Dr. Roy Schestowitz

Claude Elwood Shannon, the man who introduced entropy

Claude Elwood Shannon

Summary: An anonymous backdooring attempt against Linux goes a decade back, but a randomisation problem in today’s Linux also seems possible (subverting encryption)

Jonathan Allen wrote this article about an incident mentioned also by Freedom to Tinker. Slashdot’s summary goes like this, documenting news from one decade ago:

“Ed Felton writes about an incident, in 2003, in which someone tried to backdoor the Linux kernel. Back in 2003 Linux used BitKeeper to store the master copy of the Linux source code. If a developer wanted to propose a modification to the Linux code, they would submit their proposed change, and it would go through an organized approval process to decide whether the change would be accepted into the master code. But some people didn’t like BitKeeper, so a second copy of the source code was kept in CVS. On November 5, 2003, Larry McAvoy noticed that there was a code change in the CVS copy that did not have a pointer to a record of approval. Investigation showed that the change had never been approved and, stranger yet, that this change did not appear in the primary BitKeeper repository at all. Further investigation determined that someone had apparently broken in electronically to the CVS server and inserted a small change to wait4: ‘if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) …’ A casual reading makes it look like innocuous error-checking code, but a careful reader would notice that, near the end of the first line, it said ‘= 0′ rather than ‘== 0′ so the effect of this code is to give root privileges to any piece of software that called wait4 in a particular way that is supposed to be invalid. In other words it’s a classic backdoor. We don’t know who it was that made the attempt—and we probably never will. But the attempt didn’t work, because the Linux team was careful enough to notice that that this code was in the CVS repository without having gone through the normal approval process. ‘Could this have been an NSA attack? Maybe. But there were many others who had the skill and motivation to carry out this attack,’ writes Felton. ‘Unless somebody confesses, or a smoking-gun document turns up, we’ll never know.’”

Backdoors in Linux are a subject for jokes in Torvalds' mind, but given the above we should take this subject very seriously. In any system, for example, having no mechanism for randomness (like in some embedded devices) typically means that strong encryption (with high entropy) is not possible. Given new alleged “insecurities in the Linux /dev/random,” as Bruce Schneier put it, Linux backdoors seem possible again. David Benfell said:

I’m guessing Schneier knows what the fuck he’s talking about. If it is the same vulnerability, then Torvalds’ defense is that the vulnerable source of entropy is only one of many. But if I read Schneier correctly, the result was still too predictable.

“On the other hand,” says Benfell, “here’s Theodore T’so from the comments:”

So I’m the maintainer for Linux’s /dev/random driver. I’ve only had a chance to look at the paper very quickly, and I will at it more closely when I have more time, but what the authors of this paper seem to be worried about is not even close to the top of my list in terms of things I’m worried about.

First of all, the paper is incorrect in some minor details; the most significant error is its (untrue) claim that we stop gathering entropy when the entropy estimate for a given entropy pool is “full”. Before July 2012, we went into a trickle mode where we only took in 1 in 096 values. Since then, the main way that we gather entropy, which is via add_interrupt_randomness(), has no such limit. This means that we will continue to collect entropy even if the input pool is apparently “full”.

This is critical, because *secondly* their hypothetical attacks presume certain input distributions which have an incorrect entropy estimate —| that is, either zero actual entropy but a high entropy estimate, or a high entropy, but a low entropy estimate. There has been no attempt by the paper’s authors to determine whether the entropy gathered by Linux meets either of their hypothetical models, and in fact in the “Linux Pseudorandom Number Generator Revisited”[1], the analysis showed that our entropy estimator was actually pretty good, given the real-life inputs that we are able to obtain from an actual running Linux system.

[1]http://eprint.iacr.org/2012/251.pdf

The main thing which I am much more worried about is that on various embedded systems, which do not have a fine-grained clock, and which is reading from flash which has a much more deterministic timing for their operations, is that when userspace tries to generate long-term public keys immediately after the machine is taken out of the box and plugged in, that there isn’t a sufficient amount of entropy, and since most userspace applications use /dev/urandom since they don’t want to block, that they end up with keys that aren’t very random. We had some really serious problems with this, which was written up in the “Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices” [2]paper, and the changes made in July 2012 were specifically designed to address these worries.

[2]https://www.factorable.net/paper.html

However, it may be that on certain systems, in particular ARM and MIPS based systems, where a long-term public key is generated very shortly after the first power-on, that there’s enough randomness that the techniques used in [2]would not find any problems, but that might be not enough randomness to prevent our friends in Fort Meade from being able to brute force guess the possible public-private key pairs.

Speaking more generally, I’m a bit dubious about academic analysis which are primarily worried about recovering from the exposure of the state of the random pool. In practice, if the bad guy can grab the state of random pool, they probably have enough privileged access that they can do many more entertaining things, such as grabbing the user’s passphrase or their long-term private key. Trying to preserve the amount of entropy in the pool, and making sure that we can extract as much uncertainty from the system as possible, are much higher priority things to worry about.

That’s not to say that I might not make changes to /dev/random in reaction to academic analysis; I’ve made changes in reaction to [2], and I have changes queued for the next major kernel release up to make some changes to address concerns raised in [1]. However, protection against artificially constructed attacks is not the only thing which I am worried about. Things like making sure we have adequate entropy collection on all platforms, especially embedded ones, and adding some conservatism just in case SHA isn’t a perfect random function are some of the other things which I am trying to balance as we make changes to /dev/random.

T’so, who is the former CTO of the Linux Foundation, at least acknowledges the possibility that there is a real issue here.

Share in other sites/networks: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Reddit
  • email
  • Slashdot

If you liked this post, consider subscribing to the RSS feed or join us now at the IRC channels.

Pages that cross-reference this one

What Else is New


  1. At ZDNet, in 2020, “Linux” Means Microsoft and Windows

    The incredible charade of ZDNet carries on; the site whose parent company went bust last December isn’t even trying to hide its true agenda



  2. Red Hat is Spamming People in Order to Promote Its Sites and Its Products, Subscribing People to Mass-Marketing Lists Without the Recipients' Consent

    "Engagements" from Red Hat; have the IBM-led marketing people gone overboard, subscribing lots of people to marketing spam without bothering to ask for consent?



  3. “If I'm the Father of Open Source, It Was Done by Artificial Insemination With Stolen Sperm”

    The father of the Free software movement, Richard Stallman, is being wrongly compared to some patron of an “open source” ‘movement’ (an early effort to cancel Stallman and the FSF), which is basically a hostile corporations-led ploy these days



  4. IRC Proceedings: Wednesday, September 23, 2020

    IRC logs for Wednesday, September 23, 2020



  5. The Second Wave (of Free/Libre Software)

    Despite some major setbacks and new threats to digital freedom (autonomy is perhaps a more suitable term), progress is being made and activism must adapt to tackle newer trends



  6. Exploring the Relationship Between Red Hat and Microsoft: They're Barely Even Rivals Anymore

    The ‘older Microsoft’ (serial monopolist IBM) bought Red Hat, but evidence shows that one would be wrong to assume Red Hat really competes against Microsoft (any more than Novell did; there’s a strong relationship)



  7. Microsoft Lost More Than 15 Million Web Domains in One Month!

    Microsoft's presence on the Web is being reduced to ridiculously low levels; sooner or later Microsoft will turn from 'king' of parked (unused) domains to master of nothing



  8. Links 23/9/2020: Lenovo's Deeper GNU/Linux Dive and Tor Browser 10/Tails 4.10

    Links for the day



  9. IRC Proceedings: Tuesday, September 22, 2020

    IRC logs for Tuesday, September 22, 2020



  10. The Latest Greenwashing Campaign by the EPO is Just 'Chinese Propaganda'

    When the EPO speaks of “innovation” and “clean energy transition” it means nothing but patents on batteries, in effect monopolies being granted in Europe (to a lot of Asian — not European — companies)



  11. Links 23/9/2020: Librem 14 Shipping in December, Linux Journal Returns, Istio 1.6.10 Released, Release Candidate 3 of LLVM 11.0

    Links for the day



  12. Welcome Back, Linux Journal!

    Linux Journal is coming back under the ownership/umbrella of Slashdot folks, who are sadly preoccupied and obsessed with Microsoft talking points and PR campaigns



  13. What the Efforts to Remove Dr. Stallman Reveal About the Agenda of Large Corporations (Looking to Absorb the Competition, Remove Freedom, Spread Proprietary Software in 'Open' Clothing)

    Richard Stallman's (RMS) positions and foresight are usually correct; at the moment we're losing access to key people whose leadership positions are essential for the independence of cornerstone projects



  14. Links 22/9/2020: Tails 4.11, Linux Lite 5.2 RC1

    Links for the day



  15. Minimalism for Maximisation of Productivity and Clutter Mitigation

    Unfortunately, GNU/Linux (especially the latter, Linux) embraces bloat and anti-features in pursuit of sales (appeasing large corporations, not users’ needs), reducing the modularity, reliability and productivity of computer systems in the name of helping “dumb” users (they keep telling us people are very dumb and those who disagree are “elitist” and “extremist” or even “neckbeards” — in effect insulting every person out there)



  16. IRC Proceedings: Monday, September 21, 2020

    IRC logs for Monday, September 21, 2020



  17. Post-Coronavirus Linux.com Became Nothing But a SPAM Site

    As per the Linux Foundation‘s very own brochure, scripted and fake ‘interviews’ are to be produced and then edited/negotiated (before publication) with the sponsor… in Linux.com as the platform. This is corruption (or marketing, one might call them de facto ads presented as fake ‘articles’).



  18. Erosion of Free Speech and Tolerance of Opposing Viewpoints in Free Software Communities

    The concept of free speech is being reinvented by oversensitive people who nowadays expand the list of exclusions/exemptions (from scope of 'permissible' speech) to politics and criticism of large and highly abusive corporations



  19. Links 21/9/2020: PlasmaShell With Vulkan, Plasma Beta Review Day, OpenMediaVault 5.5.11

    Links for the day



  20. Guest Post: The Worrying State of Political Judgement in Free Software Communities

    A look at what Mozilla has become and what that teaches us about the Web and about software



  21. Links 21/9/2020: KTechLab 0.50.0, Linux 5.9 RC6

    Links for the day



  22. IRC Proceedings: Sunday, September 20, 2020

    IRC logs for Sunday, September 20, 2020



  23. Git is Free Software, GitHub is Proprietary Trap

    More and more people all around the world understand that putting their fruit of labour in Microsoft's proprietary (but 'free') prison is misguided; the only vault they have is for human beings, not code



  24. Daniel Pocock on Codes of Conduct and Their Potential Dangers in Practice

    In Debian we’ve already witnessed several examples where Codes of Conduct, if put in the wrong hands (in the Linux Foundation it’s corporate hands), can achieve the very opposite of their intended goal and its a true shame as well as a travesty for legitimate victims of real abuse



  25. Links 20/9/2020: Flameshot Screenshot Tool 0.8, Okular Improvements and More

    Links for the day



  26. Reminder: Vice Chair of the Linux Foundation's Board is an Oracle Executive Who Used to Work for Microsoft

    The Linux Foundation issued statements to the effect of opposing Donald Trump, but its current leadership (people from companies like Oracle, Microsoft and IBM) is a strong proponent of doing as much business as possible with Trump (even in violation of international law)



  27. [Meme] How to Hijack Linux and Free Software to Make Them Proprietary and Microsoft-Controlled

    Intel keeps outsourcing almost everything (that's not proprietary with back doors, e.g. ME) to Microsoft's proprietary software prison, known as GitHub; to make matters worse, Intel now uses the Microsoft-hosted Rust to develop in Microsoft servers, along with Microsoft, code that promotes Microsoft proprietary software (e.g. Hyper-V) and non-standard 'extensions'.



  28. DDOS Attacks Against Us Lately

    (Distributed) Denial-of-service attacks or DDOS attacks have slowed down the site, but we treat that as evidence of suppression and fear (of what's to come and what was recently published), or accuracy (in reporting) rather than inaccuracy



  29. [Meme] Windows as Dead Man Walking (Patches Accelerate the Death)

    Microsoft is squeezing whatever life is left in its “burning platform” (which is already exceeded in terms of market share by Android) that has a "burning" (bricked) WSL with barely any users and plenty of critical problems



  30. We Let Them Get Away With Murder, But They Make up for It by Banning Words

    The Microsoft propaganda machines (notably ZDNet this weekend) are busy portraying Microsoft as a “good company” for censoring words, never mind the actual, meaningful, substantial actions of Microsoft, which is boosting authoritarian people who imprison even babies (for the ‘crime’ of being on the ‘wrong’ side of the border)


RSS 64x64RSS Feed: subscribe to the RSS feed for regular updates

Home iconSite Wiki: You can improve this site by helping the extension of the site's content

Home iconSite Home: Background about the site and some key features in the front page

Chat iconIRC Channel: Come and chat with us in real time

Recent Posts