Bonum Certa Men Certa

Linux Backdoors Revisited (New Revelations and Old Revelations)

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.

Recent Techrights' Posts

The "Luddite" Complex
Sometimes simplest is best and sometimes "modern" is designed not with the buyers' interest in mind
SCO's Darl McBride Dead at Age 64
There's hardly any information about it, except we know he reached bankruptcy and 3 years later he died at a relatively young age
[Meme] Python Knows Its Bosses
Microsoft strings attached
[Meme] Debt of About $20 Per Active User
Facebook isn't laying off tens of thousands for "efficiency" but for survival
 
Links 02/11/2024: Many Fakes in Social Control Media
Links for the day
GNU/Linux Usage Surveys: Up to 6.8% (With ChromeOS, Based on StatCounter) in Desktops/Laptops and Above 2% in Steam
Today StatCounter starts releasing graphs based on data for November
Gemini Links 02/11/2024: Petscop, Jokes, and RetroChallenge
Links for the day
Links 02/11/2024: Temu EU Probe and Shorts Trademark
Links for the day
The 'Turning-Free-Code-Proprietary Foundation' (Linux/Microsoft Foundation)
LF will basically become just as sinister as its corporate sponsors
Python Software Foundation is 'Cancel Culture' Rehomed
Python isn't grassroots and it doesn't really tolerate grassroots
DeVault "Closes Down His Mailing Lists Every Time There's a Scandal" and Also Censors Messages
Censorious code hosting platform
What Social Control Media Really Is
Social Control Media, in a nutshell, isn't just bad if its controller is some foreign or hostile nation
Taking Ethics Lectures From Drew
Projection tactics
Links 02/11/2024: Facebook Stock Falls (Soaring Debt), Apple’s Quarterly Profit Down
Links for the day
Gemini Links 02/11/2024: Burnout, Emacs Bookmarks, and Smooth Migration
Links for the day
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Friday, November 01, 2024
IRC logs for Friday, November 01, 2024
Facebook's Debt Has Soared to All-Time High of Nearly 50 Billion Dollars
But the corporate media pretends all is well (while mass layoffs continue and slop takes over the social control media)
Geminispace Makes It Past 4,200 Capsules on November 1st
At last!
Links 01/11/2024: Election Interferences by X/Twitter/Musk, Strava as Espionage Tool
Links for the day
The October 2024 Web Server Survey Shows a Further Collapse for Microsoft in the Servers Market
Microsoft experienced the next largest loss of 699,464 sites (-3.45%)
Gemini Links 01/11/2024: TLS Sucks, twytere.com Announced
Links for the day
Links 01/11/2024: Few Things Are Cheaper Than This Antenna and "Nothing Lasts Forever"
Links for the day
Technology: rights or responsibilities? - Part V
By Dr. Andy Farnell
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Thursday, October 31, 2024
IRC logs for Thursday, October 31, 2024
R.T.O. is Another Name (or Acronym) for Voluntary Layoffs
Amazon is trying to get many workers to leave on their own
Microsoft's Acquisition of Activision (to Fake Revenue Growth by Buying Revenue) Was a Failure
Of course the mass layoffs at Microsoft aren't just a Microsoft thing
Stagnant, Shrinking Businesses and "IBM's Corporate Culture Since the Late 1980s... Over 35 Years."
Recently, IBM was using share price as a talking point, insisting the company was doing OK while tens of thousands were being laid off
Links 01/11/2024: World News, Political Catchup
Links for the day
[Meme] Probably the Worst Possible Time to Get Information From Social Control Media
Musk does not want to prevent disinformation from spreading and the same is true for Facebook and TikTok; they have their own interests
Update on Litigation Against the European Patent Office (EPO) at the ILO Administrative Tribunal (ILOAT)
Rewards and compensation for staff have long fallen, resulting in many experienced colleagues leaving and causing further declines in quality and compliance
Gemini Links 31/10/2024: NNCP, Declutter the Web, Cost of Community
Links for the day
Links 31/10/2024: Supermicro Plummets 33%, Block and Dropbox Mass Layoffs
Links for the day
Links 31/10/2024: Environmental Anxiety, Profound Changes in Hardware Market
Links for the day
Links 30/10/2024: TSMC Concerns and North Koreans in Ukraine War
Links for the day
Facebook is for Zombies
Social control media is for fools
Microsoft Now Has $235,290,000,000 in Liabilities, They Grow Over Time in Spite of Mass Layoffs (So Expect More Layoffs)
expect more mass layoffs
Links 31/10/2024: DST Woes, War Updates, Amazon RTO Backlash
Links for the day
Gemini Links 31/10/2024: Attention Economy and Gemlogs
Links for the day
Happy Halloween
October is nearly over
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Wednesday, October 30, 2024
IRC logs for Wednesday, October 30, 2024
For the Record: Linux is Controlled by the United States of America
"This is going to make many question the openness and inclusivity of the work done by Linux Foundation"
Microsoft: XBox Hardware Revenues Down About 30% (Ignore the Buzzwords and Activision Activity Dressed Up as "XBox")
For context, in a previous quarter XBox hardware sales were down by about 50%
Cooking the Books With "Cloud" And "AI" Was Not Enough to Fool Microsoft Investors
"Microsoft Shares Drop on Disappointing Azure Growth Forecast"