10.16.13

Gemini version available ♊︎

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

Decor ᶃ Gemini Space

Below is a Web proxy. We recommend getting a Gemini client/browser.

Black/white/grey bullet button This post is also available in Gemini over at this address (requires a Gemini client/browser to open).

Decor ✐ Cross-references

Black/white/grey bullet button Pages that cross-reference this one, if any exist, are listed below or will be listed below over time.

Decor ▢ Respond and Discuss

Black/white/grey bullet button If you liked this post, consider subscribing to the RSS feed or join us now at the IRC channels.

DecorWhat Else is New


  1. IRC Proceedings: Saturday, January 28, 2023

    IRC logs for Saturday, January 28, 2023



  2. Unmasking AI

    A guest article by Andy Farnell



  3. The ISO Delusion/Sirius Corporation: A 'Tech' Company Run by Non-Technical People

    Sirius ‘Open Source’ was hiring people who brought to the company a culture of redundant tasks and unwanted, even hostile technology; today we continue to tell the story of a company run by the CEO whose friends and acquaintances did severe damage



  4. Links 28/01/2023: Lots of Catching Up (Had Hardware Crash)

    Links for the day



  5. IRC Proceedings: Friday, January 27, 2023

    IRC logs for Friday, January 27, 2023



  6. Microsoft DuckDuckGo Falls to Lowest Share in 2 Years After Being Widely Exposed as Microsoft Proxy, Fake 'Privacy'

    DuckDuckGo, according to this latest data from Statcounter, fell from about 0.71% to just 0.58%; all the gains have been lost amid scandals, such as widespread realisation that DuckDuckGo is a Microsoft informant, curated by Microsoft and hosted by Microsoft (Bing is meanwhile laying off many people, but the media isn’t covering that or barely bothers)



  7. This is What the Microsoft-Sponsored Media Has Been Hyping Up for Weeks (Ahead of Microsoft Layoffs)

    Reprinted with permission from Ryan



  8. [Meme] António Campinos Wants to Be F***ing President Until 2028

    António Campinos insists he will be EPO President for 10 years, i.e. even longer than Benoît Battistelli (despite having appalling approval rates from staff)



  9. European Patent Office Staff Losing Hope

    The EPO’s management with its shallow campaign of obfuscation (pretending to protect children or some other nonsense) is not fooling patent examiners, who have grown tired and whose representatives say “the administration shows no intention of involving the staff representation in the drafting of the consultant’s mandate” (like in Sirius ‘Open Source’ where technical staff is ignored completely for misguided proposals to pass in the dark)



  10. IRC Proceedings: Thursday, January 26, 2023

    IRC logs for Thursday, January 26, 2023



  11. Sirius Relegated/Demoted/Destined Itself to Technical Hell by Refusing to Listen to the Technical Staff (Which Wanted to Stay With Asterisk/Free Software)

    In my final year at Sirius ‘Open Source’ communication systems had already become chaotic; there were too many dysfunctional tools, a lack of instructions, a lack of coordination and the proposed ‘solution’ (this past October) was just more complexity and red tape



  12. Geminispace Approaching Another Growth Milestone (2,300 Active Capsules)

    The expansion of Geminispace is worth noting again because another milestone is approached, flirted with, or will be surpassed this coming weekend



  13. [Meme] Cannot Get a Phone to Work... in 2022

    Sirius ‘Open Source’ wasted hours of workers’ time just testing the phone after it had moved to a defective system of Google (proprietary); instead of a rollback (back to Asterisk) the company doubled down on the faulty system and the phones still didn’t work properly, resulting in missing calls and angst (the company just blamed the workers who all along rejected this new system)



  14. [Meme] Modern Phones

    Sirius ‘Open Source’ is mistaking “modern” for better; insecurity and a lack of tech savvy typically leads to that



  15. The ISO Delusion: Sirius Corporation Demonstrates a Lack of Understanding of Security and Privacy

    Sirius ‘Open Source’, emboldened by ISO ‘paperwork’ (certification), lost sight of what it truly takes to run a business securely, mistaking worthless gadgets for “advancement” while compelling staff to sign a new contract in a hurry (prior contract-signing scandals notwithstanding)



  16. Links 26/01/2023: LibreOffice 7.4.5 and Ubuntu Pro Offers

    Links for the day



  17. Links 26/01/2023: GNU poke 3.0 and PipeWire 0.3.65

    Links for the day



  18. IRC Proceedings: Wednesday, January 25, 2023

    IRC logs for Wednesday, January 25, 2023



  19. Companies Would Collapse Upon Abandoning Their Original Goals (That Attracted All the Productive Staff)

    Staff with technical skills won't stick around in companies that reject technical arguments and moreover move to proprietary software in a company that brands itself "Open Source"



  20. [Meme] Listen to Your Workers, Avert Disaster

    Companies that refuse to take input from staff are doomed to fail



  21. The ISO Delusion: When the Employer Doesn’t Understand the Company's Value Proposition (Building Systems) and Rejects Security

    Sirius ‘Open Source’ has failed to sell what it was actually good at; instead it hired unqualified people and outsourced almost everything



  22. Links 25/01/2023: NuTyX 23.01.1 and GNU Guile 3.0.9 Released

    Links for the day



  23. Links 25/01/2023: Stratis 3.5.0 and Many Political Links

    Links for the day



  24. New Record Low: Only One 'Linux' Article in ZDNet in More Than Two Weeks

    Only a few years ago ZDNet published about 3 “Linux” stories per day (mostly FUD pieces); now it’s a ghost town, painted in ‘alien green’; considering ZDNet’s agenda (and sponsors) maybe it’s better this way



  25. Links 25/01/2023: Pale Moon 32.0 and DXVK 2.1

    Links for the day



  26. IRC Proceedings: Tuesday, January 24, 2023

    IRC logs for Tuesday, January 24, 2023



  27. ISO Certification Hardly Tackles Any of the Real Issues

    The real-world threats faced by private companies or non-profit organisations aren't covered by the ISO certification mill; today we publish the last post on this topic before proceeding to some practical examples



  28. [Meme] Medical Data Sovereignty

    What happens when your medical records/data are accessible to a company based abroad after a mysterious NDA with the Gates Foundation? The International Organization for Standardization (ISO) does not mind.



  29. The ISO Delusion: Sirius Open Wash Ltd. and Medical Data/Projects at Risk/Peril

    Sirius ‘Open Source’ was good at gloating about “ISO” as in ISO certification (see our ISO wiki to understand what ISO truly is; ISO certification needs to be more widely condemned and exposed) while signing all sorts of dodgy deals and lying to clients (some, like the Gates Foundation, were never mentioned because of a mysterious NDA); security and privacy were systematically neglected and some qualified as criminal negligence (with fines/penalties likely an applicable liability if caught/reported)



  30. Links 24/01/2023: Wine 8.0 is Ready, FSF Bolsters Copyleft

    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