Why don't more distros use the lighter weight C runtimes?
Why would that matter? This was a bug in a POSIX function that all C libraries would be required to implement.
Glibc getaddrinfo stack-based buffer overflow
161–170 of 480 posts
Re: Glibc getaddrinfo stack-based buffer overflow
#162Earlier quoted context omitted.
"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.
Indeed. But my point was there's lots and lots of ways code can have bugs. Vulnerabilities like these are serious, but rushing through a reimplementation in another language is bound to fail in a multitude of other ways.
What we need is not to have knee-jerk reactions akin to angry mops carrying flaming torches and sharpened pitchforks. What we need is to praise the excellent work researchers are doing and to offer our time and/or money into:
a) more security research,
b) development of experimental alternatives written in memory safe languages,
c) yet more security research except this time on the experimental counterparts,
d) thorough testing of the experimental counterparts to ensure functional compatibility.
Maybe a few years down the line we will have something usable in a few bleeding edge Linux distributions, but it will be even longer still before it will have the backing of Debian, RHEL and SLES.
Re: Glibc getaddrinfo stack-based buffer overflow
#163Earlier quoted context omitted.
> 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?
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.
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.
Re: Glibc getaddrinfo stack-based buffer overflow
#164Can 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…
I wouldn't say that UNIX workstations became truly popular until after Mac OS X took off sometime in the 2000s. C and C++ were enormously popular in the 90s, if not earlier. They were really common for Mac and Windows programming, and I don't think that had anything to do with the UNIX connection.
Re: Glibc getaddrinfo stack-based buffer overflow
#165Why don't more distros use the lighter weight C runtimes?
Why would that matter? This was a bug in a POSIX function that all C libraries would be required to implement.
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/pos...
compare with
http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...
Re: Glibc getaddrinfo stack-based buffer overflow
#166Earlier quoted context omitted.
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.
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.
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.
Re: Glibc getaddrinfo stack-based buffer overflow
#167Why 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.
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.
Re: Glibc getaddrinfo stack-based buffer overflow
#168Earlier quoted context omitted.
... and apple runs of top of BSD. C popularity pre-dates workstations. DEC (Digital Equipment Corporation ) , maker of popular mini computers, used it extensively.
I only bothered to use C when forced into UNIX world via Xenix. Yes Apple runs on top of BSD, because they weren't able to write a new OS and had to buy one, which happened to be built on top of BSD. Once upon a time they had their OS written in Object Pascal, but then they decided to rewrite it in C to welcome those UNIX devs. Nothing prevents them to rewrite parts of the OS in Swift after the language gets more mat…
What Apple OS was written in Object Pascal? It looks like they had an app framework written in that language, but the OS never was. I believe the Mac OS at the time was predominantly written in assembly, possibly with some (non-object) Pascal parts.
Re: Glibc getaddrinfo stack-based buffer overflow
#169Earlier quoted context omitted.
Every engineering decision has costs as well as benefits. It's the same reason soldiers only wear heavy armour in the centre of their chests and backs. Why don't we armour the rest? Because the cost outweighs the benefits ... and the tooling (i.e. medevac and modern medicine) makes up for the deficits.
>Every engineering decision has costs as well as benefits. This is only true if you are superstitious or religious and believe that good things that happens to you (or humanity in general) must be balanced out by something bad happening.
That's such an irrational assertion, ironically enough. Every decision has a trade off, even non-engineering decisions. It's called opportunity cost.
Re: Glibc getaddrinfo stack-based buffer overflow
#170Why don't more distros use the lighter weight C runtimes?
Most of them aren't audited at all.
If you switched SSL library from OpenSSL after Heartbleed, odds are you went from bad to worse.