

Critical security vulnerability in GNU Libc - fdevillamil
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235

======
Mojah
"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_cain
RHEL have now released updates.

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

------
fdevillamil
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.

------
lil_cain
[http://www.openwall.com/lists/oss-
security/2015/01/27/9](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.

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

------
tzs
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
Buffer_size is a pointer to the actual size (declared as size_t *buffer_size),
so comparing to NULL is correct.

