[flagged]
Glibc getaddrinfo stack-based buffer overflow
41–50 of 480 posts
Re: Glibc getaddrinfo stack-based buffer overflow
#42Can 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.
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
Re: Glibc getaddrinfo stack-based buffer overflow
#43Can 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…
C is still the lingua franca; it's the only toolchain you can rely on a target system having, and the only real usable interface for calling between code in different languages.
So my theory is that it's not so much that people are especially inclined towards starting projects in C, but that projects in C have fewer barriers to distribution and thus adoption.
By natural selection, C code spreads and becomes standard; programs in Java, JS, Ruby, Haskell, Ocaml, etc. don't tend to leave their native ecosystem.
Re: Glibc getaddrinfo stack-based buffer overflow
#44Can 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…
> 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.
On Linux it's easy: It is (or was, until very recently) the least sucky alternative. All others have (or had) issues with OS support (C#), distribution (Java: OpenJDK vs. Oracle JDK; Python: 2.5 to 3.4 parallel in use by different distributions; Vala: Every compiler update breaks the language; etc. pp.), availability of libraries (Ruby, PHP, Perl… for anything that's not their speciality) or general obscurity (OCaml, …).
Go and Rust (and JS, C# and Vala recently) seem to be changing this, thankfully. But those too will depend on the availability of high-quality bindings for all the C(++) libraries you have to use to get anything substantial done.
Re: Glibc getaddrinfo stack-based buffer overflow
#45[flagged]
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.
Re: Glibc getaddrinfo stack-based buffer overflow
#46Why don't more distros use the lighter weight C runtimes?
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.
Re: Glibc getaddrinfo stack-based buffer overflow
#47Are 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 sure how likely that'll be. It's definitely possible, but I think there are going to be a few hurdles. The main one being, symbol versioning.
This is important if you export multiple symbols for a function, that is, have a program that depends on a specific implementation of a function. That could mean you depend on different versions of the same library ("functionname@@VERSION_1, functionname@@VERSION_2"), or completely different implementations of a function ("functionname@@IMPL_X_VER_1", "functionname@@IMPL_Y_VER_2").
Wait a second. That seems like a strange feature to want, right? Well. It's particularly useful for runtime library fun stuff. LD_PRELOAD in a library that magically changes the implementation of function. A cool example of this is of preeny[1], a collection of libraries to help with debugging.
Additionally, it's useful for replacing libraries that would depend on C implementations without having to recompile them, though some preloading magic at runtime may be required.
This is only the thing, for me at least, that's blocking for making Rust system libraries. Now, any sane person may say, "Cargo will take care of versions and stuff", and that's true. Sadly, that's not the case if you ever want to use those nice and safe Rust libraries from C though.
Though, I may be completely wrong about the state of symbol versioning in Rust. I simply ran 'nm -g libopenssl.so' on sfackler's rust-openssl project and failed to see any @@ in the output -- that is specifically being exported, and not re-exported, by libopenssl. There may be better libraries to use, but eh.
I could be completely wrong on this though. I've been mainly going off of what I read here[2], and here[3] (alternatively, for a more in-depth version, try here[4]).
TL;DR: symbol versioning may not be a thing.
Disclaimer: I've had to use symbol versioning pretty heavily, so it's important to me. I could also be completely wrong about Rust not having it.
[1]: https://github.com/zardus/preeny [2]: https://gcc.gnu.org/wiki/SymbolVersioning [3]: https://www.akkadia.org/drepper/symbol-versioning [4]: https://www.akkadia.org/drepper/dsohowto.pdf
Re: Glibc getaddrinfo stack-based buffer overflow
#48This 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.
Re: Glibc getaddrinfo stack-based buffer overflow
#49Can 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.
"memory safe" languages aren't a silver bullet and urgently rewriting core libraries in a new language can be more dangerous than our current process of analyzing and fixing the existing vulnerabilities in our current libraries. However I'm all for experimental research projects developing alternative solutions.
Of course, there's no silver bullet.
But this is yet another bug that could not exist at all in a language with automatic memory management. And there are lots and lots of those bugs.
Re: Glibc getaddrinfo stack-based buffer overflow
#50Has 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]