Critical security vulnerability in GNU Libc

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235

by fdevillamil • 11 years ago

37 7 11 years ago

bugzilla.redhat.com

Mojah• 11 years ago

"Red Hat would like to thank Qualys for reporting this issue."

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

lil_cain2• 11 years ago

RHEL have now released updates.

Also, not this was leaked before the end of the embargo.

mdekkers• 11 years ago

Is this becoming a new thing on Linux? Patch Tuesdays?

fdevillamil• 11 years ago

Patches are coming, apparently the vuln was to be announced at 7PM CET, but the French Qualys RP violated the embargo on a mailing list 3 hours too early.

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

tzs• 11 years ago

I retired as a C language lawyer a long time ago, and mostly work in scripting languages nowadays, so am out of date on what is considered accepted styles and idioms, but something does not look right about the patch.

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

Is the comparison of buffer_size to NULL (1) legal, and (2) stylistically OK?

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.

tlb• 11 years ago

Buffer_size is a pointer to the actual size (declared as size_t *buffer_size), so comparing to NULL is correct.

lil_cain2• 11 years ago

http://www.openwall.com/lists/oss-security/2015/01/27/9

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.

Critical security vulnerability in GNU Libc

Related Stories