5 ms·

Glibc vulnerability was identified in uClibc and fixed 6 years ago

128 points by dsl 11y ago

dikaiosune 11y ago
Can someone provide some context here? Is the OpenWRT libc derived from glibc? If so, why didn't this make it upstream? If not, why is this relevant if they didn't use the same code to start?
- Sir_Cmpwn 11y ago
  uClibc is a fork of an old and obscure libc, which later incorporated some code from glibc and a few other libc implementations. They're all GPL'd so the mixing of code probably isn't carefully regulated, and figuring out what stuff is appropriate to submit upstream or what is even derived from a particular upstream source is probably not trivial.
- stephen_g 11y ago
  uClibc, which was what OpenWRT used as their libc, shared quite a lot of code with glibc. They don't use it anymore because the project is dead though (no releases since 2012, no commits since mid-2015) so they switched to musl, which is looking really nice. uClibc was mainly trying to be a cut-down version of glibc, but musl aims for correctness (which can be difficult when a fair bit of software out there relies on glibc's quirks and bugs).
  - hathawsh 11y ago
    Thanks for the tip. For anyone else wondering, OpenWRT 15.05 (Chaos Calmer, the current stable release) is still based on uClibc, while the OpenWRT trunk is now based on musl. (AFAICT)
- ptaipale 11y ago
  As Wikipedia puts it, uClibc was mostly written from scratch,[5] but has incorporated code from glibc and other projects. I didn't bother to check in detail it but it could mean the getaddrinfo() was taken from glibc, and later fixed, but fix not backported to glibc. Just a guess though.
- deleted 11y ago
  [deleted]
pygy_ 11y ago
14 upvotes as I'm typing, so I guess it is relevant, but I can't see how. Could someone shine more light on this?
- dang 11y ago
  HN Search can: https://hn.algolia.com/?query=glibc&sort=byDate&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=glibc&sort=byDate&prefix=false... -> https://news.ycombinator.com/item?id=11109967 https://news.ycombinator.com/item?id=11109967.
  - pygy_ 11y ago
    Thanks :-)
deleted 11y ago
[deleted]
kazinator 11y ago
This doesn't look like the same thing at all (as the recently reported glibc resolver issue): uClibc fix: https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patches-0.9.30.1/902-Fix-use-after-free-bug-in-__dns_lookup.patch?rev=20384 https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patch... glibc fix: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b995d95a5943785be3ab862b2d3276f3b4a22481 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b995d95a... It's totally different code.
- raimue 11y ago
  From the uClibc commit message of the fix: For example, the following busybox commands are triggering a segmentation fault with uClibc 0.9.30.x - nslookup ipv6.google.com - ping ipv6.google.com - wget http//ipv6.google.com/ If this had been the glibc bug, you would have noticed it way earlier.
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
geofft 11y ago
Yeah, this is not at all the same vulnerability. A segfault in uClibc was fixed 6 years ago. Wasn't the same segfault. Most production C code in the wild has more than one segfault waiting to be found. The commit message starts out "Fix use-after-free bug in __dns_lookup." First, the glibc thing wasn't a use-after-free; it was all about buffers on the stack. Second, there's no function named __dns_lookup anywhere in glibc, nor any sign that similar code is anywhere to be found: titan:~/src/libc/glibc geofft$ git grep __dns_lookup titan:~/src/libc/glibc geofft$ git grep 'a->atype' titan:~/src/libc/glibc geofft$ git grep '>dotted' titan:~/src/libc/glibc geofft$

128 points by dsl 11y ago

Can someone provide some context here? Is the OpenWRT libc derived from glibc? If so, why didn't this make it upstream? If not, why is this relevant if they didn't use the same code to start?

Sir_Cmpwn 11y ago
uClibc is a fork of an old and obscure libc, which later incorporated some code from glibc and a few other libc implementations. They're all GPL'd so the mixing of code probably isn't carefully regulated, and figuring out what stuff is appropriate to submit upstream or what is even derived from a particular upstream source is probably not trivial.
stephen_g 11y ago
uClibc, which was what OpenWRT used as their libc, shared quite a lot of code with glibc. They don't use it anymore because the project is dead though (no releases since 2012, no commits since mid-2015) so they switched to musl, which is looking really nice. uClibc was mainly trying to be a cut-down version of glibc, but musl aims for correctness (which can be difficult when a fair bit of software out there relies on glibc's quirks and bugs).
- hathawsh 11y ago
  Thanks for the tip. For anyone else wondering, OpenWRT 15.05 (Chaos Calmer, the current stable release) is still based on uClibc, while the OpenWRT trunk is now based on musl. (AFAICT)
ptaipale 11y ago
As Wikipedia puts it, uClibc was mostly written from scratch,[5] but has incorporated code from glibc and other projects. I didn't bother to check in detail it but it could mean the getaddrinfo() was taken from glibc, and later fixed, but fix not backported to glibc. Just a guess though.
deleted 11y ago
[deleted]

pygy_ 11y ago

14 upvotes as I'm typing, so I guess it is relevant, but I can't see how. Could someone shine more light on this?

dang 11y ago
HN Search can: https://hn.algolia.com/?query=glibc&sort=byDate&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=glibc&sort=byDate&prefix=false... -> https://news.ycombinator.com/item?id=11109967 https://news.ycombinator.com/item?id=11109967.
- pygy_ 11y ago
  Thanks :-)

deleted 11y ago

[deleted]

kazinator 11y ago

This doesn't look like the same thing at all (as the recently reported glibc resolver issue): uClibc fix: https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patches-0.9.30.1/902-Fix-use-after-free-bug-in-__dns_lookup.patch?rev=20384 https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patch... glibc fix: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b995d95a5943785be3ab862b2d3276f3b4a22481 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b995d95a... It's totally different code.

raimue 11y ago
From the uClibc commit message of the fix: For example, the following busybox commands are triggering a segmentation fault with uClibc 0.9.30.x - nslookup ipv6.google.com - ping ipv6.google.com - wget http//ipv6.google.com/ If this had been the glibc bug, you would have noticed it way earlier.

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

geofft 11y ago

Yeah, this is not at all the same vulnerability. A segfault in uClibc was fixed 6 years ago. Wasn't the same segfault. Most production C code in the wild has more than one segfault waiting to be found. The commit message starts out "Fix use-after-free bug in __dns_lookup." First, the glibc thing wasn't a use-after-free; it was all about buffers on the stack. Second, there's no function named __dns_lookup anywhere in glibc, nor any sign that similar code is anywhere to be found: titan:~/src/libc/glibc geofft$ git grep __dns_lookup titan:~/src/libc/glibc geofft$ git grep 'a->atype' titan:~/src/libc/glibc geofft$ git grep '>dotted' titan:~/src/libc/glibc geofft$