Critical security vulnerability in GNU Libc

Meanwhile, there are no official packages yet, so we RHEL/CentOS users can't upgrade.

Debian packages are already out for Wheezie. Waiting for Squeeze.

Note the long list of mitigations. Some things will be remotely exploitable (exim), but it looks like most things will be safe enough, as it doesn't affect cases where forward confirmed reverse DNS. Even the exploit they give only works against particular exim configs.

That said, this has a picture, and a name. So it's obviously the biggest deal ever.

Consider this section of the patch:

    diff --git a/nss/digits_dots.c b/nss/digits_dots.c
    index 2b86295..e007ef4 100644 (file)
    --- a/nss/digits_dots.c
    +++ b/nss/digits_dots.c
    @@ -46,7 +46,10 @@ __nss_hostname_digits_dots (const char *name, struct hostent *resbuf,
         {
           if (h_errnop)
            *h_errnop = NETDB_INTERNAL;
    -      *result = NULL;
    +      if (buffer_size == NULL)
    +       *status = NSS_STATUS_TRYAGAIN;
    +      else
    +       *result = NULL;
           return -1;
         }

My recollection is that NULL can be defined as 0 or as ((void * )0).

On implementations where NULL is defined to be 0, comparing an integer to NULL should give the desired result. On implementations where NULL is ((void * )0), and where the null pointer is all 0 bits, I'd expect it to work, too.

But what about on architectures where the null pointer is not all 0 bits? Then ((void * )0) should be the bit pattern of that architecture's null pointer, and what happens when that is compared to the buffer_size integer? In particular, what happens when buffer_size is 0?

If NULL is converted to an integer, won't it end up with the integer with the same bit pattern as the null pointer, and so will != buffer_size? If buffer_size is converted to a pointer, on the other hand, it will be converted to the pointer whose bits are all 0 (the magic that replaces 0 with the null pointer only applies to the constant 0, not to variables that happen to contain 0), and so will != NULL.

Thus, it seems that this comparison only works right on systems where NULL is defined as 0, or where the null pointer is all 0 bits.

If NULL is 0 in gcc, which I believe is the intended compiler for libc, then it should work everywhere, but it still seems like a bad idea, because it means that if gcc ever changes NULL to ((void *)0)

this code will need changing.

In addition to above concerns about functionality, this seems terrible style to me. The code is trying to make sure that buffer_size is not zero. It's a comparison of cardinal numbers, and so 0 is the appropriate way to write zero.