3 ms·
Seirdy's article is mostly focused on bug-finding in the binary domain, by fuzzing, memory analysis, decompiling and other techniques. He makes the entirely cor
by nonrandomstring 5y ago
Seirdy's article is mostly focused on bug-finding in the binary
domain, by fuzzing, memory analysis, decompiling and other techniques.
He makes the entirely correct observation that having source to audit
is only one part of thorough debugging, because many exploits are only
manifest at runtime in the context of specific hardware, operating
systems, and build chains.
Seirdy does not denigrate source auditing as some interpretations of
his words here seem to say. This feels like quite a mature article and
there are implications he touches on but doesn't fully explore like
Thompson's "Trusting trust" rabbit hole of the "malicious compiler"
and the fact that security by obscurity has some serious clout if you
can compile for non-standard hardware. The Non Specific Agency may
have a zero-day for your Debian package, but it won't irk the program
on your FPGA emulated Fairchild F8 Microprocessor.
- Seirdy 5y ago(am author) I'm actually going to touch on that Ken Thompson article in a follow-up about how sandboxing can improve not just security, but user freedom/control too (if implemented a certain way). It'll go over how software itself should be considered untrusted (citing Thompson); however, even if it is "trusted", it still might consume untrusted content (often by reading data from arbitrary files or the network). Part of what it means to use free software IMO is having less dependence on a vendor, and reducing trust is one of multiple things that can work in that direction.