Does kernel 2.6 include an NSA backdoor? - Setup

This is a discussion on Does kernel 2.6 include an NSA backdoor? - Setup ; Nico writes: > We're not talking about a module that is that unusual: the "password" > module is antique, and quite stable. All the Trojan had to really know > was the name of the module. We were also talking ...

+ Reply to Thread
Page 9 of 9 FirstFirst ... 7 8 9
Results 161 to 170 of 170

Thread: Does kernel 2.6 include an NSA backdoor?

  1. Re: Does kernel 2.6 include an NSA backdoor?

    Nico writes:
    > We're not talking about a module that is that unusual: the "password"
    > module is antique, and quite stable. All the Trojan had to really know
    > was the name of the module.


    We were also talking about detecting (or at least disabling) the compiler
    trojan by compiling different compilers with each other.
    --
    John Hasler
    john@dhh.gt.org
    Dancing Horse Hill
    Elmwood, WI USA

  2. Re: Does kernel 2.6 include an NSA backdoor?

    John Hasler wrote:
    > Nico writes:
    >> We're not talking about a module that is that unusual: the "password"
    >> module is antique, and quite stable. All the Trojan had to really know
    >> was the name of the module.

    >
    > We were also talking about detecting (or at least disabling) the compiler
    > trojan by compiling different compilers with each other.


    Well, yeah, that could occur as a natural result of such efforts if the
    *uninfected* compiler is the root compiler from which the other descend. But
    unless you're lucky, or code drift occurs, I'd expect the first infected
    compiler to act like that first kid in the boy's locker room with athlete's
    foot and infect just about everyone until the realize the steps they need to
    take to control it.

  3. Re: Does kernel 2.6 include an NSA backdoor?

    Nico writes:
    > We're not talking about a module that is that unusual: the "password"
    > module is antique, and quite stable. All the Trojan had to really know
    > was the name of the module.


    I wrote:
    > We were also talking about detecting (or at least disabling) the compiler
    > trojan by compiling different compilers with each other.


    Nico writes:
    > Well, yeah, that could occur as a natural result of such efforts if the
    > *uninfected* compiler is the root compiler from which the other descend.


    _Different_ compilers, not successive revisions of Pcc. Do you really
    think that you could write a trojan that would infect a compiler written
    from scratch by someone who'd never seen the source for your compiler after
    your trojan was released?
    --
    John Hasler
    john@dhh.gt.org
    Dancing Horse Hill
    Elmwood, WI USA

  4. Re: Does kernel 2.6 include an NSA backdoor?

    John Hasler wrote:
    > Nico writes:
    >> We're not talking about a module that is that unusual: the "password"
    >> module is antique, and quite stable. All the Trojan had to really know
    >> was the name of the module.

    >
    > I wrote:
    >> We were also talking about detecting (or at least disabling) the compiler
    >> trojan by compiling different compilers with each other.

    >
    > Nico writes:
    >> Well, yeah, that could occur as a natural result of such efforts if the
    >> *uninfected* compiler is the root compiler from which the other descend.

    >
    > _Different_ compilers, not successive revisions of Pcc. Do you really
    > think that you could write a trojan that would infect a compiler written
    > from scratch by someone who'd never seen the source for your compiler after
    > your trojan was released?



    Would you please go *READ* http://cm.bell-labs.com/who/ken/trust.html ? Rather
    than theorizing in unfamiliar terms? The key is that the *function* being
    compiled remains consistent amon gthe different compilers. Many compilers have
    very similar source code for such old utilities as password handling, code
    that is likely to have the same potential vulnerability.

  5. Re: Does kernel 2.6 include an NSA backdoor?

    I wrote:
    > We were also talking about detecting (or at least disabling) the compiler
    > trojan by compiling different compilers with each other.


    Nico writes:
    > Well, yeah, that could occur as a natural result of such efforts if the
    > *uninfected* compiler is the root compiler from which the other descend.


    I wrote:
    > _Different_ compilers, not successive revisions of Pcc. Do you really
    > think that you could write a trojan that would infect a compiler written
    > from scratch by someone who'd never seen the source for your compiler after
    > your trojan was released?
    > Many compilers have very similar source code for such old utilities as
    > password handling, code that is likely to have the same potential
    > vulnerability.


    Nico writes:
    > Would you please go *READ* http://cm.bell-labs.com/who/ken/trust.html ?


    I read it when it was first published.

    > The key is that the *function* being compiled remains consistent among
    > the different compilers. Many compilers have very similar source code for
    > such old utilities as password handling, code that is likely to have the
    > same potential vulnerability.


    I'm talking about the _compiler_ trojan. Thompson's code would have a hard
    time even recognizing that it is compiling a compiler, let alone
    successfully linking in a working copy of itself when compiling a compiler
    such as Gcc.

    Thompson's scheme is a valid concern for people who bought a set of Unix
    tapes (or Linux CDs), reviewed the source code for trojans, and then went
    on to compile "safe" binaries from the source they had reviewed using
    vendor-supplied binaries of that same source.
    --
    John Hasler
    john@dhh.gt.org
    Dancing Horse Hill
    Elmwood, WI USA

  6. Re: Does kernel 2.6 include an NSA backdoor?

    On 2008-03-08, Jean-David Beyer wrote:
    > The Natural Philosopher wrote:
    >>
    >> You will get some damned funny results if for example you use a compiler
    >> trying to inject its own network access when you replace the standard
    >> network access library stuff with something you have written yourself
    >> for custom hardware. And shove it on a hardware debugger.
    >>
    >> You can't subvert EVERYTHING to not notice unwarranted network access.
    >>
    >>
    >> Fer chrissakes, even a semi decent firewall with packet logging is
    >> going to notice that socket calls to unknown addresses are taking place.
    >>
    >>
    >>

    > Yes, if you trust the firewall. You keep moving the target which is the
    > trust of the bootstrapping process.
    >


    No, it's not moving the target. You're proposing a compromise scenario
    that requires multiple targets to be compromised. The compiler has to
    be comprimised, the network utilities have to compromised, the firewalls
    have to be compromised... That's the point. That's why it's unlikely.


    --
    Christopher Mattern

    NOTICE
    Thank you for noticing this new notice
    Your noticing it has been noted
    And will be reported to the authorities

  7. Re: Does kernel 2.6 include an NSA backdoor?

    Chris Mattern wrote:
    > On 2008-03-08, Jean-David Beyer wrote:
    >> The Natural Philosopher wrote:
    >>> You will get some damned funny results if for example you use a compiler
    >>> trying to inject its own network access when you replace the standard
    >>> network access library stuff with something you have written yourself
    >>> for custom hardware. And shove it on a hardware debugger.
    >>>
    >>> You can't subvert EVERYTHING to not notice unwarranted network access.
    >>>
    >>>
    >>> Fer chrissakes, even a semi decent firewall with packet logging is
    >>> going to notice that socket calls to unknown addresses are taking place.
    >>>
    >>>
    >>>

    >> Yes, if you trust the firewall. You keep moving the target which is the
    >> trust of the bootstrapping process.
    >>

    >
    > No, it's not moving the target. You're proposing a compromise scenario
    > that requires multiple targets to be compromised. The compiler has to
    > be comprimised, the network utilities have to compromised, the firewalls
    > have to be compromised... That's the point. That's why it's unlikely.
    >
    >

    Not really. Once you compromise the _su_ program or the _login_ program, you
    can do anything you want.

    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 14:00:01 up 3 days, 20:01, 2 users, load average: 4.50, 4.48, 4.43

  8. Re: Does kernel 2.6 include an NSA backdoor?

    In comp.security.misc plenty900@yahoo.com wrote:
    > I've learned that there are bits of NSA's SELinux in various
    > places in kernel 2.6. How can I be sure that Big Brother isn't
    > using back doors or bugs to break into my computer?


    You can't. You have to trust in people reading the source code detecting
    what's going on.

    > How much safer would it be to just switch back to 2.4 or 2.5?


    I cannot see any safety in it.

    Yours,
    VB.
    --
    The file name of an indirect node file is the string "iNode" immediately
    followed by the link reference converted to decimal text, with no leading
    zeroes. For example, an indirect node file with link reference 123 would
    have the name "iNode123". - HFS Plus Volume Format, MacOS X

  9. Re: Does kernel 2.6 include an NSA backdoor?

    On 2008-03-11, Volker Birk wrote:
    > In comp.security.misc plenty900@yahoo.com wrote:
    >> I've learned that there are bits of NSA's SELinux in various
    >> places in kernel 2.6. How can I be sure that Big Brother isn't
    >> using back doors or bugs to break into my computer?

    >
    > You can't. You have to trust in people reading the source code detecting
    > what's going on.
    >
    >> How much safer would it be to just switch back to 2.4 or 2.5?

    >
    > I cannot see any safety in it.
    >

    Bingo. If you're paranoid, you can see the possibility of being
    pwned by anything (and I'm not saying such paranoia is completely
    wrong). But if you're asking if SELinux makes it more likely,
    the answer has to be no. The risks, like a trojan compiler,
    that have been discussed here are no riskier for SELinux
    than for ealier Linux editions.

    --
    Christopher Mattern

    NOTICE
    Thank you for noticing this new notice
    Your noticing it has been noted
    And will be reported to the authorities

  10. Re: Does kernel 2.6 include an NSA backdoor?

    On Mar 5, 1:06 pm, Moshe Goldfarb wrote:

    > Yea they can and they will, but you can avoid it by being honest.


    Moshe, isn't that a little like saying you can avoid Hitler's wrath
    by being a good Jew who does what Hitler says to do?


+ Reply to Thread
Page 9 of 9 FirstFirst ... 7 8 9