Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for June 20, 2013
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
the application? you wouldn't get that far if you enabled such a feature for the kernel itself ;). just try to compile it with clang's -fcatch-undefined-behavior and watch the fireworks...
'Drug cocktail' to fix /tmp bugs
Posted Dec 16, 2011 13:33 UTC (Fri) by nix (subscriber, #2304)
The signed overflow thing, like the aliasing thing, is a problem that will never go away: it will just slowly retreat into more and more obscure software, while common software that relies on it will just gain -fwrapv in appropriate places because fixing it is too pervasive (just as such software has already gained -fno-strict-overflow).
Posted Dec 17, 2011 0:35 UTC (Sat) by wahern (subscriber, #37304)
Throwing exceptions on signed overflow will probably increase vulnerabilities. I don't think preventing a small number of privilege escalation attacks is worth the cost in dramatically increasing DoS attacks.
The symlink issue is a little disconcerting. It'd probably take less time grepping through the entire Debian source archive for "/tmp" and "TMPDIR", blacklisting stupid apps, and replacing bad code with mkstemp(3) or tmpfile(3), than debating how to hack the kernel to paper over idiocy.
Come to think of it, there is an operating system which takes exactly this approach--fixing classes of vulnerabilities by fixing the code. But the name escapes me at the moment ;)
Posted Dec 17, 2011 1:01 UTC (Sat) by kees (subscriber, #27264)
And for "how to hack the kernel", there's not really much of a debate the way I see it: this has been solved for over a decade already. :P
Posted Dec 17, 2011 2:54 UTC (Sat) by nybble41 (subscriber, #55106)
I doubt that. The difference between signed and unsigned shows up mainly in comparisons. The result of an expression cast to unsigned (e.g. pointer arithmetic) is generally the same whether you use unsigned modulo arithmetic or two's complement. For example, without overflow detection,
uint32_t x = 4294967295; // 2**32 - 1
has exactly the same effect on 32-bit platforms as
int32_t x = -1;
The first version does at least have the marginal advantage that you only need to check the upper boundary, provided the lower boundary is zero.
Posted Dec 18, 2011 17:12 UTC (Sun) by epa (subscriber, #39769)
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.
Posted Dec 19, 2011 13:54 UTC (Mon) by incase (subscriber, #37115)
Posted Dec 20, 2011 10:10 UTC (Tue) by epa (subscriber, #39769)
But even if for some reason you can't fix the applications, fix the kernel anyway!
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds