Symbolic links in "sticky" directories
Posted Jun 3, 2010 10:35 UTC (Thu) by nix
Parent article: Symbolic links in "sticky" directories
But some kernel hackers are not convinced that the core kernel should be fixing badly written applications.
I haven't seen anyone mentioning this, which is good, because anyone who did would be a fool. The 'badly written' code in question works perfectly well and securely everywhere except
in writable-by-attacker directories (which pretty much means sticky-bitted ones in practice), so what we really have here is a Unix API which works fine everywhere except in /tmp, and appears to work even there. Are we surprised that developers don't notice this? It's an API that requires extra effort to use correctly, and whose failure is invisible until a malicious attacker exploits it: of course they get it wrong!
Also, as you pointed out, fixing every application (including all the binary-only ones) or educating every single developer is impractical: it hasn't happened in decades and we couldn't get everyone to upgrade even if we did fix it. At least if the kernel was blocking this we'd only need to get people to upgrade to that kernel once, and then this class of problems would be history.
(I just checked at my workplace, where fifty-odd developers write Unix financial server apps. Not one of them knew what TOCTTOU races were. A single one had heard of symlink attacks in /tmp, but wasn't clear how you avoided them. More than half of them had written code that writes to /tmp for one reason or another. If we are trying to fix this by educating developers, we are failing.)
to post comments)