26 ms·

> "The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this functi

> "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.
- caf 11y ago
  I don't think a reverse query will tickle this bug, because this bug requires simultaneous A and AAAA lookups to be triggered whereas a reverse query uses a single PTR lookup.
pjmlp 11y ago
> 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. It was already clear in 1961 when Burroughs used Algol and C wasn't even born. It was clear when Hoare stated on his speech in 1980: "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." I can quote lots of other security research papers since computers exist. But then UNIX workstations took over the computing world, bringing C with them.
- minimax 11y ago
  I think the other thing that changed is that branch predictors are roughly infinitely times better than they were in 1980. The is-this-subscript-ok check should be easily predictable and I wonder if these checks even cost anything in a hot loop on a modern CPU.
  - kevingadd 11y ago
    They have a measurable cost, and performance-obsessed developers/users hate the cost. But it's a lot smaller than it used to be, and modern compiler/JIT research is yielding ways to safely eliminate/hoist a lot of the checks.
  - pjmlp 11y ago
    After Z80 and Sinclair Basic, my next languages were GW-Basic, Turbo Basic and Turbo Pascal, followed by many others. The Borland languages like many other that allowed for system programming in those days, allowed for disabling bounds checking, as Borland customers weren't like Hoare ones. I never felt the need to disable them. Yes they did had a few ms to the program execution, but nothing that would impact the user experience of the application. This is one of the biggest problem in our industry, specially among C and its derived languages (C++, Objective-C), to micro-optimize each code line without any sort of measurement how it impacts the final application. Of course there are cases where it really matters, like HPC, games and such, but those are a tiny portion of the software that gets written every day.
avian 11y ago
> It is time for the bimonthly Internet security meltdown. Time for the bimonthly Hacker News hour of C and C++ hate.
- deleted 11y ago
  [deleted]
  - pjmlp 11y ago
    Yes, UNIX was adopted by the corporations and brought C with it. Some people don't get it that before it happened we were happily using other systems programming languages way safer than C.
    - cmrx64 11y ago
      (For the record, grandparent originally ended with "Some people just don't get it")
      - deleted 11y ago
        [deleted]
      - tosseraccount 11y ago
        What do you think?
    - voidlogic 11y ago
      >Some people don't get it that before it happened we were happily using other systems programming languages way safer than C. Maybe some people, but most systems programming was done is Assembly before C.
      - TeMPOraL 11y ago
        No, you're not getting it :). There was a whole world besides Assembly and C, now mostly lost to us. E.g. Lisp machines, which even had hardware support for Lisp-specific things like tagged pointers.
masterleep 11y ago
An intermediate step is to run everything under AddressSanitizer, since it's fast enough for many cases. See, for example: https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html https://blog.hboeck.de/archives/879-Safer-use-of-C-code-runn...
- hannob 11y ago
  It likely won't help. I excluded glibc from using ASAN to let this work. It is theoretically possible to use ASAN on glibc as well, but it's complicated and certainly not ready for any kind of production use. Also although this is my work, it's far from clear to me whether using ASAN in production really is a useful thing. Practically I'd rather suggest looking at the safestack and CFI features of clang for production use instead.
  - yugr 11y ago
    BTW at least Clang's ASan is capable of detecting CVE-2015-7547 (in https://groups.google.com/forum/#!topic/address-sanitizer/ttPxNhTK9TU https://groups.google.com/forum/#!topic/address-sanitizer/tt...).
tkinom 11y ago
Does rust use getaddrinfo()? grep -irn getaddrinfo . ./src/libstd/sys/common/net.rs:123: try!(cvt_gai(c::getaddrinfo(c_host.as_ptr(), ptr::null(), ptr::null(), ./src/libstd/sys/windows/c.rs:1235: pub fn getaddrinfo(node: const c_char, service: const c_char, ./src/libstd/sys/windows/net.rs:69:/// Provides the functionality of `cvt` for the return values of `getaddrinfo` How many places doesn't rust source code use C structures or call C APIs? In the rust source tree, run this: grep -irn '[^a-zA-Z0-9]c::' . |wc 615 3143 56000 grep -irn 'extern "C"' . |wc 279 1719 23448
- chc4 11y ago
  You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!" Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust. Also, extern "C" is for C FFI exports not calling C APIs. The world unanimously decided C FFI is the least common denominator, so its not like Rust can provide a different API with better safety hints.
  - ploxiln 11y ago
    Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragmatism) unrelated to the fact that some people still like C. Just as an ironic aside - C enthusiasts may even have switched to musl-libc already, and are not affected by bugs in glibc, while rust-loving people are vulnerable! Also interesting, Go has for a long time supported using its own dns resolver instead of libc, but only recently in go 1.5 uses the go dns resolver by default on unix systems.
    - steveklabnik 11y ago
deleted 11y ago
[deleted]
cft 11y ago
>Patch ASAP What exactly do you patch? Say you have a TCP server, written in Python or in Go. Do you have to update Python and Go ASAP then and recompile the Go server? Custom compiled Apache, Nginx? Recompile those? That's a lot of work..
- r1ch 11y ago
  Unless you statically link glibc, updating glibc is enough.
- nitrogen 11y ago
  If you have dynamically linked libc (which you should), you only need to upgrade libc and restart all network processes. [Does anyone know if systemd in pid1 calls getaddrinfo? If so, this is another good reason for a minimal pid1, as you will need to reboot]
  - Xylakant 11y ago
    you need to restart all processes that might do a network address lookup. That's pretty much every daemon.
  - noselasd 11y ago
    You don't need to reboot to restart systemd, you can run systemctl daemon-reexec
  - the_why_of_y 11y ago
    No reboot needed: man systemctl daemon-reexec Reexecute the systemd manager. This will serialize the manager state, reexecute the process and deserialize the state again. This command is of little use except for debugging and package upgrades. Sometimes, it might be helpful as a heavy-weight daemon-reload. While the daemon is being reexecuted, all sockets systemd listening on behalf of user configuration will stay accessible.
- asveikau 11y ago
  Unless you are linking statically (and I don't really understand why you would) you update glibc and that's it. This question had me feeling kind of old. Does nobody learn what shared libraries are anymore?
weinzierl 11y ago
> The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. Why are browsers missing in the list? Don't they use getaddrinfo() as well?
- msbarnett 11y ago
  Literally the next sentence: > We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.
  - weinzierl 11y ago
    I read that, I just found the examples strange. Browsers are incredibly important for an incredible number of people while curl is not.
- jimrandomh 11y ago
  I'm not sure, but I suspect that major browsers may have their own DNS client implementations, or be calling getaddrinfo from within sandboxed contexts.
  - collinmanderson 11y ago
    Chrome uses a custom DNS client implementation. https://plus.google.com/+WilliamChanPanda/posts/FKot8mghkok https://plus.google.com/+WilliamChanPanda/posts/FKot8mghkok "The problem is that Chromium is issuing too many DNS queries in a short period of time, which may overload upstream devices (typically cheap NAT routers) ... which will then ignore DNS queries for a period of time."
- vdfs 11y ago
  I tried the exploit server, Firefox crashed right after changing the DNS name server.
  - muraiki 11y ago
    That is not awesome :(
ploxiln 11y ago
You already have the freedom to run your webservers as mirageos unikernels (with a networking stack written in ocaml). You already have the freedom to write and run everything you want in such an environment. But what you really want, is to force other people to write code for you, but in a language you prefer (and for it to be easy and convenient for you). Good luck with that.
yyin 11y ago
Is djbdns vulnerable? It does not use these routines. I've never needed ENDS0, but maybe the need will arise someday. Meanwhile... Short term, I'd prefer to expunge all "C networking code" originating from BIND authors, e.g., libresolv.
- cft 11y ago
  Relatedly, if I point dnscache in djbdns to Google's DNS server as a temp fix (8.8.8.8) in /etc/resolv.conf , will that mitigate the threat?
- JdeBP 11y ago
  The fact that djbdns doesn't use BIND code is not really relevant. The problem at hand is in the BIND DNS client library that is compiled and linked into applications. It's triggered by sending responses larger than 2048 bytes to those applications. The only way that djbdns factors into it is whether an attacker, running a content DNS server out on Internet, can manage to get such a DNS response through a DNS proxy server such as dnscache, to that BIND DNS client library code running in the application. Now one might think that the discussion at https://news.ycombinator.com/item?id=11110646 https://news.ycombinator.com/item?id=11110646 already covers this. All that the content DNS server has to do is set the TC flag in the DNS/UDP response, and it can quite happily get the proxy DNS server to re-try via DNS/TCP. The interesting point is that in fact that discussion does not cover this. This is because the idea that one can exploit this with a malicious content DNS server has as its unstated premise that DNS/UDP and DNS/TCP responses are passed straight through caching DNS proxies. This is the case for some DNS proxy softwares, where if the data have just come in from the back end and form a complete answer, they are passed through as the front-end answer. It isn't the case for dnscache. dnscache always answers from cache, even if the data have just arrived from a back-end transaction. So those "crafted DNS responses" beginning with 2048 bytes of valid protocol, that the malicious content DNS server has to generate, have to survive being unpacked, stuffed into dnscache's cache, extracted back out of dnscache's cache, and turned into an answer response by dnscache's from-scratch answer construction code. And this without being able to use the authority or additional sections, without being able to use more than one (non-CNAME) RRset in the answer section, and without any guarantee of any given RRset ordering. This is ... somewhat difficult. The devil in the details of this problem lies in one sentence of the analysis that accompanies the patch: > Overflowing bytes are entirely under the control of the attacker and are the result of a crafted DNS response. If you've done as the people at https://news.ycombinator.com/item?id=11112527 https://news.ycombinator.com/item?id=11112527 and https://www.reddit.com/r/netsec/comments/462xx0/glibc_getaddrinfo_stackbased_buffer_overflow/d02undj https://www.reddit.com/r/netsec/comments/462xx0/glibc_getadd... did, you might have convinced yourself how simple it is to exploit this. Just set up a malicious content DNS server that does what this does, and Bob's Your Uncle. But in fact those demonstrations are not how DNS lookups work. People do not point the BIND DNS client library at (malicious) content DNS servers. The DNS client library is pointed at the front end of a proxy DNS server, which performs back-end lookups to the (malicious) content DNS servers. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-query-resolution.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn... So one has to take into account what the proxy DNS server does in between its back end and its front end. The response returned to the BIND DNS client library from the front end is not "entirely under the control of the attacker". As in the case of dnscache, where front end responses are constructed from cache and from scratch, it's actually quite difficult for the attacker to control it at all, let alone cause dnscache to send a valid-flawed-valid response sequence. It's not just dnscache where this is a difficulty for an attacker, either. Which is why the analysis talks of man-in-the-middle attacks. To exploit this with far greater chance of success, one gets in between the BIND DNS client library and the proxy DNS server, or just plain supplants/subverts the proxy DNS server. Which is yet another reason why it's a good idea to run a proxy DNS server locally, on each machine or at least on the LAN, and make sure that "local" traffic is blocked at relevant machine/LAN borders. An attacker who can field DNS traffic to [::1]:53 or 127.0.0.1:53 in order to be that man in the middle has already had to overcome some quite tricky obstacles. (-: * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-obtaining-proxy-service.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn... It's worth noting that we've been here before. A lot. * https://cr.yp.to/djbdns/res-disaster.html https://cr.yp.to/djbdns/res-disaster.html * http://www.kb.cert.org/vuls/id/542971 http://www.kb.cert.org/vuls/id/542971 * http://www.kb.cert.org/vuls/id/803539 http://www.kb.cert.org/vuls/id/803539 * http://www.kb.cert.org/vuls/id/844360 http://www.kb.cert.org/vuls/id/844360 ... And so on.
djsumdog 11y ago
All this "Let's replace everything with Rust" is extremely childish. Be wary of making programming languages a religion. The Java zealots did it, and you can see the results where full Java projects are used in places where a 20 line Python script would have been easier. If you're serious, one of your pet projects should be trying to implement BSD sockets with Rust. Then try compiling some C apps against your implementation. Then do some performance tests showing memory and time benchmarks of your Rust vs libc implementation. Do a blog post on it. Then we'll take you seriously.
- scotchmi_st 11y ago
  I think you're misreading what he says. "...replacing it with Rust /or pretty much anything else/" (emphasis own). The point is we should be replacing C with /pretty much anything else/. Rust looks like the most obvious (but not necessary correct) candidate. Also performance is not such a big deal as dictate security considerations. One's fancy medical web app is worthless if it leaves the potential for theft of medical data.
- AsyncAwait 11y ago
  The parent actually said "Rust or pretty much anything else", which means any memory safe language. It just happens that Rust came to his/her mind as the first choice probably because it's been talked a lot about lately on HN and memory safety is its explicit focus. I see no "programming languages a religion zealotry" in parents post, but I see a lot of bitterness in yours. Perhaps it's time to reflect.
  - reality_czech 11y ago
    There are tons of vulnerabilities discovered every month. Most of the them are in Java, PHP, javascript, etc. software because that's what the majortiy fo new code is written in. And those languages have features that can lead to security holes, which C doesn't have. For example, PHP supports eval(), JS has cross-site scripting attacks, Java has classloaders, etc. etc. But somehow only the vulnerabilities in C language software get programming language zealots exited. So maybe you should reflect.
sangnoir 11y ago
> it's pretty clear at this point that we need to expunge all C language networking code from the world Will you bell the cat? I'd pay a lot of money to see Linus' reaction to your massive network-stack replacement kernel patch written in Rust. More seriously though, who is prepared to fund this? Is the risk worth that much effort? Because I see a lot of people being vocal about it on HN, but no real attempt is made to come up with a safe Rust-based alternatives
latenightcoding 11y ago
How did I know this would turn into a C vs Rust debate
- JdeBP 11y ago
  There are a few interesting points in this discussion that all of the C/Rust/C++/ObjectiveC/Go/Java discussion has swamped. For those who would like to find the discussion that is not argument about computer programming languages: * Is Google Public DNS a potential mitigator? Sub-thread at https://news.ycombinator.com/item?id=11113113 https://news.ycombinator.com/item?id=11113113 . * Is Google Public DNS a potential exploit vector? Sub-thread at https://news.ycombinator.com/item?id=11111300 https://news.ycombinator.com/item?id=11111300 . * Are there any BIND settings that are potential mitigators? Sub-thread at https://news.ycombinator.com/item?id=11110646 https://news.ycombinator.com/item?id=11110646 . * What happens if one's DNS proxy server doesn't itself support sending >2048 byte answer messages to the BIND DNS client library in the first place? Sub-thread at https://news.ycombinator.com/item?id=11111617 https://news.ycombinator.com/item?id=11111617 . * How exploitable is this? What about Windows? Sub-thread at https://news.ycombinator.com/item?id=11110443 https://news.ycombinator.com/item?id=11110443 . * What about MacOS 10? Sub-thread https://news.ycombinator.com/item?id=11113471 https://news.ycombinator.com/item?id=11113471, and a mention of BSD libc at https://news.ycombinator.com/item?id=11111702 https://news.ycombinator.com/item?id=11111702 .

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.
caf 11y ago
I don't think a reverse query will tickle this bug, because this bug requires simultaneous A and AAAA lookups to be triggered whereas a reverse query uses a single PTR lookup.

pjmlp 11y ago

> 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. It was already clear in 1961 when Burroughs used Algol and C wasn't even born. It was clear when Hoare stated on his speech in 1980: "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." I can quote lots of other security research papers since computers exist. But then UNIX workstations took over the computing world, bringing C with them.

minimax 11y ago
I think the other thing that changed is that branch predictors are roughly infinitely times better than they were in 1980. The is-this-subscript-ok check should be easily predictable and I wonder if these checks even cost anything in a hot loop on a modern CPU.
- kevingadd 11y ago
  They have a measurable cost, and performance-obsessed developers/users hate the cost. But it's a lot smaller than it used to be, and modern compiler/JIT research is yielding ways to safely eliminate/hoist a lot of the checks.
- pjmlp 11y ago
  After Z80 and Sinclair Basic, my next languages were GW-Basic, Turbo Basic and Turbo Pascal, followed by many others. The Borland languages like many other that allowed for system programming in those days, allowed for disabling bounds checking, as Borland customers weren't like Hoare ones. I never felt the need to disable them. Yes they did had a few ms to the program execution, but nothing that would impact the user experience of the application. This is one of the biggest problem in our industry, specially among C and its derived languages (C++, Objective-C), to micro-optimize each code line without any sort of measurement how it impacts the final application. Of course there are cases where it really matters, like HPC, games and such, but those are a tiny portion of the software that gets written every day.

avian 11y ago

> It is time for the bimonthly Internet security meltdown. Time for the bimonthly Hacker News hour of C and C++ hate.

deleted 11y ago
[deleted]
- pjmlp 11y ago
  Yes, UNIX was adopted by the corporations and brought C with it. Some people don't get it that before it happened we were happily using other systems programming languages way safer than C.
  - cmrx64 11y ago
    (For the record, grandparent originally ended with "Some people just don't get it")
    - deleted 11y ago
      [deleted]
    - tosseraccount 11y ago
      What do you think?
  - voidlogic 11y ago
    >Some people don't get it that before it happened we were happily using other systems programming languages way safer than C. Maybe some people, but most systems programming was done is Assembly before C.
    - TeMPOraL 11y ago
      No, you're not getting it :). There was a whole world besides Assembly and C, now mostly lost to us. E.g. Lisp machines, which even had hardware support for Lisp-specific things like tagged pointers.

masterleep 11y ago

An intermediate step is to run everything under AddressSanitizer, since it's fast enough for many cases. See, for example: https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html https://blog.hboeck.de/archives/879-Safer-use-of-C-code-runn...

hannob 11y ago
It likely won't help. I excluded glibc from using ASAN to let this work. It is theoretically possible to use ASAN on glibc as well, but it's complicated and certainly not ready for any kind of production use. Also although this is my work, it's far from clear to me whether using ASAN in production really is a useful thing. Practically I'd rather suggest looking at the safestack and CFI features of clang for production use instead.
- yugr 11y ago
  BTW at least Clang's ASan is capable of detecting CVE-2015-7547 (in https://groups.google.com/forum/#!topic/address-sanitizer/ttPxNhTK9TU https://groups.google.com/forum/#!topic/address-sanitizer/tt...).

tkinom 11y ago

Does rust use getaddrinfo()? grep -irn getaddrinfo . ./src/libstd/sys/common/net.rs:123: try!(cvt_gai(c::getaddrinfo(c_host.as_ptr(), ptr::null(), ptr::null(), ./src/libstd/sys/windows/c.rs:1235: pub fn getaddrinfo(node: const c_char, service: const c_char, ./src/libstd/sys/windows/net.rs:69:/// Provides the functionality of `cvt` for the return values of `getaddrinfo` How many places doesn't rust source code use C structures or call C APIs? In the rust source tree, run this: grep -irn '[^a-zA-Z0-9]c::' . |wc 615 3143 56000 grep -irn 'extern "C"' . |wc 279 1719 23448

chc4 11y ago
You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!" Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust. Also, extern "C" is for C FFI exports not calling C APIs. The world unanimously decided C FFI is the least common denominator, so its not like Rust can provide a different API with better safety hints.
- ploxiln 11y ago
  Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragmatism) unrelated to the fact that some people still like C. Just as an ironic aside - C enthusiasts may even have switched to musl-libc already, and are not affected by bugs in glibc, while rust-loving people are vulnerable! Also interesting, Go has for a long time supported using its own dns resolver instead of libc, but only recently in go 1.5 uses the go dns resolver by default on unix systems.
  - steveklabnik 11y ago

deleted 11y ago

[deleted]

cft 11y ago

>Patch ASAP What exactly do you patch? Say you have a TCP server, written in Python or in Go. Do you have to update Python and Go ASAP then and recompile the Go server? Custom compiled Apache, Nginx? Recompile those? That's a lot of work..

r1ch 11y ago
Unless you statically link glibc, updating glibc is enough.
nitrogen 11y ago
If you have dynamically linked libc (which you should), you only need to upgrade libc and restart all network processes. [Does anyone know if systemd in pid1 calls getaddrinfo? If so, this is another good reason for a minimal pid1, as you will need to reboot]
- Xylakant 11y ago
  you need to restart all processes that might do a network address lookup. That's pretty much every daemon.
- noselasd 11y ago
  You don't need to reboot to restart systemd, you can run systemctl daemon-reexec
- the_why_of_y 11y ago
  No reboot needed: man systemctl daemon-reexec Reexecute the systemd manager. This will serialize the manager state, reexecute the process and deserialize the state again. This command is of little use except for debugging and package upgrades. Sometimes, it might be helpful as a heavy-weight daemon-reload. While the daemon is being reexecuted, all sockets systemd listening on behalf of user configuration will stay accessible.
asveikau 11y ago
Unless you are linking statically (and I don't really understand why you would) you update glibc and that's it. This question had me feeling kind of old. Does nobody learn what shared libraries are anymore?

weinzierl 11y ago

> The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. Why are browsers missing in the list? Don't they use getaddrinfo() as well?

msbarnett 11y ago
Literally the next sentence: > We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.
- weinzierl 11y ago
  I read that, I just found the examples strange. Browsers are incredibly important for an incredible number of people while curl is not.
jimrandomh 11y ago
I'm not sure, but I suspect that major browsers may have their own DNS client implementations, or be calling getaddrinfo from within sandboxed contexts.
- collinmanderson 11y ago
  Chrome uses a custom DNS client implementation. https://plus.google.com/+WilliamChanPanda/posts/FKot8mghkok https://plus.google.com/+WilliamChanPanda/posts/FKot8mghkok "The problem is that Chromium is issuing too many DNS queries in a short period of time, which may overload upstream devices (typically cheap NAT routers) ... which will then ignore DNS queries for a period of time."
vdfs 11y ago
I tried the exploit server, Firefox crashed right after changing the DNS name server.
- muraiki 11y ago
  That is not awesome :(

ploxiln 11y ago

You already have the freedom to run your webservers as mirageos unikernels (with a networking stack written in ocaml). You already have the freedom to write and run everything you want in such an environment. But what you really want, is to force other people to write code for you, but in a language you prefer (and for it to be easy and convenient for you). Good luck with that.

yyin 11y ago

Is djbdns vulnerable? It does not use these routines. I've never needed ENDS0, but maybe the need will arise someday. Meanwhile... Short term, I'd prefer to expunge all "C networking code" originating from BIND authors, e.g., libresolv.

cft 11y ago
Relatedly, if I point dnscache in djbdns to Google's DNS server as a temp fix (8.8.8.8) in /etc/resolv.conf , will that mitigate the threat?
JdeBP 11y ago
The fact that djbdns doesn't use BIND code is not really relevant. The problem at hand is in the BIND DNS client library that is compiled and linked into applications. It's triggered by sending responses larger than 2048 bytes to those applications. The only way that djbdns factors into it is whether an attacker, running a content DNS server out on Internet, can manage to get such a DNS response through a DNS proxy server such as dnscache, to that BIND DNS client library code running in the application. Now one might think that the discussion at https://news.ycombinator.com/item?id=11110646 https://news.ycombinator.com/item?id=11110646 already covers this. All that the content DNS server has to do is set the TC flag in the DNS/UDP response, and it can quite happily get the proxy DNS server to re-try via DNS/TCP. The interesting point is that in fact that discussion does not cover this. This is because the idea that one can exploit this with a malicious content DNS server has as its unstated premise that DNS/UDP and DNS/TCP responses are passed straight through caching DNS proxies. This is the case for some DNS proxy softwares, where if the data have just come in from the back end and form a complete answer, they are passed through as the front-end answer. It isn't the case for dnscache. dnscache always answers from cache, even if the data have just arrived from a back-end transaction. So those "crafted DNS responses" beginning with 2048 bytes of valid protocol, that the malicious content DNS server has to generate, have to survive being unpacked, stuffed into dnscache's cache, extracted back out of dnscache's cache, and turned into an answer response by dnscache's from-scratch answer construction code. And this without being able to use the authority or additional sections, without being able to use more than one (non-CNAME) RRset in the answer section, and without any guarantee of any given RRset ordering. This is ... somewhat difficult. The devil in the details of this problem lies in one sentence of the analysis that accompanies the patch: > Overflowing bytes are entirely under the control of the attacker and are the result of a crafted DNS response. If you've done as the people at https://news.ycombinator.com/item?id=11112527 https://news.ycombinator.com/item?id=11112527 and https://www.reddit.com/r/netsec/comments/462xx0/glibc_getaddrinfo_stackbased_buffer_overflow/d02undj https://www.reddit.com/r/netsec/comments/462xx0/glibc_getadd... did, you might have convinced yourself how simple it is to exploit this. Just set up a malicious content DNS server that does what this does, and Bob's Your Uncle. But in fact those demonstrations are not how DNS lookups work. People do not point the BIND DNS client library at (malicious) content DNS servers. The DNS client library is pointed at the front end of a proxy DNS server, which performs back-end lookups to the (malicious) content DNS servers. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-query-resolution.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn... So one has to take into account what the proxy DNS server does in between its back end and its front end. The response returned to the BIND DNS client library from the front end is not "entirely under the control of the attacker". As in the case of dnscache, where front end responses are constructed from cache and from scratch, it's actually quite difficult for the attacker to control it at all, let alone cause dnscache to send a valid-flawed-valid response sequence. It's not just dnscache where this is a difficulty for an attacker, either. Which is why the analysis talks of man-in-the-middle attacks. To exploit this with far greater chance of success, one gets in between the BIND DNS client library and the proxy DNS server, or just plain supplants/subverts the proxy DNS server. Which is yet another reason why it's a good idea to run a proxy DNS server locally, on each machine or at least on the LAN, and make sure that "local" traffic is blocked at relevant machine/LAN borders. An attacker who can field DNS traffic to [::1]:53 or 127.0.0.1:53 in order to be that man in the middle has already had to overcome some quite tricky obstacles. (-: * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-obtaining-proxy-service.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn... It's worth noting that we've been here before. A lot. * https://cr.yp.to/djbdns/res-disaster.html https://cr.yp.to/djbdns/res-disaster.html * http://www.kb.cert.org/vuls/id/542971 http://www.kb.cert.org/vuls/id/542971 * http://www.kb.cert.org/vuls/id/803539 http://www.kb.cert.org/vuls/id/803539 * http://www.kb.cert.org/vuls/id/844360 http://www.kb.cert.org/vuls/id/844360 ... And so on.

djsumdog 11y ago

All this "Let's replace everything with Rust" is extremely childish. Be wary of making programming languages a religion. The Java zealots did it, and you can see the results where full Java projects are used in places where a 20 line Python script would have been easier. If you're serious, one of your pet projects should be trying to implement BSD sockets with Rust. Then try compiling some C apps against your implementation. Then do some performance tests showing memory and time benchmarks of your Rust vs libc implementation. Do a blog post on it. Then we'll take you seriously.

scotchmi_st 11y ago
I think you're misreading what he says. "...replacing it with Rust /or pretty much anything else/" (emphasis own). The point is we should be replacing C with /pretty much anything else/. Rust looks like the most obvious (but not necessary correct) candidate. Also performance is not such a big deal as dictate security considerations. One's fancy medical web app is worthless if it leaves the potential for theft of medical data.
AsyncAwait 11y ago
The parent actually said "Rust or pretty much anything else", which means any memory safe language. It just happens that Rust came to his/her mind as the first choice probably because it's been talked a lot about lately on HN and memory safety is its explicit focus. I see no "programming languages a religion zealotry" in parents post, but I see a lot of bitterness in yours. Perhaps it's time to reflect.
- reality_czech 11y ago
  There are tons of vulnerabilities discovered every month. Most of the them are in Java, PHP, javascript, etc. software because that's what the majortiy fo new code is written in. And those languages have features that can lead to security holes, which C doesn't have. For example, PHP supports eval(), JS has cross-site scripting attacks, Java has classloaders, etc. etc. But somehow only the vulnerabilities in C language software get programming language zealots exited. So maybe you should reflect.

sangnoir 11y ago

> it's pretty clear at this point that we need to expunge all C language networking code from the world Will you bell the cat? I'd pay a lot of money to see Linus' reaction to your massive network-stack replacement kernel patch written in Rust. More seriously though, who is prepared to fund this? Is the risk worth that much effort? Because I see a lot of people being vocal about it on HN, but no real attempt is made to come up with a safe Rust-based alternatives

latenightcoding 11y ago

How did I know this would turn into a C vs Rust debate

JdeBP 11y ago
There are a few interesting points in this discussion that all of the C/Rust/C++/ObjectiveC/Go/Java discussion has swamped. For those who would like to find the discussion that is not argument about computer programming languages: * Is Google Public DNS a potential mitigator? Sub-thread at https://news.ycombinator.com/item?id=11113113 https://news.ycombinator.com/item?id=11113113 . * Is Google Public DNS a potential exploit vector? Sub-thread at https://news.ycombinator.com/item?id=11111300 https://news.ycombinator.com/item?id=11111300 . * Are there any BIND settings that are potential mitigators? Sub-thread at https://news.ycombinator.com/item?id=11110646 https://news.ycombinator.com/item?id=11110646 . * What happens if one's DNS proxy server doesn't itself support sending >2048 byte answer messages to the BIND DNS client library in the first place? Sub-thread at https://news.ycombinator.com/item?id=11111617 https://news.ycombinator.com/item?id=11111617 . * How exploitable is this? What about Windows? Sub-thread at https://news.ycombinator.com/item?id=11110443 https://news.ycombinator.com/item?id=11110443 . * What about MacOS 10? Sub-thread https://news.ycombinator.com/item?id=11113471 https://news.ycombinator.com/item?id=11113471, and a mention of BSD libc at https://news.ycombinator.com/item?id=11111702 https://news.ycombinator.com/item?id=11111702 .