KHB: Failure-oblivious computing

Posted Jul 4, 2006 8:42 UTC (Tue) by walterh (guest, #19113)
In reply to: KHB: Failure-oblivious computing by evgeny
Parent article: KHB: Failure-oblivious computing

>> Who says that, say, clipping a buffer that
>> is being overrun by an attacker is a safe choice?
>
> If it is not, the program is severely broken in other way(s) as well,
> and this could be exploited without the buffer overrun in the first place;
> so what's your point?

My point is that clipping buffers is worse than just terminating the program -- and I gave examples why this is so. Your assertation that you can safely clip buffers is clearly wrong, as is it not hard to think about otherwise perfectly safe programs that get exploitable if you just clip a buffer somewhere.

KHB: Failure-oblivious computing

Posted Jul 4, 2006 9:02 UTC (Tue) by evgeny (subscriber, #774) [Link] (2 responses)

> it not hard to think about otherwise perfectly safe programs that get exploitable if you just clip a buffer somewhere.

Might be; then do think a bit harder to come with a reasonable example proving it; the ones you suggested are absolutely irrelevant. Let's take the first one: say, a buffer is defined as char buf[5] and the attacker manages to pass to it "Hello, world!" causing an overrun. Now, the failure-oblivious runtime notices this and clips the string to just "Hell" (plus the terminating zero). You say when "Hell" propogates further, it might cause a compromise. It could be of course, but my point is that the attacker could send this "Hell" in the first place, and get a successful exploit anyway, whether the buffer overruns are clipped or not. Such things are called a failure to sanitize user input. Do you follow?

KHB: Failure-oblivious computing

Posted Jul 4, 2006 9:29 UTC (Tue) by walterh (guest, #19113) [Link] (1 responses)

> Might be; then do think a bit harder to come with a reasonable example
> proving it; the ones you suggested are absolutely irrelevant.

Just to show you how relevant these examples are, think about the ACL example again: Say a server has a block list which is consists of a dynamic part supplied by the IDS and a static part supplied by the administrator. Joe Hacker has been put on the static part by the administrator. To get around the block, he injects forged packets into the IDS to grow the dynamic block list to the point where the buffer for the combined block list overruns. Now, as the buffer contains just IP addresses this would result in a program crash enabling a denial of service attack. But, when the buffer just gets clipped so that the static part of the block list is gone, Joe Hacker can get access.

Or, another example: A PHP app checks user+password combinations with the following SQL command:

SELECT * FROM users WHERE user='%s' AND password='%s';

Of course, it will escape and special characters like ' in input. Now Joe Hacker supplies
looooo....ongname'
as username. The ' at the end gets escaped to \'. Assume that due to some buffer magic the last character is clipped. Now the string is
looooo....ongname\
Choosing
or 1=1 limit 1;
for the password the SQL command now becomes

SELECT * FROM users WHERE user='looooo....ongname\' AND password=' or 1=1 limit 1;';

which will let Joe hacker in.

So you can see that is is easy to come up with examples where the technique advertised in the article creates gaping security holes.

To be honest, I think it is very worrying how some people here defend a broken idea. If those are the ones writing critical applications, then there is plenty or reason to be afraid.

KHB: Failure-oblivious computing

Posted Jul 4, 2006 11:11 UTC (Tue) by evgeny (subscriber, #774) [Link]

> Say a server has a block list which is consists of a dynamic part supplied by the IDS and a static part supplied by the administrator.

Well, any seasoned C programmer will notice that this is a very strange coding practice:
1) Why to concatenate the lists instead of checking first the static and then the dynamic part?
2) If the concatenation is for a reason indeed necessary, one'd do it the other way around, thus simplifying the compile-time optimization and run-time memory access patterns.

These alone would suggest the prorgam is badly written and perhaps shouldn't be trusted anyway.

However, a more seriously wrong assumption you made is that in the absence of the buffer clipping _any_ buffer overrun results in SEGFAULT. Alas, this is NOT the case. Otherwise, the issue of the buffer overruns would be considered only in the context of DoS. Instead, we're talking about executing practically anything, including the shell access (which is arguably much worse than failure to throwing a bad guy away right at the entrance). And even if that doesn't happen, an equivalent of the buffer clipping could take place. E.g.,

int main(void)
{
char buf[5];
sprintf(buf, "Hello, world!\n");
printf(buf);
exit(0);
}

works nicely here (i.e., outputting the entire "Hello, world!\n" string), instead of segfaulting. However, were there enough of code between the sprintf() and printf() lines, the result could be very different, including in theory the clipping right after the "Hell" substring, or any other type of garbling.

> Or, another example: A PHP app

All strings in PHP are dynamic... You should use a different language.

> checks user+password combinations with the following SQL command:
>
> SELECT * FROM users WHERE user='%s' AND password='%s';

Oh, just let's not return to this deadly beaten horse. You can read e.g. this nice article (http://lwn.net/Articles/185813/) and the very informative comments to it to understand that constructing an SQL statement directly from the user input is 99.999% garanteed to be vulnerable, even in languages that don't have the string buffer overrun problem.

Your examples above show signs of programming ignorance. On the contrary, the buffer overruns are periodically spotted in very mature pieces, written by very respectable programmers. They're often typos (or off-by-one miscalculations) than real mistakes. I wish libc had functions to deal with strings in a safe manner. sigh...

> To be honest, I think it is very worrying how some people here defend a broken idea.

Nobody said this is a silver bullet. As practically any other technique, it has a restricted area of applicability. (E.g., as mentioned in the original article, it certainly shouldn't be used in the scientific computing).