Comments on: GCC vs. CERT

Comment on GCC vs. CERT by: Ian Lance Taylor

Thu, 24 Apr 2008 00:10:49 +0000

Thanks very much for the pointer.

Comment on GCC vs. CERT by: dbremner

Wed, 23 Apr 2008 19:48:21 +0000

Russ Cox reported this as a vulnerability to CERT. The original broken code is here.
I’m disappointed by CERT’s response.

Comment on GCC vs. CERT by: Ian Lance Taylor

Sat, 12 Apr 2008 01:07:09 +0000

Knieper: thanks for the example. It’s almost plausible. Of course it’s better to rewrite the incorrect test as

if (len > max - ptr)
return EINVAL;

rather than to rely on wrapping overflow. (Let’s not forget that the C language standard specifically says that pointer overflow is undefined, and that it will not work as you expect on a segmented memory architecture).

You’re right, gcc PR 27180 was an earlier iteration of this. it was made to work correctly–that is, to optimize those comparisons only when appropriate–with gcc PR 27039.

Comment on GCC vs. CERT by: Ian Lance Taylor

Sat, 12 Apr 2008 00:54:24 +0000

ncm: strlcpy lets you write sloppy code faster without introducing buffer overflow. I guess I do have to agree that any fully correct use of strlcpy can be replaced by memcpy. String truncation at a relatively arbitrary point is only rarely the right thing to do.

Comment on GCC vs. CERT by: Knieper

Fri, 11 Apr 2008 20:16:24 +0000

>The advisory is about an optimization which gcc
>introduced in gcc 4.2
No, it’s an old bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27180

>This means in particular that p + C can not wrap
>around the end of memory, so the compiler can
>ignore wrapping issues.
>Now, I don’t know who would have thought otherwise.

>What matters is whether the offset is within the
>bounds of the object the pointer points at. A test
>which relies on wrapping overflow for pointer bounds
>seems rather strange.

http://www.fefe.de/openldap-mail.txt

Comment on GCC vs. CERT by: ncm

Fri, 11 Apr 2008 18:42:30 +0000

strlcpy, in isolation, wouldn’t be so bad. What makes it actionably bad is “security professionals” insisting that every strcpy call be replaced by strlcpy.

That said, it’s a bad design because it doesn’t pull its weight: it’s just as much work (and code) to check the result as it would have been to pass verified-safe arguments to memcpy. Furthermore, there’s nothing meaningful to do if it comes out wrong. It’s not so bad as strtok, which represents the extremum of standardized interface design stupidity. (I don’t doubt MS has surpassed it privately, but who could find out without home trepanation?)

Comment on GCC vs. CERT by: Christoph Bartoschek

Fri, 11 Apr 2008 11:42:44 +0000

Somehow my program example got mangled through the posting process. Did not notice it earlier.

Unfortunately you are right. Deciding about which removed code should be warned is very hard.

Comment on GCC vs. CERT by: Danilo Piazzalunga

Fri, 11 Apr 2008 08:16:26 +0000

ncm: I never understood why strlcpy() is considered that bad. I agree with Ian in finding strlcpy() just a nicer strncpy().

Comment on GCC vs. CERT by: Ian Lance Taylor

Thu, 10 Apr 2008 20:04:21 +0000

I haven’t actually tried your program, but it is yet another case. In standard C there is nothing you can add to a non-null pointer which will give you a null pointer.

It doesn’t make sense to me to have a warning for every code block that is optimized out. It will happen too often–there will be too many false positives. Think about inline functions, for example, when called with constant arguments.

I also don’t think a warning for the type of code in your example is useful. What real code would it help?

There is an easy way to ensure that nothing gets optimized out: compile with -O0.

Comment on GCC vs. CERT by: Christoph Bartoschek

Thu, 10 Apr 2008 10:29:20 +0000

I wonder why the following programm does not give a warning for the first if statement similar to the warning for the second statement:

#include
#include

int main(void) {
char buf[1];
unsigned pos = 1;
int len = INT_MAX;

if (buf+len= 0) printf(”Bigger\n”);
return 0;
}

I used version 4.3 and:
gcc -O2 -W -Wall -pedantic -Wstrict-overflow=5 fehler.c

Generally I would like to have a warning for each code block that is optimized out and a possibility to disable the warning for specific code blocks.