Hacker News new | ask | show | jobs
by freedomben 2730 days ago
The real bomb-shell here that I find terrifying, is that there is still an open and (likely) exploitable bug in glibc that has been around for years and isn't getting attention. glibc is everywhere and used by almost everything. If you program in almost any modern language like ruby, node.js, python, java, C, C++, or more, you are calling functions in glibc.

Note: Unless you use an alternative libc implementation such as musl, which is standard on things like Alpine Linux for example. However glibc is by far most common.

2 comments

While that does seem like a buried lede, I felt it wasn't my place to raise alarms about a 2 year old bug that may have been fixed.

The bug description certainly makes it sound very serious. If its not fixed in upstream, it at least seems fixed at the distribution level since Ubuntu 18.04 and newer don't suffer from the issue. Or if they do, it can't be reached via the same code in ul.

Golang infamously tried to not use libc at all and just use the kernel syscalls by itself. I think they now do use some stuff from glibc? Or maybe they only use the libc on OSes where the kernel interface is not stable, like Windows?

Also, I don't know how much of glibc is used by openjdk, but potentially not a lot because the jvm wants to behave the same on all platforms, so they don't want to rely on behaviors of the libc.

WinAPI for kernel32 is to Windows what libc is to POSIX, approximately. It's a lower level API than a language runtime and is more agnostic to language specifics, but is higher level than a kernel syscall interface.
Go now calls through libSystem on macOS and iOS, at least: https://golang.org/doc/go1.11#runtime
Going from memory here, and it's been a little while (< a year), but Go at least uses enough glibc that if you use certain functions it won't statically link on linux by default anymore, so I corroborate your statement :-) I ran into this when working on https://github.com/FreedomBen/findref which is a command-line utility written in Go