30 ms·

Glibc getaddrinfo stack-based buffer overflow

• t0mk 11y ago
  Is getaddrinfo usually statically linked or dynamically linked to stuff? Which pkgs on Ubuntu will be necessary to upgrade once they roll the fix to the repos?
  • zzzcpan 11y ago
    This is one of those things that usually cannot be linked statically at all. So, not many things to upgrade.
    • umanwizard 11y ago
      Why can't it be linked statically?
      • fpoling 11y ago
        Glibs uses /etc/nsswitch.conf to decide at runtime which libraries has to be loaded dynamically to implement DNS resolver, user lookup etc. One in principle can compile those libraries statically, but it is rather complicated for no gains, so almost nobody is doing that.
        • umanwizard 11y ago
          Interesting, thanks!
• Munksgaard 11y ago
  Can we agree that it's urgently necessary to rewrite most of the core Linux/OSS stack in memory safe languages? Exploits like this come up all the time, and we know how to completely eliminate them. I don't care if it's Rust or D or Go or Haskell or OCaml or anything else, as long as it's not C. The sooner we do this, the better.
  • hendzen 11y ago
    So are you personally volunteering to rewrite all of Linux and glibc in Rust? Are you or your employer volunteering to fund such efforts? There is a reason it hasn't happened yet - because doing so would be exceptionally time consuming and expensive.
    • golergka 11y ago
      Right now, companies that run linux on their servers don't have to pay huge fines when security meltdowns happen. I imagine if they would, they would put more money into the problem: either fund linux development or created more of a market for commercial server operating systems (which can still be open source, at least in some interpretations of the term), for example.
      • nitrogen 11y ago
        No. Strict liability for third party software failure is not a good idea. Software gains much much more from the freedom to innovate than it loses from exploits. Strict liability would be a terrible blow against basically everything HN represents.
        • golergka 11y ago
          Well, there are areas where freedom to innovate is more important, and then there are areas where liability is more important. May be US (as de-facto main government-level actor in IT and internet) could create voluntary certification that opened up companies to such liabilities? Small startup operating from a garage — no certification necessary, but users are aware that no one is guaranteeing anything. IBM? Level A certification which they advertise everywhere, with billions of dollars in potential fines.
          • ivl 11y ago
            If it was voluntary, I doubt many of those companies would see it as worth the risk. The problem is that these errors happen because so many people are working on interdependent parts. Many times, it's not even your error that can make your software vulnerable. I dislike making anything so risky, because we'll see much, much less good software at the end of the day.
• pilif 11y ago
  How is this related to CVE-2015-0235 (the GHOST vulnerability last year)?
  • jimrandomh 11y ago
    They are separate vulnerabilities in the same codebase, both affecting DNS clients. This one is new, so having previously patched to protect from CVE-2015-0235 does not make you safe from CVE-2015-7547.
• verytrivial 11y ago
  An extra gold star for the valuable comments added by the patch! https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
• jimrandomh 11y ago
  > "The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack." > "The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further." > "Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR." It is time for the bimonthly Internet security meltdown. Again. When they say that "exploitation vectors are diverse and widespread", they really mean it. Patch ASAP. This is a race; it is only a matter of time before criminals start automatically and systematically scanning every server on the internet for this, and you really really want to be patched before that happens. Thinking a bit more long term, it's pretty clear at this point that we need to expunge all C language networking code from the world, replacing it with Rust or pretty much anything else. That's not sufficient by itself, but it is necessary, or else the periodic Internet security meltdowns won't ever stop.
  • dalore 11y ago
    But this is hard for them to 'scan' for. As they need to get vulnerable systems to query their dns server. But it's not hard to get a system to do a dns query. Sometimes even connecting to it will cause your ip to appear in the logs which are then sometimes reversed ip. But one could easily just create a webpage with img.src pointing to the host. DNS being distributed could halt the attack upstream by patching their servers to stop the queries so any vulnerable clients won't get compromised even if they make the query.
    • Xylakant 11y ago
      > DNS being distributed could halt the attack upstream by patching their servers to stop the queries so any vulnerable clients won't get compromised even if they make the query. Anybody connecting to a public network that pushes network settings may still be affected. For wifis with a capture portal (hotel wifi etc) you usually have to use the network-provided dns server.
• rtpg 11y ago
  Are there any big efforts to rewrite glibc in something like rust? ... Is that a thing that is even possible? An in-place replacement library for dynamic or static linking. I'm really worried that I still hear about buffer overflows in this day and age. Of all the libraries in the world, glibc should probably be written in some subset of Idris that compiles into 100% safe C. We have the technology to move to this now
  • lmm 11y ago
    It would be a wasted effort. Anything that's using glibc (directly) is written in C and therefore inherently unsafe. There are only two kinds of programs written in C: those that need to do unsafe things and those whose developers don't care about safety. Better to look to building systems that don't need to run any C code (see the recent fuss around unikernels).
    • qb45 11y ago
      > Anything that's using glibc (directly) is written in C ... and together with stuff using glibc (indirectly) constitutes 99.99% of your software. How much software/languages implement their own DNS resolver instead of just calling libc? How about syscall wrappers?
      • lmm 11y ago
        The JVM looks to have its own implementation. I imagine .net would be the same. There's ocaml-dns for unikernel-deployed OCaml. A managed language generally doesn't give you direct access to syscalls at all. In rust you can perform them without having to go via C.
        • gpderetta 11y ago
          Note that DNS lookup doesn't require any syscall other than normal socket i/o, which is available on any non toy language. One possible reason why java might implements its own name resolution is because it wants to do async name resolution which is not possible (at least portably) via getaddrinfo and friends.
• spyrosk 11y ago
  So can someone ELI5 how bad this is? From what I'm reading this should only affect systems that use a compromised DNS server or in a MitM attack scenario. Which is serious but not so easily exploitable (I think).
  • mschuster91 11y ago
    > Which is serious but not so easily exploitable (I think). Oh it is. All you need is an open wifi with a router only dealing IPv4 addresses... start up radvd and serve your machine as authoritative IPv6 DNS server, and profit.
    • tremon 11y ago
      That requires local area access. So maybe easily exploitable, not easy to do mass infections. Besides, how many distro's are actually configured for dhcpv6 stateful configuration out of the box?
      • mschuster91 11y ago
        Windows and OS X AFAIK, as well as the Debian installer... not sure about mainstream distros though.
  • peterwwillis 11y ago
    If you request a network connection to an attacker-controlled host, your network software may try to resolve the attacker's host name. The DNS NS record of their domain may then specify your resolver directly look up the record using the attacker's own name server, meaning you are directly doing DNS queries against the attacker's NS. So in theory, all you need to be exploited is to connect to a compromised host and resolve its hostname.
    • thrownaway2424 11y ago
      It could be even worse than that. If the attacker tries to connect to you, your server may try to reverse their IP for logging, and the attacker can control the PTR record. Or the attacker could send you an email that's guaranteed to bounce, and they control the return path that your mailer has to resolve.
• arielb1 11y ago
  That's what you get when you have thousands of lines of code with variable names like `thisanssizp`. glibc should die in a fire.
  • the_why_of_y 11y ago
    The DNS code in resolv/ is not formatted according to GNU coding style - you can tell by the sane placement of braces. It's a fork of an ancient version of BIND. Starting with version 2.2, the resolver in the GNU C Library comes from BIND 8. https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/README;h=dbb15108ae025e2896c0dc1d9161f14d6e05d330;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/READ...
  • frign 11y ago
    Exactly. The mess glibc is is giving C a bad name. Look at the musl libc for how it should be done.
• tasqa 11y ago
  Looking for a quick mitigation technique before patches start rolling out... Would it be wise to limit responses to 512 bytes so the payload cannot be loaded? Configuring BIND to use a specific buffer size (only for BIND 9.3.2 and newer): Add the following line to the "options" section of your named.conf file: edns-udp-size: n Configuring Unbound to use a specific buffer size: Add the following line to the "server" section of your unbound.conf file: edns-buffer-size: n source: https://labs.ripe.net/Members/anandb/content-testing-your-resolver-dns-reply-size-issues https://labs.ripe.net/Members/anandb/content-testing-your-re...
  • rayvd 11y ago
    I feel like this would depend where in the BIND code the size restriction is being enforced. Sounds promising, however.
  • sveiss 11y ago
    I haven't tested it, but I'd expect not. Given a limited EDNS0 buffer size, UDP responses would either come back with a truncated flag or not at all. Either case would trigger a TCP retry, and the bug can be triggered that way.
• nwah1 11y ago
  Why don't more distros use the lighter weight C runtimes?
  • daeken 11y ago
    Many applications don't work with anything but glibc, so distributions don't use them; because distributions don't use them, applications don't support anything but glibc.
    • tomjakubowski 11y ago
      The number of applications that rely on malloc/free being multithreaded fork safe, like glibc's allocator, is astounding. Off the top of my head, any application that uses glib and g_spawn_* is quite unportable for this reason.
  • pquerna 11y ago
    For example, Node.js still has test case failures when running on musl on Alpine Linux: https://github.com/nodejs/docker-iojs/issues/44#issuecomment-153606107 https://github.com/nodejs/docker-iojs/issues/44#issuecomment... Most apps will work out of the box, but you can see in that issue 1+ year of various people debugging and fixing issues to just get existing test cases to pass.
  • ape4 11y ago
    lighter weight doesn't mean fewer bugs.
  • ajross 11y ago
    Why would that matter? This was a bug in a POSIX function that all C libraries would be required to implement.
    • tomjakubowski 11y ago
      And the C libraries all implement those functions (mostly) differently. The "lighter weight" standard libraries tend to have simpler implementations of these functions, which may be easier to audit for these kinds of bugs. For example: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/getaddrinfo.c https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/pos... compare with http://git.musl-libc.org/cgit/musl/tree/src/network/getaddrinfo.c http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...
• JabavuAdams 11y ago
  The criticisms of C and C++ smack of second-system syndrome and naive developers. Repeat after me: there is no silver bullet! Languages like Ruby have had their host of ridiculous security errors. One advantage of legacy code is that it is battle-tested. It's not sexy, it's not clean, but neither is the real world. Wholesale re-writes fail time and time again because what looked simple from 10k feet isn't when you have to actually interface with the real world. Fuck Rust and you naive and self-serving evangelists. Come back to me in 20 years with what you've learned.
  • JabavuAdams 11y ago
    EDIT> Also, do you seriously think humans will be programming in 20-50 years? We'll be operating at a higher level and just boiling it down to C/asm anyway. If you want to make a difference, then work on machine programming. If you're inventing a new programming language, then you're fighting yesterday's battle.
    • deleted 11y ago
      [deleted]
      • JabavuAdams 11y ago
        Quantity has a quality all its own. If you look at what Google is doing with their code indexing, deep integration with LLVM, etc ... it's about tooling at a certain point, not so much the language.
  • jblow 11y ago
    There absolutely are some silver bullets. ALL of these buffer overflows in C happen because the C stack grows backward, and old space is after new space. If anyone have enough of a crap just to standardize a calling convention that went the other way, stack buffer overwrites would ALWAYS go into unused memory. Then security-minded people would switch to this calling convention for secure programs, and many problems would be solved. (Of course heap problems would still exist but they are much harder to exploit and it is easy to make an allocator that tries to confound heap attacks.)
• IgorPartola 11y ago
  This is why I enabled automatic security updates on all the machines I control. I'd rather get a monitoring alert that something is broken, than to find out much later that someone rooted my server.
  • drummer32 11y ago
    Unless you automatically restart every service that is linked with a library when you update it, you are still vulnerable.
• LinuxBender 11y ago
  Has anyone actually tried the PoC on their systems? I will test on CentOS 6 and 7 after I have had my coffee. Anyone willing to volunteer to test on Ubuntu and Debian? Here is CentOS 7 [ 389.064412] do_general_protection: 159 callbacks suppressed [ 389.064416] traps: CVE-2015-7547-c[1161] general rotection ip:7fa6b0d8fd67 sp:7ffdaf034a30 error:0 in libresolv-2.17.so[7fa6b0d87000+16000]
  • gtirloni 11y ago
    https://access.redhat.com/security/cve/cve-2015-7547 https://access.redhat.com/security/cve/cve-2015-7547
    • LinuxBender 11y ago
      Thanks @gtirloni
  • lukeasrodgers 11y ago
    I tested my ubuntu 12.04 and it did not seem to be affected. server: vagrant@precise32:/tmp/CVE-2015-7547$ sudo python CVE-2015-7547-poc.py [UDP] Total Data len recv 36 [UDP] Total Data len recv 36 client: ./CVE-2015-7547-client CVE-2015-7547-client: getaddrinfo: Name or service not known vagrant@precise32:/tmp/CVE-2015-7547$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04 LTS Release: 12.04 Codename: precise vagrant@precise32:/tmp/CVE-2015-7547$ ldd --version ldd (Ubuntu EGLIBC 2.15-0ubuntu10) 2.15 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper.
    • atom_enger 11y ago
      I'm seeing the same behavior here. Thanks for the update and confirmation. Can others confirm if this means 12.04 isn't impacted by this cve?
  • 11y ago
• cnvogel 11y ago
  As far as I see the bug primarily lies within this function here... resolv/res_send.c https://github.com/bminor/glibc/blob/master/resolv/res_send.c#L952 https://github.com/bminor/glibc/blob/master/resolv/res_send.... Lines 952 ... 1389 [=~450 lines of code], with more than a dozen of variables holding random state. Think about the complexity you have with all the conditionals and loops, often copying and pasting similar conditions with (xx1 && xx2) variants. While discusions about the relative merits of Rust, C, Ocaml, Intercal are fun, with enough dedication you can write unauditable/unreviewable code in any language. Even though you might avoid memory corruption, you still can't prove that such kind of code does anything correct.
  • cmrx64 11y ago
    You sure can prove that any correct code does something correct, but you can never prove something about a program outside of a machine-checked formal proof.
    • nly 11y ago
      The problem is that it's far more difficult to prove what code doesn't do than what it does. I can write a function to do X, Y and Z, and I can show, through observation and aggressive testing, that it does indeed do X,Y and Z....but its a lot harder to prove that it only does X,Y and Z and nothing else. Memory safety is just one expression of this problem.
      • cmrx64 11y ago
        In the typical framework (refinement), if you prove your function does X, Y, and Z, then it does exactly X, Y, and Z. Please don't take my comment out of the context of formal, machine-checked proofs. It is hard, and that's my point.
  • sbov 11y ago
    Sure. But not doing something correct is far different from a security vulnerability.
  • 11y ago
• Ono-Sendai 11y ago
  Looking at that code, which is a tangle of goto statements and buffer allocations and accesses, it's a miracle any of it works in the first place. I bet there are tons more bugs in there.
  • matthewaveryusa 11y ago
    Tangle of gotos? Those gotos all look reasonable -- they go to return conditions no longer than a few lines. Buffer allocations? They allocate to 2-3 buffers. That's all very reasonable. allocations and gotos aren't the devil in C.
    • Ono-Sendai 11y ago
      Well, the control flow seems complicated at least.
      • 0x4a42 11y ago
        No
        • carterehsmith 11y ago
          .
• leesalminen 11y ago
  I haven't seen anything come down through yum or apt-get yet. Does anyone know how this can be patched prior to that?
  • Trellmor 11y ago
    Debian has published security announcements for glibc [1] and eglibc [2]. Updates should be available from http://security.debian.org/ http://security.debian.org/ (and I was able to install them). Also, keep this in mind: >While it is only necessary to ensure that all processes are not using the old glibc/eglibc anymore, it is recommended to reboot the machines after applying the security upgrade. [1] https://lists.debian.org/debian-security-announce/2016/msg00051.html https://lists.debian.org/debian-security-announce/2016/msg00... [2] https://lists.debian.org/debian-security-announce/2016/msg00050.html https://lists.debian.org/debian-security-announce/2016/msg00...
  • arielb1 11y ago
    As a brute-force fix, you can disable DNS in /etc/nsswitch.conf and put the addresses you need (at least security.debian.org, YOUR_MIRROR) in /etc/hosts.
• btrombley 11y ago
  Can someone please explain the fix in practice? Is it as simple as upgrading glibc (and eglibc?) on all servers? Or is there a network change I should immediately change?
  • mocko 11y ago
    Yes, patching your OS (e.g. an apt-get update + apt-get upgrade) then rebooting once the vendor has released patches should be sufficient.
• titzer 11y ago
  Buffer overrun on the stack...this makes me sad. It's 2016.
  • rcurry 11y ago
    "There are two things I am sure of after all these years: there is a growing societal need for high assurance software, and market forces are never going to provide it." - Earl Boebert
  • deleted 11y ago
    [deleted]
• ptrincr 11y ago
  Redhat (RHEL5 unaffected) - https://access.redhat.com/security/cve/cve-2015-7547 https://access.redhat.com/security/cve/cve-2015-7547 - https://access.redhat.com/articles/2161461 https://access.redhat.com/articles/2161461 RHEL6 - https://rhn.redhat.com/errata/RHSA-2016-0175.html https://rhn.redhat.com/errata/RHSA-2016-0175.html - update to glibc-2.12-1.166.el6_7.7.x86_64.rpm RHEL7 - https://rhn.redhat.com/errata/RHSA-2016-0176.html https://rhn.redhat.com/errata/RHSA-2016-0176.html - update to glibc-2.17-106.el7_2.4.x86_64.rpm Debian - https://security-tracker.debian.org/tracker/CVE-2015-7547 https://security-tracker.debian.org/tracker/CVE-2015-7547 Use "aptitude show libc6" - needs to be 2.19-18+deb8u3 (jessie), 2.21-8 (sid) Ubuntu - http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-7547.html http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20... SUSE - https://www.suse.com/security/cve/CVE-2015-7547.html https://www.suse.com/security/cve/CVE-2015-7547.html Interesting to note this tip: While it is only necessary to ensure that all processes are not using the old glibc anymore, it is recommended to reboot the machines after applying the security upgrade. From - https://lists.debian.org/debian-security-announce/2016/msg00051.html https://lists.debian.org/debian-security-announce/2016/msg00... Therefore at the very least you will need to restart anything which depends on glibc. This should give you a list of packages: lsof | grep libc | awk '{print $1}' | sort | uniq
  • shaggy 11y ago
    Thanks for these. Has anyone seen a link from/for CentOS yes?
    • ptrincr 11y ago
      Not sure about Centos, can't find anything. Looks like someone has submitted a patch for Fedora - https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f9e9a34ce https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f9e9a34... I'm guessing Ubuntu will add something here once they get a fixed released - http://www.ubuntu.com/usn/ http://www.ubuntu.com/usn/ Should be able to see centos updates here, once they are released, for files glibc-2.12* with a 2016 timestamp - http://mirror.centos.org/centos/6/updates/x86_64/Packages/ http://mirror.centos.org/centos/6/updates/x86_64/Packages/ http://mirror.centos.org/centos/7/updates/x86_64/Packages/ http://mirror.centos.org/centos/7/updates/x86_64/Packages/
• fpoling 11y ago
  I wonder why alloca+malloc/free was used in the first place and not straightforward malloc/realloc/free. The overhead of the latter should be negligible given that this is a DNS resolver. The overhead in fact could be negative due to simpler code and better cache utilization. Premature optimization is a root of all evil indeed.
• mariuolo 11y ago
  There's something I don't understand: if it's from 2015, how come it hadn't been fixed until now? At least for debian.
• weinzierl 11y ago
  Can this be used to exploit DNS servers via other rogue DNS servers? What if I setup a rogue DNS and wait for it to be queried by 8.8.8.8. When I own 8.8.8.8 I can exploit every client that queries it. Browsers use getaddrinfo(), don't they?
  • thrownaway2424 11y ago
    You think Google's DNS service is based on third-party resolver code?
    • weinzierl 11y ago
      I'm out of my element here but is it really so far fetched? A quick search in the PowerDNS codebase [1] reveals four sites where getaddrinfo() is called. This isn't obviously the code for recursive lookups but that doesn't matter. If an attacker can trick it to query their rogue DNS they have won. I don't want to suggest that Google uses PowerDNS, I just used is as an example. [1] https://github.com/PowerDNS/pdns/search?utf8=%E2%9C%93&q=getaddrinfo https://github.com/PowerDNS/pdns/search?utf8=%E2%9C%93&q=get...
      • thrownaway2424 11y ago
        It just seems out of character. Google is huge with the not-invented-here.
  • inopinatus 11y ago
    No. Recursive resolvers do not use getaddrinfo(3) to resolve DNS queries.
    • weinzierl 11y ago
      That was what I was thinking but it was stupid idea. My point is that if you could use this bug to use one rogue DNS to own other DNSes this could be leveraged to bring large parts of the Internet down. I don't know how hard or easy this could be. A quick glance into PDNS reveals four calls to getaddrinfo()[1]. So it might be possible... [1] https://github.com/PowerDNS/pdns/search?utf8=%E2%9C%93&q=getaddrinfo https://github.com/PowerDNS/pdns/search?utf8=%E2%9C%93&q=get...
• rms_returns 11y ago
  Can someone explain in layman's terms how will this affects me as a Linux user who works on Ubuntu?
  • profmonocle 11y ago
    In layman's terms - It probably won't, just install security updates as usual and you shouldn't have to worry about it.
  • djcapelis 11y ago
    Update your machines and you should probably restart too so any running processes link to the new libc.
    • inopinatus 11y ago
      This. Far too often I see libraries updated by a security patch but without a restart of affected dependent processes, meaning you're not protected. sudo lsof -n | grep DEL is your friend in this matter.
• ComputerGuru 11y ago
  Everyone's going crazy advising everyone else to update, but the glibc homepage is happily, statically sitting on version 2.22 from 2015-08-14. Maybe we should start by releasing an update there asap, and go from there? (I just switched our last Linux server over to FreeBSD, despite some software we use not being available; so I'm happy to sit this one out.)
• totony 11y ago
  If this causes you serious problems, you should really consider using a patched grsecurity kernel (even though their stable versions arent free anymore)
• mmosta 11y ago
  Newbie questions: Are "upload file by URL" functions potential vectors? (payload in malcious dns response) Is this contingent on a cooperating DNS server (not truncating the record?)
• mwcampbell 11y ago
  The Debian glibc package update that fixes this vulnerability is dated February 11. But the patch wasn't posted on the glibc mailing list until today. So did Debian get the patch even before it was made public upstream? If so, then why didn't Ubuntu get it early as well?
  • stevekemp 11y ago
    Sufficiently "bad" issues are disclosed to multiple Linux vendors at the same time, via the vendor-sec mailing list. If you're a member of a security team for a distribution this is generally where you hear about issues. From there coordinated release dates will be agreed, and barring big surprises like one distro pushing out an update too soon everybody _should_ release at the same time. Sometimes people get sick, take a holiday, or drop the ball for other reasons. I'd expect Ubuntu did get notified, but haven't yet tested/built their fixed packages to push out.
• efuquen 11y ago
  Can someone give me technical reasons why this world isn't possible: Parts of the linux kernel or glibc or any other critical C code gets replaced by rust code little parts at a time, which is also calleable from C (https://doc.rust-lang.org/book/ffi.html https://doc.rust-lang.org/book/ffi.html)? That way these libraries could be made safer in a controlled and incremental manner. And to reiterate I'm asking for technical limitations, not political or dogmatic.
  • maerF0x0 11y ago
    All code is binary, you can write a compiler that turns human readable code (rust) into binary. Then you can push that binary wherever you want (into a custom address in another file for example). Technically we can do _anything_ we can rewrite part of it in JavaScript if we want. What you need to understand is that almost 100% of engineering is economic. Is it worth the time to rewrite things in a new language, to rebuild the tool chain to make things easy/convenient, to deal with the gotchas in each new language and their compilers ? On and on the list goes. And most of the issue is there isnt incentive, users of free software have a first mover problem in that if someone else pays for the software to be made, nonparticipants get it for free. Thus we all wait for someone else to pay for all the wonderful things that would benefit us all.
  • kibwen 11y ago
    The biggest technical limitation is that there's currently only one Rust compiler, and it targets LLVM, which means that it can currently compile for only a subset of all platforms that C can compile to. For some projects this isn't a problem. For example, Firefox is replacing bits of itself little by little with Rust, which is fine because Rust targets all platforms that Firefox is built for (though it did take some wrangling to get Rust working on Windows XP). However, a project like glibc is used across a much greater variety of platforms, and many of those platforms may have nothing but C compilers. And those C compilers may very well be buggy and nonstandard, so even transpiling to C won't help unless you're willing to hand-tweak the generated code.
  • DSMan195276 11y ago
    I thought about this before, since it seemed like a good idea to me too. It's not that simple though, there's tons of problems you'd hit and the result wouldn't be what you want. The bottom line is that Rust is simply not a drop-in replacement for C: You can't just pass a Vec<> to some C code and expect it to work. The reality is that you're going to end-up writing a lot of C-like Rust - Which either acts on C types directly or converts them to Rust types and then does things to them and converts them back. Either way, the safety is largely lost due to this because C types are not going to be safe. You also can't use any inline C functions or preprocessor macros in your Rust code, meaning that the interop between C and Rust isn't really that good - FFI lets you call functions, but functions only make-up a part the C API. The rest would have to be duplicated in Rust and kept up-to-date, which is a huge development burden and very error prone. And when you're finally "done" and all the C code is gone, what you're left with is just a lot of C-like Rust, communicating with each-other through the C API using C types with unsafe code everywhere. Essentially C but in Rust form. You'd have to do a ton of refactoring to turn this into anything like idiomatic Rust, and you can't do that refactoring till all the C code interfacing with that Rust code is completely gone so you can stop supporting interop with C. The bottom line is that it you could do it, but it won't work well because it's missing the big picture - If you don't write Rust code like Rust, then you don't get the safety guarantee's, and you can't do that if you're trying to recreate a bunch of C interfaces in Rust. C interfaces are not safe in the way that Rust would want them to be safe. It's the same reason why you can't write a converter to convert from C to idiomatic Rust - You have to design the system differently to get the gains from Rust, which is a non-trivial thing to do. Rewriting small parts in Rust isn't going to result in the design differences that you need, and the interop between Rust and C isn't very good, leading to lots of problems while you're dealing with both languages in the same code base.
• Erwin 11y ago
  It seems tcp_wrappers-libs is using getaddrinfo, so if you have some rules setup there that may be an attack vector. I'm not sure if sshd will want to do a getaddrinfo if you don't have some tcp wrappers rule set up in /etc/hosts.{deny,allow}.
  • JdeBP 11y ago
    See https://news.ycombinator.com/item?id=8957680 https://news.ycombinator.com/item?id=8957680 for earlier discussion of that latter point.
• amelius 11y ago
  Is there something that can be done about this on the network level? I mean, it seems almost impossible to assure that every instance of getaddrinfo is patched. I'm thinking about a background tool (iptables plugin?) that simply truncates long DNS replies, so that they can never cause a buffer overflow.
  • JdeBP 11y ago
    See https://news.ycombinator.com/item?id=11112923 https://news.ycombinator.com/item?id=11112923 on this page.
    • amelius 11y ago
      Thanks!
• alkonaut 11y ago
  Criticism of C aside, when you use a language that isn't very expressive and where it's easy to shoot yourself in the foot, you need to keep it very neat. I mean just look at this https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/getaddrinfo.c https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/pos... That size of methods, huge macros, the low ratio of comments to (non-obvious) statements etc. I know it's easy to criticize very old and tested code, but there is no (and never was any) excuse for code like that.
  • AndyKelley 11y ago
    Compare to the musl implementation: http://git.musl-libc.org/cgit/musl/tree/src/network/getaddrinfo.c http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...
    • alkonaut 11y ago
      It's better. The musl version is slightly smaller and tidier but also doesn't handle all the same proticols so it's not a fair comparison. At least it doesn't have a lot of conditional compilation and macros. But the musl code too has bloody ZERO comments for a nearly 100 line long method of dense/opaque C code! Why? Is commenting and splitting code into functions frowned upon in "traditional" systems programming? Who is it that writes code like this? Why isn't code like this rejected by a maintainer with "split this into at least smaller 5 functions and comment anything non-obvious"? Edit: looking again it's actually not that bad, it does have two lookups already broken out and a lot of the verbosity is just field assignment. Would be happy with a dozen lines of comments and a split into 2-3 functions.
      • AndyKelley 11y ago
        I feel like comments are extremely valuable in API documentation, but not so much in the implementation. When you're reading an API you want to understand how it works without cracking open the source. When you're looking at an implementation it is your duty to load the source into your comprehension, at which point comments become irrelevant, or worse, misleading.
• Gratsby 11y ago
  Has anyone put together a POC that doesn't require re-pointing the system nameserver and crashing other applications?
  • zwetan 11y ago
    I'm interested in that too
  • arbruijn 11y ago
    You can create a small chroot with a custom resolv.conf. Example (tested on Ubuntu 14.04 64-bit): mkdir -p root/lib/x86_64-linux-gnu root/lib64 root/etc cp -a --parents /lib/x86_64-linux-gnu/lib{c,nss,resolv}* root cp /lib64/ld-linux-x86-64.so.2 root/lib64 cp CVE-2015-7547-client root echo 'nameserver 127.0.0.1' > root/etc/resolv.conf sudo chroot root ./CVE-2015-7547-client If it prints nothing it crashed. Try running with strace to be sure.
    • Gratsby 11y ago
      Brilliant. Thank you.
• takeda 11y ago
  Fun fact: If you have programs written in Go, after patching this you probably will need to recompile all of them.
  • AsyncAwait 11y ago
    Go 1.5 uses its own pure-Go DNS resolver.
    • acln 11y ago
      Under certain conditions, it does not. https://golang.org/pkg/net/#hdr-Name_Resolution https://golang.org/pkg/net/#hdr-Name_Resolution
      • justincormack 11y ago
        When it does not it dynamically links.
        • takeda 11y ago
          That does not make sense. Among others the page lists: > [...] when /etc/resolv.conf or /etc/nsswitch.conf specify the use of features that the Go resolver does not implement, and when the name being looked up ends in .local or is an mDNS name. Those things you can't check at compile time. In any case, you can tell whether the binary is statically linked or not. Statically linked: $ file /usr/bin/consul /usr/bin/consul: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped $ ldd /usr/bin/consul not a dynamic executable Dynamically linked: $ file /bin/echo /bin/echo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped $ ldd /bin/echo linux-vdso.so.1 => (0x00007fff01fff000) libc.so.6 => /lib64/libc.so.6 (0x0000003bcd800000) /lib64/ld-linux-x86-64.so.2 (0x0000003bcd000000) Notice the libc.so.6
• friendcomputer 11y ago
  If this was originally filed on an open bug tracker in July 2015, what were the glibc team doing in the mean time? The Google post indicates they were "working on it" when Google got in touch. How much work was going on, exactly? How did this languish for so long?
• Mojah 11y ago
  A summary of the problem, the affected Linux versions and patching remediations have been posted here: https://ma.ttias.be/critical-glibc-buffer-overflow-vulnerability-getaddrinfo-linux-cve-2015-7547-cve-2015-5229/ https://ma.ttias.be/critical-glibc-buffer-overflow-vulnerabi...
• JabavuAdams 11y ago
  I apologize for my bad behaviour on this thread. I'm in a bad place, mentally.
• jvehent 11y ago
  iptables -t filter -A INPUT -p udp --sport 53 -m connbytes --connbytes 512 --connbytes-dir reply --connbytes-mode bytes -j DROP iptables -t filter -A INPUT -p tcp --sport 53 -m connbytes --connbytes 512 --connbytes-dir reply --connbytes-mode bytes -j DROP
  • rphlx 11y ago
    FYI, that will pretty much break DNSSEC.
  • superkuh 11y ago
    Thanks for this. It'll do for my router until a new firmware is out. I tried the above but --connbyte takes a range as input not a single value. Like, "512:8192" or "512:" for "greater than 512". In practice "512:" is interpreted as "512:4294967295". So it ends up looking like, iptables -t filter -A INPUT -p udp --sport 53 -m connbytes --connbytes 512: --connbytes-dir reply --connbytes-mode bytes -j DROP iptables -t filter -A INPUT -p tcp --sport 53 -m connbytes --connbytes 512: --connbytes-dir reply --connbytes-mode bytes -j DROP
• el8c0d3r 11y ago
  Don't use SQL or PHP either! These are vulnerable to bugs!
• cft 11y ago
  If I point the local DNS resolver to Google's DNS server as a temp fix (8.8.8.8) in /etc/resolv.conf , will that mitigate the threat before the patch?
  • JdeBP 11y ago
    The problem is DNS/UDP and DNS/TCP responses that are larger than 2048 bytes hitting your BIND DNS client library. Do you have any reason to believe that Google Public DNS (in your part of the world) always limits its responses to smaller than 2048 bytes?
    • cft 11y ago
      Google's DNS relay may take steps to sanitize malicious DNS responses.
• fpoling 11y ago
  If alloca could be used to get arbitrary-sized buffer the bug would not exist. Another Y story https://fosdem.org/2016/schedule/event/ada_memory/ https://fosdem.org/2016/schedule/event/ada_memory/ points out that Ada does not have this limitation. There it is a job of the compiler to allocate bug chunks outside of the stack not to cause stack overflows. C really needs such API.
• alblue 11y ago
  Does this affect OSX?
  • sigjuice 11y ago
    No. OS X has its own implementation. http://www.opensource.apple.com/source/Libinfo/Libinfo-477.20.1/lookup.subproj/libinfo.c http://www.opensource.apple.com/source/Libinfo/Libinfo-477.2...
• newman314 11y ago
  Ubuntu is now patched. http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-7547.html http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...
• AndyMcConachie 11y ago
  I have a question that hopefully someone can clear up for me. If I understand the Google sec article correctly, this requires a single packet > 2048 bytes to be received by a host using glibc. > The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Is my understanding correct? If it is, then it's worth pointing out that many links on the public Internet have an MTU of 1500 bytes. This is an historical legacy of original Ethernet from the 80's. Path-MTU-Detection(PMTUD) doesn't really work on the Internet, so it's safest to assume that you only ever get 1500 bytes. Given all that, this places a burden on anyone wanting to eploit this. Since they cannot assume a PMTU greater than 1500 bytes between endpoints, they're limited in how they can exploit the bug. Correct? Please correct me if I'm wrong. I always feel these bug reports are missing that vital piece of information I need to operationalize the bug. And thanks.
  • sveiss 11y ago
    Datagrams larger than the MTU can be sent, they'll just be fragmented. The point of PMTU is to avoid fragmentation where necessary, but it's still possible.
    • AndyMcConachie 11y ago
      Sometimes datagrams larger than 1500 bytes can be sent, sometimes they won't reach their destination. Fragmentation doesn't really work, and at the very least will almost always ensure out-of-order delivery. Either way you can't depend on it. PMTUD doesn't work at all on the modern Internet, not for IPv4, and not for IPv6. So again, I'm just wondering how dangerous this exploit really is. I'm not saying it isn't dangerous, I'm saying our understanding of it should be tempered somewhat due to many links not fragmenting properly that have MTUs of 1500 bytes.
• maxima120 11y ago
  I think new generation wants to take over linux with their new ideas but in reality they just want to prove themselves and prepared to completely ruin it in the process.. well. Cos they just young and want new things. They know big words and think they now the world and they hate their parents... so in short - they want to do to the Linux what the previous generation did to windows... karma. P.s. whatever language you use its irrelevant. Bugs are in the heads. Code is just the reflection.
• jedisct1 11y ago
  Don't panic, don't spread fear: https://00f.net/2016/02/17/cve-2015-7547/ https://00f.net/2016/02/17/cve-2015-7547/