Glibc getaddrinfo stack-based buffer overflow • Hacker News Board

Re: Glibc getaddrinfo stack-based buffer overflow

#61

Post by Xylakant » Tue, Feb 16, 2016, 4:23 PM UTC

dalore wrote: post #19

jimrandomh wrote: post #9

> "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 ex…

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…

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

Re: Glibc getaddrinfo stack-based buffer overflow

#62

Post by [deleted] » Tue, Feb 16, 2016, 4:24 PM UTC

avian wrote: post #26

jimrandomh wrote: post #9

> "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 ex…

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

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#63

Post by tremon » Tue, Feb 16, 2016, 4:27 PM UTC

mschuster91 wrote: post #28

spyrosk wrote: post #23

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

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

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?

Re: Glibc getaddrinfo stack-based buffer overflow

#64

Post by pjmlp » Tue, Feb 16, 2016, 4:27 PM UTC

IgorPartola wrote: post #42

pjmlp wrote: post #29

Earlier quoted context omitted.

Apparently until the UNIX culture that worships C exist, it won't happen. C only became a thing in computing after UNIX workstations became popular. Before it, there were quite a few safer systems programming languages to choose from, that got steam rolled by C adoption in OS SDKs. Due to its relation with UNIX, it will most likely happen with Apple (Swift), Microsoft (.NET Native, System C#, C++/GSL), Google (Java F…

> Java FTW on Android This made me smile. Need I point out that Android runs on top of Linux? Or that you can still use C/C++ on Android? http://developer.android.com/tools/sdk/ndk/index.html

Yes and I use it.

I also feel the pains that Android teams imposes on the NDK users to use it as little as possible.

If you bothered to read the contents of the link that you pushed.

"Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need"

Also Android Java is nowadays AOT compiled to native code. So whatever C and C++ dependencies there are, could certainly eventually be replaced if there were willingness to do so.

Besides, have you ever tried to implement libc in ANSI C, without language extensions and a sprinkle of Assembly?

Re: Glibc getaddrinfo stack-based buffer overflow

#65

Post by arielb1 » Tue, Feb 16, 2016, 4:28 PM UTC

autoreleasepool wrote: post #56

rtpg wrote: post #18

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

I'm not trying to be rude, but I'm sorry... Are you seriously suggesting that rewriting an implementation of the C standard library in a language that isn't C is something that makes any bit of sense? I think you have a fundemental understanding of the roll the C-standard library plays in the C language. Not to mention UNIX in general. Maybe you're suggesting we need an OS based in Rust instead of C (which is more re…

Rust can have the same ABI as C - rewriting NSS in Rust should not pose ABI problems.

Re: Glibc getaddrinfo stack-based buffer overflow

#66

Post by jblow » Tue, Feb 16, 2016, 4:29 PM UTC

JabavuAdams wrote: post #41

[flagged]

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

Re: Glibc getaddrinfo stack-based buffer overflow

#67

Post by gtirloni » Tue, Feb 16, 2016, 4:29 PM UTC

LinuxBender wrote: post #50

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]

https://access.redhat.com/security/cve/cve-2015-7547

Re: Glibc getaddrinfo stack-based buffer overflow

#68

Post by tosseraccount » Tue, Feb 16, 2016, 4:29 PM UTC

IgorPartola wrote: post #42

pjmlp wrote: post #29

Earlier quoted context omitted.

Apparently until the UNIX culture that worships C exist, it won't happen. C only became a thing in computing after UNIX workstations became popular. Before it, there were quite a few safer systems programming languages to choose from, that got steam rolled by C adoption in OS SDKs. Due to its relation with UNIX, it will most likely happen with Apple (Swift), Microsoft (.NET Native, System C#, C++/GSL), Google (Java F…

> Java FTW on Android This made me smile. Need I point out that Android runs on top of Linux? Or that you can still use C/C++ on Android? http://developer.android.com/tools/sdk/ndk/index.html

... and apple runs of top of BSD.

C popularity pre-dates workstations. DEC (Digital Equipment Corporation ) , maker of popular mini computers, used it extensively.

Re: Glibc getaddrinfo stack-based buffer overflow

#69

Post by Trellmor » Tue, Feb 16, 2016, 4:29 PM UTC

leesalminen wrote: post #54

I haven't seen anything come down through yum or apt-get yet. Does anyone know how this can be patched prior to that?

Debian has published security announcements for glibc [1] and eglibc [2]. Updates should be available from 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/msg00...

[2] https://lists.debian.org/debian-security-announce/2016/msg00...

Re: Glibc getaddrinfo stack-based buffer overflow

#70

Post by arielb1 » Tue, Feb 16, 2016, 4:30 PM UTC

leesalminen wrote: post #54

I haven't seen anything come down through yum or apt-get yet. Does anyone know how this can be patched prior to that?

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.