|
|
Log in / Subscribe / Register

Quotes of the week

[Posted September 10, 2015 by corbet]

Seriously. When was the last time you heard somebody complain about "I wrote the number 9223372036854775809, and the computer thought I meant '1' - I'm really really upset"
— Linus Torvalds

Documentation can [be], and often is, wrong. The code that has been there for more than two decades determines what the interface and semantics actually are.
— David Miller
to post comments

Quotes of the week

Posted Sep 11, 2015 6:48 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

Gosh, if I understood Linus right, not doing any overflow checking on integer parsing sounds a bit shortsighted. Well, maybe it might make sense in the kernel, but certainly not in general.

For example: suppose you are parsing the output of 'git cat-file --batch' on a 32-bit system. Git writes text output with a count of bytes and then the blob content. All an attacker has to do is prepare a git repository with object size bigger than the maximum int size and you have a memory trampling attack. If scanf("%d") did some reasonable checking that the number being parsed fits in an int, this whole class of attacks would be closed off.

Linus points out that if the attacker can pass a text string with a huge number which overflows, the attacker can equally pass the small post-overflow number directly. But that's missing the point. There will be cases where the text string isn't directly provided by the attacker but there is nonetheless a way for them to arrange for an exploitable overflow to occur, as in the git cat-file example above.

Quotes of the week

Posted Sep 11, 2015 6:58 UTC (Fri) by epa (subscriber, #39769) [Link]

...Well, that example may be a bit far-fetched, since the code parsing git output would have to be quite unusually written (allocate a fixed size buffer and then just keep reading and reading until EOF). But the principle is valid I think.

Or consider a system which first validates a set of text parameters to make sure it is not crazy - "maximum 1000 blargs are allowed" - before passing them on to the code which does the work. If the validation code parses a 32-bit int, then the attacker could specify the number of blargs with a large text string which overflows to 1000 when parsed as int32. Then the calculation engine receives the parameter set and parses it using slightly different rules (perhaps it is built as 64-bit) and uses an excessively large number of blargs. Again, the fact the the attacker could have specified the string '1000' directly is irrelevant.

Quotes of the week

Posted Sep 11, 2015 10:55 UTC (Fri) by HIGHGuY (subscriber, #62277) [Link]

There's another must-read quote in there:

>Too much "I know better than you" is actually a bug.
[Linus Torvalds]

I *do* care about integer overflow

Posted Sep 11, 2015 19:53 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link] (3 responses)

> "I wrote the number 9223372036854775809, and the computer thought I meant '1' - I'm really really upset"

I *do* care. If the kernel got 9223372036854775809, and that is not supported, then something has gone TERRIBLY WRONG in the calling app. It's very helpful if the kernel actually replied with an error, instead of blithly replacing one number with another; it simplifies debugging (because the problem is reported sooner) and it reduces the risk that the "wrong" thing happens. Also, perhaps a future version of the kernel may actually support 9223372036854775809; if it previously interpreted it as 1, that's a quiet interface change (ugh!), while switching from "error" to quietly supporting the bigger range is typically a non-problem.... and it's easy to detect when you're running on an older kernel.

And yes, security vulnerabilities really do happen often from integer overflows, it's CWE-190: https://cwe.mitre.org/data/definitions/190.html

I *do* care about integer overflow

Posted Sep 12, 2015 1:01 UTC (Sat) by zlynx (guest, #2285) [Link] (2 responses)

The point I got from Linus was that if your code has a problem with a number being out of range then IT HAD BETTER CHECK THAT NUMBER.

Not rely on the integer parser to do it.

I *do* care about integer overflow

Posted Sep 14, 2015 3:37 UTC (Mon) by gutschke (subscriber, #27910) [Link]

Yes, it is certainly a good thing in general for the caller of the number parser to verify the input. Unfortunately, very few people go to the trouble of doing so, as the existing APIs make it so incredibly tedious to tell whether an overflow happened.

Linus used "scanf()" as an example. Honestly, off the top of my head, I wouldn't even know how to write code that securely uses "scanf()" and checks that no unexpected overflow happened, while still allowing the special case of using negative numbers as a short-hand for setting all the leading bits. If you give me half an hour, I am sure I could write code that does this, and write enough unit tests to convince me that I hopefully got it right. But realistically, who is going to do this each and every time.

Other APIs such as "strtoul()" work better in this situation, but even they require several lines of C code to do the right thing; and all of this is potentially security-sensitive code that has lots of subtle corner cases and is easy to get wrong.

I *do* care about integer overflow

Posted Sep 14, 2015 20:40 UTC (Mon) by robbe (guest, #16131) [Link]

But isn't it too late when the (kernel) caller of scanf() checks for overflow ... as it already happened.

I'm with David on this. Say you wrote this nice grenade-priming driver. It can be triggered by writing an integer N to /proc/explode_in, uses this scanf() interface to parse the string "N" into an integer, and then set the grenade to blow up in N seconds.

Only root can write to the explode_in file, so someone cobbles together some suid-root code that first checks if the given delay is "safe", i.e. larger than 15 seconds, then passes the value on to the kernel. 9223372036854775809 is bigger than 15, so we're goo<boom>

Quotes of the week

Posted Sep 14, 2015 8:52 UTC (Mon) by granquet (guest, #60931) [Link]

Read The Fucking ... Code?

Quotes of the week

Posted Sep 29, 2015 8:12 UTC (Tue) by kevinm (guest, #69913) [Link]

Unfortunately, in the context of davem's comment it seems that the macro in question is itself confused about what the type of the argument should be.


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