User: Password:
Subscribe / Log in / New account

'Drug cocktail' to fix /tmp bugs

'Drug cocktail' to fix /tmp bugs

Posted Dec 18, 2011 17:12 UTC (Sun) by epa (subscriber, #39769)
In reply to: 'Drug cocktail' to fix /tmp bugs by wahern
Parent article: Fixing the symlink race problem

Part of the problem is C's insane rules for silent conversion between signed and unsigned, so if your code is using unsigned int but a library uses signed ints, you must be very careful.

Throwing exceptions (or just aborting) on signed overflow would increase DoS vulnerabilities in the short term. The reason to suggest it is that it would convert subtle and perhaps unnoticed bugs into much more obvious bugs; also that 'fail safe' in the context of software usually means stop execution rather than doing something weird and continuing.

I don't agree that fixing all of Debian is easier than fixing the kernel. Too much new software is being written all the time with the same old vulnerabilities again and again (the LWN security section is witness to that). The choice is either to fix the kernel or to genetically engineer a new super-race of programmers who are immune to mistakes, oversights, or the belief that because a program works when tested then it will still work in the presence of pathological conditions such as an attacker making races.

As for OpenBSD, they sensibly take a belt-and-braces approach to most security issues. For example if your programs do not have vulnerabilities, then PID randomization is not necessary, but they do it anyway. By the same token, fixing every program in Debian is certainly a good idea but it should be as well as putting some defensive measure in the kernel, not a substitute.

(Log in to post comments)

'Drug cocktail' to fix /tmp bugs

Posted Dec 19, 2011 13:54 UTC (Mon) by incase (guest, #37115) [Link]

Actually, fixing all of Debian (I take that as a synonym for "fixing all the software you can find") still does make sense even if the Linux kernel "fixes" this issue: There are still heaps of other Unix systems that might be affected by the same insecure temporary file handling problem, there are lots of systems running older kernels but sometimes (manually compiled) newer applications,....
So in either case, I think the kernel should take measures appropriate to mitigate this attack vector, while applications should be fixed to use more secure access patterns to avoid this problem (both on Linux and on other potentially affected systems).

'Drug cocktail' to fix /tmp bugs

Posted Dec 20, 2011 10:10 UTC (Tue) by epa (subscriber, #39769) [Link]

I thoroughly agree: fix the kernel *and* fix the applications. That's what I intended to say in the earlier post.

But even if for some reason you can't fix the applications, fix the kernel anyway!

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds