User: Password:
Subscribe / Log in / New account

'Drug cocktail' to fix /tmp bugs

'Drug cocktail' to fix /tmp bugs

Posted Dec 16, 2011 13:33 UTC (Fri) by nix (subscriber, #2304)
In reply to: 'Drug cocktail' to fix /tmp bugs by PaXTeam
Parent article: Fixing the symlink race problem

Hah. Forget the kernel: bugs are still being found in GCC itself where the compiler either contains examples of signed overflow, or introduces signed overflows during optimization. (The most recent example I'm aware of is PR51247, fixed just last month.)

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).

(Log in to post comments)

'Drug cocktail' to fix /tmp bugs

Posted Dec 17, 2011 0:35 UTC (Sat) by wahern (subscriber, #37304) [Link]

You're probably right--it will never go away. The easiest way to fix signed overflow is to not use signed integers. Yet people continue to use (int) and (long) reflexively. Java doesn't even have unsigned integers, just for purities sake. The C++ crowd still debates whether size_t is better than a signed integer. Never mind that in real-life signed arithmetic is rare. SLoC-for-SLoC, the vast majority of arithmetic is mundane management of data for which negative numbers are unnecessary and awkward, and where unsigned overflow is usually entirely and reliably benign. It's even often a negative feedback effect--by using modulo arithmetic you thwart someone trying to overflow your buffers by producing the opposite result. Finally, corruption isn't much of an issue because garbage in is garbage out; no software can fix that.

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 ;)

'Drug cocktail' to fix /tmp bugs

Posted Dec 17, 2011 1:01 UTC (Sat) by kees (subscriber, #27264) [Link]

The problem is needing to continually scan all the software because /tmp junk _keeps_ getting added. :(

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

'Drug cocktail' to fix /tmp bugs

Posted Dec 17, 2011 2:54 UTC (Sat) by nybble41 (subscriber, #55106) [Link]

> by using modulo arithmetic you thwart someone trying to overflow your buffers by producing the opposite result

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,

char *buffer;
uint32_t x = 4294967295; // 2**32 - 1

has exactly the same effect on 32-bit platforms as

char *buffer;
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.

'Drug cocktail' to fix /tmp bugs

Posted Dec 18, 2011 17:12 UTC (Sun) by epa (subscriber, #39769) [Link]

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.

'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 © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds