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

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. Guarding Your Privacy With E2EE: Primer

    "As with all security, there is assumed risk no matter how careful you are. There are no security guarantees but that doesn't mean you shouldn't try."



  2. Links 27/11/2020: Systemd 247 and Cockpit 233

    Links for the day



  3. A Free Speech Deficit Harms Software Freedom

    Free software and Software Freedom cannot possibly succeed if we keep accepting or even just tolerating systematic censorship of opinionated people in our community; failing to speak out on this matter (for fear of supposedly offending someone, risking expulsion) is part of the problem — complicity by passivity



  4. Perception of Difficulty

    New poem by figosdev



  5. IRC Proceedings: Thursday, November 26, 2020

    IRC logs for Thursday, November 26, 2020



  6. Cartoon: After Gambling With Workers' Savings the EPO Can Do Real Estate

    New EPO cartoon from EPO insiders (the one on the right certainly looks a lot like António Campinos and the one on the left can be his EUIPO ‘import’ or Benoît Battistelli‘s INPI ‘import’)



  7. Free as in Freedom Should Not be Associated With Cost

    It's important to remind people that so-called 'free' services (Clown Computing, centralised spaces that 'farm' their so-called 'users') aren't really free; we need to advocate freedom or free-as-in-freedom alternatives



  8. [Meme] UPC's Pyrrhic Victory

    Contrary to what Team UPC says, what happened earlier today is hardly a breakthrough



  9. Many Thanks to Free Software, the Demise of Software Patents (in Europe and the US), and So Much More

    On a positive note we're heading into the end of November, one month before Boxing Day; we take stock of patent affairs that impact software developers



  10. Links 26/11/2020: PHP 8.0, Proxmox VE 6.3, UNIGINE 2.13

    Links for the day



  11. 29,000 Blog Posts and Recent Site Improvements

    Over 29,000 blog posts have been posted here, but more importantly we've made the site a lot more robust and resilient, accessible in more formats and protocols (while improving transparency, too)



  12. [Meme] Trump is Out. Now It's Time to Pressure the Biden Administration/Transition Team on Software Freedom Issues.

    The Biden transition is in motion and tentative appointments are underway, based on news reports (see our Daily Links); now is the time to put pressure, e.g. in the form of public backlash, to ensure it's not just another corporate presidency



  13. Boycott ZDNet Unless You Fancy Being Lied to

    ZDNet's Catalin Cimpanu continues to lead the way with misinformation and lies, basically doing whatever he was doing to land that job at ZDNet (after he had done the same elsewhere)



  14. The UPC and Unitary Patent Song

    On goes the UPC symphony, as the Unified Patent Court (UPC) is almost here, always coming "real soon!"



  15. Open Letter to the German Greens on UPC and Software Patents: Don’t Betray Your Voters and Your Promises, or You Will Regret it

    Dear Members of the German Greens in the Bundestag. By Benjamin HENRION.



  16. [Meme] One Step Away From Replacing Patent Examiners With 'Hey Hi' (AI)

    If it's not legal for 'Hey Hi' (AI) to get a patent, why should it be legal for patents to be granted by those who are invisible (and sometimes in de facto house arrest)?



  17. European Patent Office (EPO) Reduced to 'Justice Over the Telephone' and Decree by E-mail

    The EPO is trashing the EPC and everything that the Office was supposed to stand for, as it wrongly assumes demand for monopolies (typically from foreign corporations) comes before the rule of law and Europe's public interest



  18. Making Free Software Work for Users

    The latest reply to a non-developer concerned about software freedom; guest post by figosdev



  19. IRC Proceedings: Wednesday, November 25, 2020

    IRC logs for Wednesday, November 25, 2020



  20. Links 26/11/2020: AV Linux 2020.11.23 and Blender 2.91 Release

    Links for the day



  21. Links 25/11/2020: GamerOS and Biden Transition in Motion

    Links for the day



  22. An Orwellian December

    With December around the corner and states tightening the screws on the population (or employers on employees) at least we can look forward to spring



  23. The Non-Technical (or Lesser Technical) Software User That Wants Software Freedom

    Assuming that Free software should care about what users — not only developers — really want (and need) it’s important to understand how they view the current situation (with growing waves of corporate takeover and compromises, even expulsions)



  24. The European Patent Office Should be Run by Patent Examiners (Scientists), Not Politicians

    Europe would be better off (and patent quality much improved) had people with an actual grasp of science and reality were in charge of the EPO, not a money-chasing kakistocracy (which is what we have now)



  25. Member of the EPO's Boards of Appeal Explains Why VICOs (or ViCo/Video Conferences/Virtual 'Hearings') Are Not Suitable for Justice

    It's interesting to hear (or see/read) what people inside the EPO have to say about the "new normal" when they enjoy a certain level of anonymity (to avert retribution)



  26. Open Source Initiative (OSI) Co-founder Bruce Perens: Open Invention Network (OIN) is Protecting the Software Patent System From Reform and OSI Approves Faux 'Open' Licences (Openwashing)

    Richard Stallman was right about the OSI and the fake 'movement' that claims to have 'coined' the term "Open Source" (it wasn't a new term at all; it had been used in another context and the Free software community spoke of things like "Open Hardware" years earlier)



  27. IRC Proceedings: Tuesday, November 24, 2020

    IRC logs for Tuesday, November 24, 2020



  28. Making JavaScript Suck Less

    "Other than that, the first rule of JavaScript is: Do not use JavaScript. But this article is for people who break the first rule."



  29. Microsoft 'Moles' Inside WINE Project? WINE Should Bring Windows Users to GNU/Linux, Not the Other Way Around.

    The press release above (link omitted, it was pinned in several sites) is a cause for concern; after Microsoft infiltrated OSI and the Linux Foundation (both are now GitHub boosters, in effect diverting projects to Microsoft’s proprietary monopoly) it’ll be important to watch this space



  30. Links 25/11/2020: Raspberry Pi 400 With Touchscreens, Animation Framework in GTK/GNOME

    Links for the day


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