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

21–30 of 65 posts

Re: Trusting-Trust Attack against an Entire Linux Distribution

#21

Post by mmooss »

nickpsecurity wrote: post #13

The solution to this in the Orange Book (TCSEC) days in the 1980's-1990's was a system fully traceable from requirements to code, proven to embed a security policy, and analyzable and buildable from source locally by the customer using existing, trusted tools. Eventually, people added hashes for the code and data. So, your program that combines source files or checks dependencies would be fully specified in its succe…

> 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 more software, and can focus on quality. Also, LLM attackers create demand for higher quality.

In other words, LLMs might enable us to some of these things that were impossible before.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#22

Post by gleenn »

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…

Works until AI compromises a bunch of OSes. And wouldn't there be difficulty comparing binaries built from significantly different environments? It sounds like some progress has been made in general for fixed identical builds, but isn't that also still a hard problem? I don't know enough low level C-level stuff about binary generation.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#23

Post by fjfaase »

FYI, I reviewed the live-bootstrap project that starts with a small seed. For a T-diagram that shows all processes being executed in stage0, have a look at [1]. I did work on a solution that requires less steps, but starts with a bit larger seed (though maybe documented a bit better), see [2] and [3] for the T-diagram. Also has targets for x86_64 and arm64. (Work on RISC-V has started.)

[1] https://fransfaase.github.io/Emulator/tdiagram.html

[2] https://fransfaase.github.io/MES-replacement/

[3] https://fransfaase.github.io/MES-replacement/Tdiagram.html

Re: Trusting-Trust Attack against an Entire Linux Distribution

#24

Post by nulltrace »

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.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#26

Post by cpburns2009 »

jacquesm wrote: post #11
cpburns2009 wrote: post #7

Earlier quoted context omitted.

Script kiddies have always been a problem you have to defend against. This is nothing new.

Script kiddies will soon have capabilities that nation states once upon a time could only dream of.

That's largely true of most technology available today. You can buy a cheap $100 phone that's more powerful than old super computers.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#27

Post by fwlr »

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 true even when the seed shrinks to 0 bytes, or shrinks to a negative number of bytes, or shrinks into a miniature poodle and tap-dances across your keyboard.

The question that should have been addressed is “does the tampered instance participate in the build?”, and the whole point of these minimal-byte “seed” bootstraps is that they are just enough bytes of executable to do everything else from the source. So, no, the tampered instance won’t be participating in the build. We might even deploy our own tautology and say that if a pre-existing tainted binary participates in a build, then that build was not a bootstrap build, and therefore all bootstrap builds are in fact perfectly and definitionally immune to the attack.

Honestly, this whole paper kinda reads like an academic version of a slop CVE.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#28

Post by wizzwizz4 »

gleenn wrote: post #22
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…

Works until AI compromises a bunch of OSes. And wouldn't there be difficulty comparing binaries built from significantly different environments? It sounds like some progress has been made in general for fixed identical builds, but isn't that also still a hard problem? I don't know enough low level C-level stuff about binary generation.

> 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 2), and compare the stage 2 artefacts. Provided that your comparison program is known-good, and the stage 2 build is deterministic (not the case for some real-world programs, but true for things like tcc), this lets you verify that the two compilation procedures work identically.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#29

Post by OroPla »

Legend2440 wrote: post #3
shevy-java wrote: post #2

In other words: AI can not be trusted.

Nothing about this uses AI in any way. I'm so tired of people injecting it into every conversation.

Is it a stretch to imagine a compromised LLM writing compromising code? I've been operating under the assumption that LLM code might be bad and not working, but I hadn't thought about it compromising a system.

Re: Trusting-Trust Attack against an Entire Linux Distribution

#30

Post by gleenn »

wizzwizz4 wrote: post #28
gleenn wrote: post #22

Earlier quoted context omitted.

Works until AI compromises a bunch of OSes. And wouldn't there be difficulty comparing binaries built from significantly different environments? It sounds like some progress has been made in general for fixed identical builds, but isn't that also still a hard problem? I don't know enough low level C-level stuff about binary generation.

> 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.
Post reply on HN