Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trusting-Trust Attack against an Entire Linux Distribution

arxiv.org

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Trusting-Trust Attack against an Entire Linux Distribution

#41

Post by mmooss »

nickpsecurity wrote: post #34
mmooss wrote: post #21

Earlier quoted context omitted.

> Most software isn't built that way. It can't be because the priorities of developers and customers work against it. The most significant such priority may be the costs of paying developers and of time to delivery. The dramatic reductions in those costs due to LLMs enable us to produce much more quantity and/or quality. Many complain now about quantity, so perhaps we are finally at a stage where we don't need much m…

It's very exciting to see the work on combining AI models with static analysis, test generation, formal proof, and refactoring. All of these suggests we might see high assurance (EAL6+) developed rapidly in the future. At least for combinations of well-understood concepts.

You don't mention generating code from scratch; is that on purpose? Perhaps a developer could add many constraints that would have been too expensive previously - e.g., code in Spark, use only these ___ system calls, never use this riskier capability, use only these ___ libraries, etc.

The LLM might take longer than otherwise, but still be fast enough. The new technology, like every useful one, changes the tradeoff equation.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#42

Post by krater23 »

27 years ago we named this link virus. It worked well on DOS, Windows and on every other OS where the user who executed a infected file had enough access rights to change other executables.

But this one is crippled because there is only one file that can infect other files.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#44

Post by krater23 »

nulltrace wrote: post #24
charcircuit wrote: post #5

This paper can be boiled down to: If you have malware on your CI machine it can infect the artifacts it creates. In this paper the malware was a strip trojan, but it could have been just as well a normal piece of malware which starts a service and then waits for the final artifact to be generated after which it infects it.

Rebuilding strip from clean source doesn't clear it. The copy in the bootstrap seed modifies its replacement, and the replacement carries on from there. The provenance can still look normal.

Rebuilding from clean source on a infected device. Whats the point? Could be every computer virus from 30 years ago.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#45

Post by PhilipRoman »

gleenn wrote: post #30
wizzwizz4 wrote: post #28

Earlier quoted context omitted.

> Works until AI compromises a bunch of OSes. Just write a new OS. It's a weekend project to get enough groundwork that you can bootstrap a clean system from clean source code. > And wouldn't there be difficulty comparing binaries built from significantly different environments? Not really. Starting from stage 0, compile the compiler under test (stage 1), then use the compiled compiler to compile the compiler (stage…

Not sure if you're joking. How do you write an OS without these tools that might be compromised? It's the same problem.

Write a subleq interpreter with a magnet and a steady hand? (Hopefully the magnet is not compromised)

Re: Trusting-Trust Attack against an Entire Linux Distribution

#47

Post by cure_42 »

PhilipRoman wrote: post #45
gleenn wrote: post #30

Earlier quoted context omitted.

Not sure if you're joking. How do you write an OS without these tools that might be compromised? It's the same problem.

Write a subleq interpreter with a magnet and a steady hand? (Hopefully the magnet is not compromised)

I am trying to imagine how the magnet could be compromised. Could you theoretically embed an electromagnetic and a controller within a decoy magnet and somehow detect what was being recorded and subvert it? Probably not but... No, just probably not.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#48

Post by signa11 »

tenthirtyam wrote: post #46

"Coding Machines" from 2009 is an excellent short story describing the Trusting Trust attack. https://www.teamten.com/lawrence/writings/coding-machines/

iirc mr. adam-gordon-bell did a podcast on this, it is quite nice actually.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#49

Post by yayachiken »

fwlr wrote: post #27
Jach wrote: post #8

I'm glad they mention Wheeler's work briefly in section 7.2, since it provides a general counter to the trusting-trust attack that a lot of people seem to not know about. They dismiss it as not applying in this case, but I'm not really convinced by their argument. It's true if you only replace the compiler and run in the same environment then it won't help, but IIRC Wheeler's approach treats the environment itself as…

I also think they’ve shortchanged the bootstrap build mitigation. They write: A utility such as strip sustains the attack whenever a tampered instance participates in the rebuild, even after the compiler seed shrinks to a few hundred bytes. Well, yes, if you presuppose your modified binary is used, then you will find that your attack continues, but that’s only because “P iff P” is a logical tautology. It would be tru…

The paper is not about implementing a general attack that works on all trusting-trust mitigations.

It is precisely about showing that you can still propagate backdoored code if the compromised binary in your seed is NOT the compiler.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#50

Post by wood_spirit »

Jach wrote: post #8

I'm glad they mention Wheeler's work briefly in section 7.2, since it provides a general counter to the trusting-trust attack that a lot of people seem to not know about. They dismiss it as not applying in this case, but I'm not really convinced by their argument. It's true if you only replace the compiler and run in the same environment then it won't help, but IIRC Wheeler's approach treats the environment itself as…

I’ve never found Wheeler’s approach very satisfying. It says “we can’t trust the compiler, so here’s a second compiler.” But I think it is too literal interpretation of Thompson’s attack and it is just moving goalposts not really stopping the essence of the attack. The viruses of the 1990s got so advanced they regularly intercepted the read calls and stripped their payload from inspection so hiding themselves, and you could imagine in the playpen where we think we trust some other external compiler we must also think we trust the read functions on the compromised machine etc. Thompson was thinking at a higher level than this.
Post reply on HN