So Tuesday a security firm called Qualys dropped an advisory for something they nicknamed GHOST, and by Wednesday my phone was buzzing with alerts from three different monitoring tools I have hooked up to this dinky little Digital Ocean droplet the blog runs on. Great. Love that for me.
The short version, if you missed it: it's a buffer overflow bug in glibc, the C library that basically everything on a Linux box links against, tucked inside the gethostbyname() and gethostbyname2() functions. CVE-2015-0235, if you want to look it up yourself. The bug's actually been sitting in there since 2000 — it got quietly fixed back in glibc 2.18 in 2013, except almost nobody realized the fix closed a security hole, so a bunch of long-term-support distros never bothered backporting it. Which means if you're running something like Ubuntu 12.04 LTS or Debian 7 or CentOS 6 (and I'd bet a decent chunk of you reading this on your own VPS are), you were sitting on it too.
Qualys built a working proof-of-concept exploit against Exim, the mail server, and got remote code execution without any authentication. That's the part that got everyone's attention. This wasn't some theoretical "well technically if the stars align" bug. It's the real thing.
Anyway. I self-host this blog, WordPress on a $5/mo droplet I've had since 2013, and I do all my own sysadmin because apparently I enjoy pain. So Wednesday night, instead of watching the last twenty minutes of whatever I'd queued up on Netflix, I was SSH'd into the box at 11pm checking my glibc version.
Here's basically what I did, in case anyone else is procrastinating on this:
Check if you're affected. Qualys posted a little C test program you can compile and run — search "GHOST test glibc" and you'll find it copy-pasted into about forty different blog posts by now, mine included below since I'm apparently one of them:
wget --no-check-certificate https://gist.githubusercontent.com/.../ghost.c
gcc ghost.c -o ghost
./ghost
If it prints "vulnerable" instead of "not vulnerable," congrats, you've got homework.
Patch it. On Ubuntu/Debian it's just:
sudo apt-get update
sudo apt-get install libc6
CentOS/RHEL folks, it's yum update glibc. Took maybe four minutes on my end, most of it waiting on a mirror that seemed to be having a rough night.
The annoying part: reboot. Because glibc gets loaded into basically every running process on the system, a patch doesn't actually take effect for a service until that service restarts, and since half your system depends on it, the actual advice everyone's giving is just to reboot the whole box. Not restart Apache, not restart MySQL. Reboot. Which is a weirdly nerve-wracking thing to do to a server you've had uptime bragging rights on for like 400-something days, but fine, I did it. Took about ninety seconds and nothing caught fire.
I'll be honest, my irritation here isn't really about the vulnerability itself. Bugs happen, that's software. It's more that I run one tiny blog on one tiny box and I still had to go do actual security triage on a Wednesday night because a library function I've literally never called directly in my life had a decade-old hole in it. That's the deal with running your own stuff though: nobody's doing this for you. If you're on shared hosting or something managed, your host probably already patched this without you noticing, which, fine, good for you I guess.
A few of the writeups floating around are also pointing out this affects way more than just web servers: anything doing a DNS-style hostname lookup through glibc is technically in scope, so router firmware, embedded devices, all sorts of stuff nobody's going to get around to patching for years, if ever. That part's the genuinely unsettling bit, not my little droplet.
If you haven't checked yet, go check. It takes ten minutes and you'll feel better than I did discovering it at 11pm on a work night.