3 ms·
Then why is nobody trying to fix the vulnerability at the source ie. userland process?
by kronos29296 9y ago
Then why is nobody trying to fix the vulnerability at the source ie. userland process?
- cyphar 9y agoTo butcher an LWN quote, "there are potentially millions of buggy programs, but only one kernel". It's a measure to prevent a class of exploit, rather than depending on people writing safe C code (which I believe decades of software engineering have proven we are collectively incapable of doing).
- clarry 9y agoThis has nothing to do with the (un)safety of C code. The programs do not have to be buggy at the source level. The compiler is the bug.
- clarry 9y agoTo do that, you need to have a compiler that has the right features, and then you need to recompile all your software.
- PeterisP 9y agoThere exists a fix for the vulnerability at the source, namely, a compiler feature that will add extra code that will "touch" every 4k page of the stack if large amount is allocated. However, for that fix to be useful, every single distribution needs to recompile every single userland package and distribute it to every single user - i.e., instead of downloading a security patch, you need to download a new version of every executable on your hdd.
- loeg 9y agoIt could be limited to only programs that are setuid.
- kronos29296 9y agoCan't the changes be gradually introduced? We change distros every year or reinstall the OS every time a new version of the distro is released. That's a newly compiled set of executables that are being installed every year. If the distro guys just did for the next version (Atleast the guys like Debian, Fedora etc from whom most other distros are derived) wouldn't most systems be protected? It would take a while but it wouldn't take 10 years atleast. Mass adoption is impossible but incremental changes are. If critical executables are patched then we have atleast a partially protected system right? (I am not an expert but this sounds a bit more plausible than breaking the entire userland)