Yesterday, right after I had the displeasure of dragging myself into work with a head attached to my body that hurt oh so much, I found out to my slight dismay about the GHOST vulnerability (and of course of the ops teams working to patch the servers). I scrambled to find out what in the world it was all about. This Qualys Security Advisory has a very scary rundown of the bug.
I have a Debian machine, in the cloud, with DigitalOcean, that I use for running all sorts of crazy things. I patched the box up, though there sure was a long list of updates. The thing you come to hate about Windows, if you use it, is that every update, security or feature-wise, to the OS requires a complete reboot, even on servers. Contrarily, it’s the thing you love about Linux, if you use it. But this bug was different. In a number of discussions about the GHOST vulnerability I read, it was advised, for a successful completion of the patch process, to fully reboot affected servers. It sounded ridiculous but after peeling away the veneer of absurdity, it made all the sense in the world. The GHOST vulnerability affected “glibc” which is a very important part of the Linux OS. An unnamed number of applications, services, and OS components use “glibc”, and as such, there was no surefire way of knowing that everything running on a Linux system that depended on “glibc” was restarted or reloaded in a way that caused it to use the updated version of “glibc” — except for a complete reboot.
I did that. I forgot to mention I run OpenVPN on my machine which uses the TUN/TAP interface drivers on the system. When the system got back to its feet, which was rather quick, I couldn’t get OpenVPN to start. It bailed out after coughing up this:
SIOCSIFADDR: No such device : ERROR while getting interface flags: No such device
SIOCSIFDSTADDR: No such device : ERROR while getting interface flags: No such device
SIOCSIFMTU: No such device failed!
Naturally, the “tun” interface wasn’t up. I couldn’t remember, when I first set up OpenVPN, whether I set up the “tun” interface myself. But a peek at the syslog told me something:
kernel: [ 228.358361] tun: Unknown symbol ipv6_proxy_select_ident (err 0)
kernel: [ 228.360982] Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev- instead
Confused, I looked around and found this bug report. Somebody, probably the afflicted, found out that DigitalOcean was playing silly by not changing the kernel version to boot from to the one updated to. The solution was simple: Boot the server from the DigitalOcean panel with the latest kernel version selected from the settings page for the droplet. That fixed it.
In passing, I’d like to mention this article here which makes a case that WordPress can be used to exploit the vulnerability owning to the way WordPress handles ping-back comments.