11–20 of 65 posts
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 platform musl itself supports, in time.
So, your program that combines source files or checks dependencies would be fully specified in its success and failure states. Only combinations of functions leading to a provably-secure state are even allowed. If you can't do that, the feature is too complex to allow. Human pentesters review it from design to algorithms to building it to spot ways attacks might happen.
That's what it takes to build software that usually resists subversion. Most software isn't built that way. It can't be because the priorities of developers and customers work against it. So, we'll continue to see clever attacks that exploit systems not designed to high security standards.
For this topic, I recommend David A. Wheeler's page on Software, Configuration Management Security because it covers many issues with it in mostly-centralized systems.
From TFA: > Ken Thompson's trusting-trust attack [...] is widely regarded as a threat specific to compilers. We show that it is not And yet, from Reflections On Trusting Trust : > In demonstrating the possibility of this kind of attack, 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. The paper is certainly a nice worked-out ex…
Ken Thompson's Trusting Trust is an interesting conundrum... there are ways to minimize the need to trust however, if you can express everything in the same language or common runtime:
you could backdoor not only the strip command but alot of other commands that work on elf binaries: strings, strace, objdump, nm, ldd, etc
Earlier quoted context omitted.
AI could enable script kiddies to pull this off.
Script kiddies have always been a problem you have to defend against. This is nothing new.
It would take at least some knowledge to hack, not just a random script from a forum.
Now, with LLMs, it's the '90s all over again.
Earlier quoted context omitted.
Script kiddies have always been a problem you have to defend against. This is nothing new.
Yes and no. We used to have rampant script kiddies back in the '90s and early 2000s. After 2005-ish, well maybe 2010, most systems became adequate enough to not trust users' input, bug bounties, security as a separate role, etc, etc. It would take at least some knowledge to hack, not just a random script from a forum. Now, with LLMs, it's the '90s all over again.
If its easy enough to find exploits, its likely similarly easy to scan code for exploits, or use AI-based anti-virus technologies. The only thing holding us back is the cost of compute. We can't all run the latest models against everything.