Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Glibc getaddrinfo stack-based buffer overflow

googleonlinesecurity.blogspot.com

Post reply on HN
Print view View original

91–100 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#91

Post by tosseraccount »

pjmlp wrote: post #33
sargun wrote: post #22

Earlier quoted context omitted.

I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. In my mind, these use cases are quite limited though - integration into 3rd party libraries, legacy codebases, and working in embedded environments. I also agree that performance can be a reason, but see Knuth's opinion on premature optim…

Sometimes there isn't any other choice. For example, in the mobile OS space if you want to write native apps, without rewriting 100% of the application code per platform and avoid toolchain debugging headaches, C and C++ are the only languages available in iOS, Android and WP SDKs. In WP case, there are APIs like DirectX that aren't fully exposed via WinRT, so you need to write a C++ wrapper for those type of APIs. T…

Isn't slapping C onto objective C trivial for iOS and OSX? Just wrap to the GUI's objective C. You can use this trick for WTL on Window's C++, too.

Re: Glibc getaddrinfo stack-based buffer overflow

#92

Post by [deleted] »

cmrx64 wrote: post #80
pjmlp wrote: post #72

Earlier quoted context omitted.

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.

(For the record, grandparent originally ended with "Some people just don't get it")

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#93

Post by mocko »

btrombley wrote: post #84

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?

Yes, patching your OS (e.g. an apt-get update + apt-get upgrade) then rebooting once the vendor has released patches should be sufficient.

Re: Glibc getaddrinfo stack-based buffer overflow

#94

Post by sbov »

cnvogel wrote: post #52

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

Sure. But not doing something correct is far different from a security vulnerability.

Re: Glibc getaddrinfo stack-based buffer overflow

#96

Post by ptrincr »

Redhat (RHEL5 unaffected) - https://access.redhat.com/security/cve/cve-2015-7547 - https://access.redhat.com/articles/2161461

RHEL6 - 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 - update to glibc-2.17-106.el7_2.4.x86_64.rpm

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

SUSE - 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/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

Re: Glibc getaddrinfo stack-based buffer overflow

#97

Post by pjmlp »

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…

Are you are that Visual Studio C library is written in C++ with extern "C" and for Microsoft C is legacy, with .NET Native and C++ with compiler static analysis being the way forward?

Re: Glibc getaddrinfo stack-based buffer overflow

#99

Post by _0w8t »

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.

Re: Glibc getaddrinfo stack-based buffer overflow

#100

Post by autoreleasepool »

sargun wrote: post #22
Munksgaard wrote: post #2

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.

I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. In my mind, these use cases are quite limited though - integration into 3rd party libraries, legacy codebases, and working in embedded environments. I also agree that performance can be a reason, but see Knuth's opinion on premature optim…

> Can people tell me why they start projects in broad C++, and C still? I may be completely missing some piece of the puzzle.

Sure.

---

Compelling features:

- Unrivaled portability (yes, contrary to folklore C - and to a lesser extent C++ - is more portable than Java)

- Excellent libraries

- Excellent documentation and learning resources

- Unrivaled tooling

- perfect mapping to how the computer works

- Unrivaled performance (other than Rust)

- exceptional, engaging, and intelligent community (specifically referring to the cpp community)

---

Why start a C++ project today?

- you want to write a web browser

- you want a platform agnostc GUI

- you want to learn OpenGL or Vulkan

- you want to use Unreal and you're not a visual learner

- you're want to write the business logic for a cross platform application and share as much code as possible

- you're implementing you're own programming language

- your implementing an algorithm or data structure you've been studying

- you're bored

- you like programming in C++

- you want to learn template meta-programming

- you want to learn functional programming

- you want to learn how to write a device driver

- you need the performance

- you are not writing mission critical software (aka 99% of all side projects)

- you're a curious person

- you're a contrarian and everyone you know uses Java

- you want to become a more well-rounded engineer

- you want to learn about the ins and outs of language design and features

- you want make a lot of money

- you only know C++

Those are a few reasons. Hope that helps you solve your puzzle.

PS: Do the anti-C people realize that a kernel in Rust/Nim/whatever would be under a big unsafe block anyways? Yeah, you have to program "unsafe" code eventually. Those nice high level abstractions are not omnipresent, you know. They need something to abstract.

Post reply on HN