back to article So, Linus Torvalds: Did US spooks demand a backdoor in Linux? 'Yes'

Linux supremo Linus Torvalds has jokingly admitted US spooks approached him to put a backdoor in his open-source operating system. During a question-and-answer ‪session ‬at ‪the LinuxCon gathering in New Orleans this week‪, Torvalds ‬and his fellow kernel programmers ‪w‬ere‪ asked by moderator Ric Wheeler whether America's g- …

COMMENTS

This topic is closed for new posts.

Page:

  1. Chika

    Post a comment?

    Are you mad? I wouldn't dare post a comment here in case the NSA had a backdoor...

    1. amanfromMars 1 Silver badge

      Post a leading comment and phishermen will be all at sea and know not what to do?

      If Spooky Five Eyed Monsters have a backdoor into here on El Reg, they be desperately slow to realise what they should be doing to control the future with IT and media .... and that would indicate that they do not have the intelligence in-house to make good and better beta use of that which be shared freely in comments made here oft and at times on these leading tales with following threads.

      More Herman Munster monster types than big scary master race types, methinks. ...... http://memecrunch.com/image/50915d72afa96f2b9a00006f.jpg

      Is it mad or smart to post here if one would expect/hope/suspect/invite spooks to phish here and poach/net/capture some prime game with the simplest of ignorant megabuck lures/jackpot lottery prizes, which have no one asking awkward questions about instant flash wealth for services to be rendered .... or not to be rendered but to be held in temporary abeyance until such times as intelligent things will not collapse dumb systems and algorithms in a global flash crash?

  2. Anonymous Coward
    Anonymous Coward

    So, he was joking then? Which would seem to make sense, if I were going to put a backdoor into an open source product, I'd compromise a distribution rather than the source.

    How many people compile from source and then compare the binaries that they've compiled with the ones supplied by the distribution? I'm guessing in the region on none, there are simply too many variables which would end up with fractionally different binaries.

    1. Spoonsinger

      So, he was joking then?

      Well he has tended to open mouth/write in the past without thinking, maybe this was an example of that, and brain kicking into to say 'you really really really didn't want to do that'.

      1. Anonymous Coward
        Anonymous Coward

        Re: So, he was joking then?

        Many a true word spoken in jest.

        He answered EXACTLY as I'd have answered in his position if I HAD been whispered to. Gave us as honest an indication as he could without breaking any secret court secret orders. Doesn't mean he yielded of course, just that it is (or would be) up to us to find them. (Try doing that with Windows/iOS/OSX/etc..)

    2. Wemb

      What makes you think compiling from source will help....

      http://www.catb.org/jargon/html/B/back-door.html

      1. This post has been deleted by its author

        1. Charles 9

          Re: Agreed.

          "If I were the NSA, I would just have the "right" people placed in a company like RHEL, where the compiler could be doctored, and the doctored binary and clean source code could then be distributed.

          Any recompile would, of course, inject Trojan horse code - regardless of how closely the source was inspected: Neither the compiler source, nor the project source code would contain any evidence"

          But they'd also have to dodge an independent compile using another toolchain's compiler: one outside NSA control.

          In the end, a compiler could probably be vetted a few times, down to the machine code, and its binary code hashed a few ways (just in case the spooks have a way to create a preimage trojan for one of them--it would be statistically infeasible to tamper with the code AND match the hashes on two different hash familities). Once that could be verified, then you can compile against that one and establish a chain of trust that shows the code wasn't tampered without it showing up in the source. I don't think we're at the stage were we need such anal retention YET...but it's still an option.

      2. Roland6 Silver badge

        Re @Wemb

        Back to basics then and brush up on those Unix porting skills, as the only way to avoid such tricks as KT's is to do the bootstrapping yourself... But did Linux implement Unix's platform portability?

    3. Voland's right hand Silver badge

      If memory serves me right Fins and Bulgarians are the only people wave their head horizontally when saying yes. So that is the harmless explanation. The not so harmless... Well... Linus is renowned for his body language ya know...

      1. Ocular Sinister

        Don't know about that

        But I do know that Indians shake their head for yes and nod for no.

        1. yosemite

          Re: Don't know about that

          Actually the Indian "head wobble" is an all encompassing gesture, it's more a sign of acknowledgement than a sign of agreement/disagreement to a statement.

          Basically, no they don't do as you suggest.

          1. john.w

            Re: Don't know about that

            It does mean "no" but more of a question, 'no?' . I had an Indian colleague who although the lead architect insisted on requesting agreement at almost every sentence 'no?'. Tried to stop her doing it as it rather undermined her own arguments showing what appeared to be a lack of confidence 'no?'. It all comes down to the politeness of Indian society.

        2. Charles 9

          Re: Don't know about that

          I know there's at least one culture that intentionally swapped their nods and shakes to stave off trouble from oppressive overlords while at the same time end-running a "cannot tell a lie" canon. Even after they were freed, the trend stuck.

      2. ilmari

        Finns nod for yes and shake for no.

        If you offer or posess alcohol, any and all responses or gestures mean "Good Sir, please , a sampling of your beverage, or I shall ensure your next liquid intake is intravenous.".

      3. Robert Helpmann??
        Childcatcher

        Nod for "No"

        If memory serves me right Fins and Bulgarians are the only people wave their head horizontally when saying yes.

        Bushmen, too, if 'The Gods Must Be Crazy" is to be believed.

      4. Lars Silver badge
        Linux

        @Voland's right hand, and what ever in that hand

        "He nodded his head", "He shook his head" is YES and NO. In the plus 50 countries have been to, this is the only thing that never fails. It would surprise me if Bushmen and what ever you could find in South America or the Pacific Islands did not understand the difference. Either you are a troll, stupid or just uneducated. Perhaps not totally uneducated as you managed to write Bulgarians if not Finns.

        As for this interview, it was honest, no company advertising, imagine a third sofa with Ballmer and Elop taking part.

      5. t.est

        Finns don't do that at all. It was a joke, or a message not a behaviour of fins.

        If you watch the video the latter part comes naturally, while the No/Yes part is performed with somewhat difficulty.

    4. Chemist

      "I'd compromise a distribution rather than the source."

      LOTS of distros though - going to compromise all of them ?. As a certain AC is fond of telling us Linux is only 1%, so what is any one distro ?

      1. Anonymous Coward
        Anonymous Coward

        There's really only about three distributions, which are used as a forking point for most of the others. Red Hat, Debian and Suse, I'd go with that.

        1. mmeier

          >There's really only about three distributions, which are used as a forking point for most of the others. Red Hat, Debian and Suse, I'd go with that.

          Well make it RedHat, Suse and xBuntu and you have 90+ percent of the Linux boxes compromised. And those are the packages most likely used "as is" rather then checked and recompiled because they target the "I want to USE the maschine not fiddle with it" part of Linux.

          Add in that all three are done by companies and there are legal means to get a company to "play nice and shut up" and the chances increase that there is "something nice" in there. With the Kernel Devs none the wiser.

    5. tom dial Silver badge

      If I am going to the bother of compiling the binaries, why would I not simply use them, as in Gentoo? If I did either, could I be confident that nothing was missed in my code examination? What about the compiler, the linker, and so on? If I compared results to the distributor's, how would I decide whether a difference indicated a fault in the distributed binary, the source, or simply noise introduced by differences in the two Make environments?

      The question ultimately resolves to one of trust: how far shall I trust the kernel and other developers, knowing that they are fallible and conceivably corruptible humans not all that different from me? Should I reckon them more or less trustworthy than those of Microsoft, Apple, or Google? Why?

      For that matter, why should I consider as The Guardian, Spiegel, The New York Times, the Washington Post, or even The Register more trustworthy than the US and UK governments and their accomplices in Canada, Australia and New Zealand? I have little personal knowledge of any of them, and all of them, whether government or press, may have motives for shading or spinning the truth. The documents I have seen are worrisome for sure, but are open to a range of interpretations not all of which support a claim that the governments are much interested in imposing a totalitarian regime. But are these documents to be considered trustworthy as given, inasmuch as they have an unverified history that depends on the questionable trustworthiness of a single individual?

  3. Kebabbert

    Other ways to get a back door

    NSA dont have to ask Linus Torvalds himself anymore. They can just submit a patch, because there are so many patches into Linux all the time, it is hard to check all new code. Apparently, this attempt was blocked. But how many more are not blocked? In Windows, NSA can not submit a patch, so NSA must ask Microsoft to deliberately insert a patch. But for Linux, there is a very high code turnover, so it is not hard to submit some new code:

    http://www.theregister.co.uk/2003/11/07/linux_kernel_backdoor_blocked/

    "If you were the NSA, how would you backdoor someone's software? You'd put in the changes subtly. Very subtly."

    "Whoever did this knew what they were doing," says Larry McVoy, founder of San Francisco-based BitMover, which hosts the Linux kernel development site that was compromised. "They had to find some flags that could be passed to the system without causing an error, and yet are not normally passed together... There isn't any way that somebody could casually come in, not know about Unix, not know the Linux kernel code, and make this change. Not a chance."

    1. Roo

      Re: Other ways to get a back door

      You don't have to manually check all the patches, regression tests & unit tests can do that stuff for you more reliably (and in the case of wait4 a priv-escalation test should be pretty easy to engineer). Sufficiently motivated users can implement their own tests too.

      Having said that writing your own tests against closed-source software is often a lot harder because typically it is insufficiently documented for you to infer what the valid states/inputs and outputs of the system are.

      I was worried by the fact that vendors place backdoors in software as a matter of routine (eg: default admin accounts+passwords) *before* the Ed Snowden decided to strip away any of the comfy illusions I had about the surveillance regimes we operate under...

      1. This post has been deleted by its author

    2. Anonymous Coward
      Anonymous Coward

      Re: Other ways to get a back door

      "They can just submit a patch, because there are so many patches into Linux all the time, it is hard to check all new code"

      Strange then that it all does get checked

      1. Kebabbert

        Re: Other ways to get a back door

        "...Strange then that [all code] does get checked..."

        Sure it gets checked. But the point is that it is not checked thoroughly. It is only skimmed and lot of subtleties are not catched. There are question marks in the code that gets accepted, because the code turn over is so high, no one can thoroghly check all code. Lot of code that no one really understands gets accepted. Maybe they contain subtle back doors?

        http://www.forbes.com/2005/06/16/linux-bsd-unix-cz_dl_0616theo.html

        "....Lok Technologies , a San Jose, Calif.-based maker of networking gear, started out using Linux in its equipment but switched to OpenBSD four years ago after company founder Simon Lok, who holds a doctorate in computer science, took a close look at the Linux source code.

        “You know what I found? Right in the kernel, in the heart of the operating system, I found a developer’s comment that said, ‘Does this belong here?’ “Lok says. “What kind of confidence does that inspire? Right then I knew it was time to switch....”

        1. Anonymous Coward
          Anonymous Coward

          Re: Other ways to get a back door

          “You know what I found? Right in the kernel, in the heart of the operating system, I found a developer’s comment that said, ‘Does this belong here?’ “Lok says. “What kind of confidence does that inspire? Right then I knew it was time to switch....”

          Specifically to switch to giving stupid interviews to Forbes to increase the visibility of his obscure company.

          The kernel has many comments about whether code could be improved and this is probably one of them. Logically, Lok is saying that coders should write comments as if they were writing marketing copy.

          Aside from anything else, if Lok was competent to be writing code he should have been able to answer the question himself.

          1. DanDanDan

            Re: Other ways to get a back door

            Frankly, I'd be more worried if the code *didn't* contain comments as such. There's no such thing as perfect code. Sometimes what you're writing seems pretty damn good, but sometimes there's a question mark about the better approach to take to solving a problem or its organisation. "Does this belong here" is a perfectly good comment to place by code. A more experienced coder may see the comment and think "Hmmm, no, I'll move it elsewhere and explain in the commit message my reasoning". Without the comment, probably no-one is going to review it and it'll be left there forever.

            Given that "perfect" code is a highly subjective affair and given that time constraints exist, the search for perfection is fairly futile and not productive. "Better" is better than "Not better", so if a clear improvement is there to be made, subject to one or two doubts, it should be implemented, with a comment explaining the doubts so it can be picked up for further improvement down the line.

  4. CommanderGalaxian

    Linus is wrong about Chipzilla. It contributes nothing further to the randomisation if it has a predictable sequence. It's like wrapping an already random stream in see-through paper, that's all. It can't add further entropy if it is no longer usefully randomising. Dunno why he doesn't get that point. Using it just wastes processor cycles.

    1. Richard Tobin

      The issue was not about wasting cycles - it's about whether it can *reduce* entropy. Linus thought this was absurd because even if the data was not random, it wouldn't reduce entropy. That's true so long as the data is produced without any knowledge of the other random data it will be combined with - but the sufficiently paranoid observe that we can't check that's the case.

      1. tentimes

        There is a very easy way to check: just plot or interpolate to expression the output of this supposed random generator.

        I used to write random number generators and test them, way-back-when, and the first thing I would do was plot it - human brain is very good at seeing patterns. I was amazed how difficult it really is to create a random number (it's impossible, basically - but you can get closer by degrees and there are now good mathematical models for it - if they aren't NSA'd too that is ;)

        1. Charles Manning

          Errr

          "human brain is very good at seeing patterns."

          The human brain is indeed a pattern matching engine. That is how it works.

          Unfortunately it even sees patterns when they really don't exist. That is how we end up with superstition.

          Pseudo-random numbers, as used by GPS, look entirely random and would not be caught by your plot test.

      2. CommanderGalaxian
        Headmaster

        It's all about KISS.

        "The issue was not about wasting cycles - it's about whether it can *reduce* entropy. ..."

        It won't reduce entropy - and it will defo not increase it! (An increase being what you want). So why run yet more s/w - purposelessly? Just something else that can break.

      3. Charles 9

        "Linus thought this was absurd because even if the data was not random, it wouldn't reduce entropy. That's true so long as the data is produced without any knowledge of the other random data it will be combined with - but the sufficiently paranoid observe that we can't check that's the case."

        Given most of the other inputs to /dev/random (the true RNG stream) are environmental, they'd have to subvert the environment to a great degree to be able to know the state of even one of the input streams to the point of being able to counter it.

        And there are other true random sources of bits besides radioactive decay. You can use a reverse-biased transistor, shot noise, avalanche noise (this is what the Entropy Key uses), and so on. Then there are projects like HAVEGE that emply the hectic, multitasking nature of modern CPUs to draw entropy.

    2. Steve Knox
      Boffin

      It contributes nothing further to the randomisation if it has a predictable sequence

      Every pseudorandom number generator in existence has a predictable sequence (hint: that's why they have pseudo- in the name). However, because exploitation of said sequence is dependent upon knowledge of the initial seed value, simply seeding a PRNG with data from a local nondeterministic source practically negates any advantage. Even the compromised Intel PRNG would not be easily exploited unless the application used a deterministically-determined seed value and output a large sequence of unmodified values from the PRNG.

      So provided the PRNG is seeded from a non-deterministic local source which is mathematically independent from the other inputs, using its values would contribute to the randomization.

      1. DJO Silver badge

        Psudorandomosity

        Every pseudorandom number generator in existence has a predictable sequence

        True but "predictable" covers a massive range from "bleeding obvious" to "almost totally incomprehensible to anything less than a Culture ship Mind" and all points between.

        As far as I know nuclear decay is the only easy genuine random source available but a bit tricky to include in a little chip at a suitably low cost.

        1. Steven Roper

          @ DJO Re: Psudorandomosity

          "As far as I know nuclear decay is the only easy genuine random source available but a bit tricky to include in a little chip at a suitably low cost."

          What about Americium-241 based smoke detectors? We already have widespread, low-cost "nuclear" gear in our homes in this form - why couldn't we use this same technology as an RNG in our computers as well?

          1. Palf

            Re: @ DJO Psudorandomosity

            Too late. NSA hacked Americium-241 a decade ago. They found a backdoor into the weak force.

        2. Nigel 11

          Re: Psudorandomosity

          As far as I know nuclear decay is the only easy genuine random source available

          Completely wrong. Others are thermal noise (in analogue electronics), and turbulence (in airflow). Your audio input jack and hardware can be a very effective random source. For best effect, connect a thermal noise source instead of a microphone: it's trivial to build one from a few discrete electronic components, and power it off a USB port.

          But even a microphone listening to background noise will do. Even if the spooks have a hi-fi uncompressed bug in your office, it won't be recording exactly the same audio stream. The least significant bit per sample will be random, which is quite a reasonable source of entropy to blend into an entropy pool. (If you stick your random noise microphone to your PC's fan grille, it'll be more than one random bit per sample).

          Finally, for an entropy pool you don't need random in the sense of passing all statistical tests for a random source. It just has to be non-reproducible and not remembered by anything. So the "signal" bits of the background noise in your office also qualify to a greater or lesser extent.

      2. the spectacularly refined chap

        Every pseudorandom number generator in existence has a predictable sequence (hint: that's why they have pseudo- in the name).

        No, this is yet another example of equating two distinct concepts - determinism and randomness. It's possible to be completely non-deterministic but still not random. It's the kind of subtlety which is why encryption and related areas are best left to real experts as opposed the "I read a web page once" types. I certainly no expert either but I have studied deeply enough to realise it is a lot more complex than people generally assume.

        A simple everyday example of the difference between the two would be what was found shortly after the introduction of the Euro coins: because the two faces are designed independently (one centrally and one on a national basis) certain Euro coins are not perfectly balanced and so have a slight preference for one side or the other when tossed. The result of an individual toss is still essentially unpredictable but in the long-term a marked bias shows up.

        Tossing such coins thus yields a pseudorandom sequence, even though the individual values remain entirely unpredictable.

        1. Julian Bradfield

          A biased sequence can still be random in some senses. The comment to which you reply is correct: all pseudo-random sequences are deterministic, because that's what the term means: a pseudo-random sequence is an algorithmically produced sequence which passes whatever your favourite statistical tests for randonmess are.

          You're correct that non-determinism and randomness are different: in mathematical modelling of systems, a "non-deterministic" choice is one that is not made by the system of interest, but by its environment: e.g. a vending machine has a non-deterministic choice between receiving a "tea" button press and a "coffee" button press, as which one happens depends on the environment (the user). In theory of computation, a non-deterministic algorithm really means one where all possible choices are explored in parallel; or alternatively, you can take a lucky guess as to which choices you should make.

          "Random" refers either to statistical properties of a sequence - and such a sequence can be a determined thing, just not determined by any computable function - or to a primitive notion of probability. In the probabilistic case, biased outputs are included: for example, if you generate a sequence of bits every second by seeing whether an atom of uranium has decayed in that second, that sequence is, as far as we know, truly random in every probabilistic sense of "random". The ratio of zeroes to ones, however, depends on how much uranium you have. In the algorithmic case, a biased sequence is not random becase it can be compressed - if the string has ten times as many zeroes as ones, then you can trivially compress it by coding sequences of zeroes, and you'll win - but it can still be a random sequence in the probabilistic sense.

          Cryptographers want sequences that are random in both senses.

          1. CliveM

            "A biased sequence can still be random in some senses. The comment to which you reply is correct: all pseudo-random sequences are deterministic, because that's what the term means: a pseudo-random sequence is an algorithmically produced sequence which passes whatever your favourite statistical tests for randonmess are."

            In isolation a biased sequence can't be considered to be random. To quote Knuth, "A distribution is generally understood to be uniform unless some other distribution is specifically mentioned" (TAOCP vol 2 section 3.1).

            As for the meaning of pesudorandom, that simply implies an approximation of randomness. It says nothing about how the sequence in generated.

        2. Jonathan Richards 1

          Pseudorandom != unbiased

          Surely, in the case you present, the *sequence*, e.g. HTHHTHTTTH.... is random, but the *probability* of the next toss being H or T is slightly biased. The point about a pseudorandom generator algorithm is that it's entirely and absolutely predictable. If you set up two, side by side with the same starting parameters, they'll produce exactly the same sequence which however looks (more or less) random.

          That's not the case with the Euro coins. Even in a high-precision coin-tossing machine in a vacuum (patent pending) the sequence is going to vary based on unpredictable (read: random) variables.

  5. IGnatius T Foobar

    This is the case for open source operating systems.

    This, by itself, is the case for open source operating systems such as Linux. They *can't* put a back door in, because it would be quickly spotted by everyone who audits the kernel source (and the rest of the source that makes up a Linux operating system -- yes, we call that Linux too, not silly names like GNU).

    It also pretty much proves that every major closed source operating system absolutely has government back doors in it. If you use Windows, the government has the key to your computer. If you use Apple, the government has the key to your computer. If you use Linux, the government at least has to crack your encrypted communications first.

    1. Anonymous Coward
      Anonymous Coward

      Re: This is the case for open source operating systems.

      Any possible backdoor would be done in such a way as to appear as a bug that grants privilege escalation for plausible deniability. And we all know Linux is notorious for its many, many bugs that the kernel devs should classify as security vulnerabilities, but refuse to do so.

      1. Chemist

        Re: This is the case for open source operating systems.

        "And we all know Linux is notorious for its many, many bugs "

        Oh, it's you again - please go away - this is for adults

    2. Dan 55 Silver badge

      Re: This is the case for open source operating systems.

      I see you attempted to backdoor this thread and I caught you out.

      There are examples of bugs/backdoors/whatever you call them lasting years in open source projects because nobody caught them.

      I'm quite the open source fanboy but I wouldn't go so far as to think it's perfect. Mainly my higher confidence in open source programs is that someone else will find the problems, but if everybody's thinking that...

    3. Anonymous Coward
      Anonymous Coward

      @IGnatius

      "They *can't* put a back door in, because it would be quickly spotted by everyone who audits the kernel source (and the rest of the source that makes up a Linux operating system -- yes, we call that Linux too, not silly names like GNU)."

      So what would happen if someone did spot something out of place in the kernel source?

      Wouldn't it be fair to say that if that person starts asking on the kernel mailing list they'll just get ridiculed and optionally insulted for not understanding the module they're commenting on?

      1. Charles Manning

        Re: @IGnatius

        Wouldn't it be fair to say that if that person starts asking on the kernel mailing list they'll just get ridiculed and optionally insulted for not understanding the module they're commenting on?"

        If someone did spot something they would get a fair audience if they could demonstrate the issue or give a reasonable explanation.

        They would get ridiculed if they continued to press a point that could only be explained by six rolls of tin foil.

Page:

This topic is closed for new posts.

Other stories you might like