They used to call this a computer virus.
Or any clown with access to Intel Management Engine module signing keys.
If you know, than you know why RISCV was fast-tracked in some places... =3
Trusting-Trust Attack against an Entire Linux Distribution
51–60 of 65 posts
Re: Trusting-Trust Attack against an Entire Linux Distribution
#52Earlier quoted context omitted.
Break expectations. Bootstrap it through an esoteric-enough system. Write an Uxn emulator in assembly targeting the cushy environment that UEFI has and you've got a system with graphics, a text editor, a spreadsheet editor, an assembler, games, and maybe even more. I have a Z80-powered email appliance that can be loaded with programs from a connected device. Whoever is breaking my trust in trust surely won't have pla…
but now they will via delegation to an automated analyst/systems programmer. get ready. the effort required for a complete infiltration has been lowered a great deal.
This automated analyst isn't going to be able to run usefully on hardware that is still otherwise useful, giving you a clear path to choke it out or identify its presence when your hello world is taking 3 months to finish compiling.
Re: Trusting-Trust Attack against an Entire Linux Distribution
#53Earlier quoted context omitted.
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.
>The paper is not about implementing a general attack that works on all trusting-trust mitigations.
Then why have section 7.3 'Bootstrappable Builds', that briefly surveys a type of trusting-trust mitigation, and concludes that their method "sustains the attack [...], even after the compiler seed shrinks to a few hundred bytes"?
>It is precisely about showing that you can still propagate backdoored code if the compromised binary in your seed is NOT the compiler.
Whatever this paper is about, it is certainly not precisely about it. But quibbles aside, if that truly is what the authors set out to show, they should probably re-read the transcript, where Ken says "[For demonstration purposes], I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode."
Re: Trusting-Trust Attack against an Entire Linux Distribution
#54Earlier quoted context omitted.
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.
At that point maybe they'll just knock you out and torture you for whatever secrets instead
Re: Trusting-Trust Attack against an Entire Linux Distribution
#55Earlier 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.
You can construct a CPU out of an EEPROM, a clock, and a few latches. Connect it to an immediate mode display with a serial interface that doesn't care about being clocked slowly, connect up a buzzer or some blinkenlights for output when you're exceptionally paranoid and can't trust the display controller, make a basic keyboard with a rubber sheet, some wire, and some glue, poke a keyboard driver and a line editor into memory with your DIP switches, crank the clock up to kilohertz (so the keyboard latency is tolerable), and you too can bootstrap a cross-compiler! (Though be aware that the radio interference will be enough for a committed attacker to figure out what you're computing, unless you take measures against that.)
But they're not going to backdoor an Apple ][e, or a random 80m¢ microcontroller, for basically any value of "they"; so you can just use one of those instead, and save yourself the hassle.
Re: Trusting-Trust Attack against an Entire Linux Distribution
#56This is basically an ELF executable file infecting virus, nothing novel about that.
Generally speaking, Linux doesn't suffer from ELF-executable-file-infecting viruses in practice, because most random executables aren't run with root permissions, so they don't have permission to write to widely-executed executables, which you install from the package system.
However, anything in the build toolchain that someone uses to build those widely-executed executables necessarily does have permission to write to them!
This is certainly not novel, having been the subject of a Turing Award speech, but it is something that many people haven't thought through.
Re: Trusting-Trust Attack against an Entire Linux Distribution
#57Earlier quoted context omitted.
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.
> It is precisely about showing that you can still propagate backdoored code if the compromised binary in your seed is NOT the compiler.
But that seems like quibbling about semantics. Thompson says that if a compromised binary generates a binary, you cannot trust the generated binary.
This does not even have to be gcc, it could be vim. Or strip. Or cat. Or dd.
Or an iop to write data to persistent storage if the firmware of your SSD is compromised.
Re: Trusting-Trust Attack against an Entire Linux Distribution
#58Earlier 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.
You can construct a CPU out of an EEPROM, a clock, and a few latches. Connect it to an immediate mode display with a serial interface that doesn't care about being clocked slowly, connect up a buzzer or some blinkenlights for output when you're exceptionally paranoid and can't trust the display controller, make a basic keyboard with a rubber sheet, some wire, and some glue, poke a keyboard driver and a line editor in…
I like the way you think, a true MacGyver-style problem solving.
Re: Trusting-Trust Attack against an Entire Linux Distribution
#59Earlier 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.
By doing it.
Individual cpu instructions, even of a crude old 8-bit cpu with no embedded minix os like today, are both simple enough for a human to manually understand what they do, and useful enough to build crude versions of useful things like an editor, interpreter, or compiler.
You can write a forth-like language or even a c-like language starting from individual cpu instructions that a human can read, understand, and write totally manually, and then use that to build up rapidly all the way to a full modern desktop.
If you were really paranoid about the very act of the initial typing-in, there are any number of ways to store data in a totally brainless eprom or record it to tape or something, and examine it with nothing but some leds, no cpu at all, to verify the bytes are the bytes you want. And you only need to do that for a pretty small number of initial bytes. After that it's all just regular source code which could be written on paper.
Bootstrapping is only an inconvenience problem, not a real problem.
It's not convenient for most people to assemble some bytes into some storage medium and then verify them without simply using a normal untrust-able computer to do it. But it's no problem really if you had some reason to be that careful.
Re: Trusting-Trust Attack against an Entire Linux Distribution
#60FYI, x86_64-linux and i686-linux nixpkgs bootstrap seed is not 25 bundled binaries, but 181 bytes, since https://github.com/NixOS/nixpkgs/pull/479322 . at publication date this article would apply to non-x86 platforms like aarch64-linux, risvc64-linux, etc. if you're concerned about this and not on x86, i encourage you to extend this to other platforms! i believe it's possible to generalize this to every linux platfo…
Hi, I'm the author of the PR. Work is currently underway to bootstrap other platforms through cross-compilation. I'm hoping to construct native bootstraps to the two platforms you've mentioned later as well.