The maintainer of GLIBC has detailed the procedure

Jan 31, 2015 11:12 GMT  ·  By

Just a couple of days ago, it was revealed that Google actually patched the GHOST exploit in Chrome OS back in 2014 but didn't shared that info further down the chain. The maintainer of the GLIBC package for Google explains why that happened.

When an exploit, vulnerability, or any kind of issue is found in the open source ecosystem, it's usually patched right away and the other developers quickly find about it. That's enough to trigger a ripple effect that ensures that all the distros will be getting the update as soon as possible.

As you can imagine, problems are identified all the time and fixed. Users don't usually hear about them because they are not important. From time to time, a bigger issue is identified and maybe it gets a special name. Just a few days ago, news about an exploit in GLIBC got the name GHOST. It turns out that it wasn't a big deal.

The problem was that Google had already patched that problem for Google Chrome in 2014 and nobody knew. The rest of the world patched their systems a few days ago, when the news broke out. As it turns out (and as previously suspected), it wasn't something intentional, just the regular churn of bug fixes.

All is good in Chrome OS land

The maintainer of the GLIBC package explained why his fix was never pushed. It wasn't something done on purpose, it was just another fix for a problem among hundreds of others.

"I used to maintain GLIBC that is used in Google production. I didn't investigate whether the bug is exploitable or not (I just assume that all buffer overflows should be patched). I simply noticed that upstream has already fixed the issue, and so we backported the patch as we routinely do for other buffer overflows."

"If I was supposed to cry alarm, I would have to cry alarm every time there is a buffer overflow in glibc, which doesn't seem very useful," said maintainer Paul Pluzhnikov.

This pretty much solves the mystery of the GHOST patch in Chrome OS.