Ghostwriting a Qualys horror story for maximal FUD (fear, uncertainty, and doubt)

Summary: Responding to the media blitz which paints GNU/Linux as insecure despite the fact that bugs were evidently found and fixed

THERE IS something to be said about the "top" news regarding GNU/Linux. It's not really news. The so-called "GHOST" publicity stunt needn't be repeated by FOSS sites. It is about a bug which was patched two years ago, but some sites overlook this important fact and stick lots of spooky logos, playing right into the hands of Qualys, an insecurity firm (making money from lack of security or perception of insecurity).

We have watches the 'news' unfolding over the past day and a half and now is a good time to explain what we deal with. The so-called "GHOST" (all capital letters!) bug is old. Qualys is going two years ago into bugfixes, giving a name to the bugfixes, then making plenty of noise (all over the news right now). Qualys does not look like a proxy of Microsoft or other GNU/Linux foes, but it is self-serving. Insecurity firms like Qualys probably learned that giving a name to a bug in GNU (SJVN mistakenly calls it "Linux", but so do many others) would give more publicity and people will pay attention to brands and logos rather than to substance. Just before Christmas an insecurity firm tried to do that with "Grinch" and it turned out to be a farce. SJVN says that this old "vulnerability enables hackers to remotely take control of systems without even knowing any system IDs or passwords."

Well, it was patched back in 2013. Use of names for marketing is what makes it "news"; the opportunists even prepared a PRESS RELEASE and pushed it into 'big' sites like CNN. It has marketing written all over it, just like "Heartbleed" that had strong Microsoft connections behind the disclosure. It is sad that Linux sites fall for this. Phoronix copies the press release as though it's reliable rather than self-promotional. Michael Larabel writes: "The latest high-profile security vulnerability affecting Linux systems us within Glibc, the GNU C Library."

It is not "latest", it is 2 years old. Larabel says that "Qualys found that the bug had actually been patched with a minor bug fix released on May 21, 2013 between the releases of glibc-2.17 and glibc-2.18."

OK, so it's not news. FOSS Force cites SJVN to amplify the scare and other FOSS sites are playing along as though this is top news. It oughtn't be. It is already widely patched (maybe requiring a reboot), so let's patch and move on (unless it was already patched upstream/downstream years ago). IDG has already published at least three articles about it [1, 2], including one from Swapnil Bhartiya, who is not too alarmist to his credit. He noted that "there was a patch released back on May 21, 2013, between the releases of glibc-2.17 and glibc-2.18. However it was not considered to be a security risk and thus major Linux distributions that offer long term support and get security updates remained vulnerable, including Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7 and Ubuntu 12.04."

It affects very specific versions, mostly long-term support releases that already have reliable patches available. It should be clear that some headlines such as this or that clarify the limited scope of impact (not bad reporting) unlike the alarmist trolls.

What Techrights generally found was that early coverage came from so-called 'security' sites or blogs of insecurity firms that try to sell their services (e.g. [1, 2, 3]). These set the tone for many.

The response to this bug is proportional to the perceived danger (e.g. due to media hype), not the severity of the bug. Some security news sites [1, 2] focus on names and logos while facts remain only a side issue. This so-called "ghost" nonsense (some lines of code basically) was fixed 2 years ago and as the blog post "long term support considered harmful" explains it: "In theory, somebody at glibc should have noticed that fixing a buffer flow in a function that parses network data has security implications. That doesn’t always happen, however, for many reasons. Sometimes the assessment isn’t made; sometimes the assessment fails to consider all possible exploit strategies. Security bugs are “silently” fixed frequently enough (without evil intentions) that we should consider them a fact of life and deal with them accordingly."

Some of the worst kind of coverage we found came from The Register with its flamebait headlines (scary headlines for maximum effect) and the troll Brian Fagioli. They are only some among many who are using the name to come up with puns and FUD. Jim Finkle is back to his GNU/Linux-hostile 'reporting', bringing this to the corporate media (there is some in the UK also) and LWN quickly cited the GNU/Linux-hostile Dan Goodin. He called "Highly critical" a bug that was patched two years ago.

Debunking some of the latest security FUD we had Fedora Magazine which stated "don’t be [worried], on supported Fedora versions."

For unsupported version there is a lot more than this one bug that one needs to worry about.

Apple fans were quick to take advantage of the news, despite the fact that Apple is leaving systems vulnerable for many months, knowingly (like Microsoft does, until Google steps in).

See, with proprietary systems one knows for a fact that there is no security. With GNU/Linux is an open question and it depends on what measures one takes to keep it secure. For Apple and Microsoft security is not at all the goal; back doors and unpatched flaws are not really as "interesting" and important for them to patch as helping spying agencies. Google is not at fault here, Google just saw that Apple and Microsoft had no plans to plug serious holes -- a patch evidently wasn't going to be made ready before the public finds out about it, owing to Google. Apple chooses to blame Google; same as Microsoft. They should only blame themselves both for the bugs and for negligence after the bugs were highlighted to them. There is no room here for properly comparing GNU/Linux (Free/libre) to OS X or Windows (proprietary) because evidence clearly shows that the latter are not interested in security and not pursuing security when it is trivially possible.

What we find curious amid the latest FUD campaign is that Apple back/bug doors are not as widely publicised as a GNU bug that was patched 2 years ago and mostly affects LTS systems (which already have patches available). "Nothing I can think of," said a reader of ours about this media hype, "but the LTS model followed by RHEL and Ubuntu have different goals and purposes than the short, fast development cycle like OpenBSD."

Nobody is forced to use an LTS release and those who choose it must be aware of the potential risk.

Regarding the other FUD that flooded the press in recent weeks, targeting for the most part Google and Android, our reader XFaCE wrote the following:

I assume you want to write about that new Android vulnerability. Basically I can see the narrative being pushed through three points

- Microsoft supported Windows XP/7/etc. for years, why doesn't Google support old Android versions

- Google told Microsoft about a very old bug in their software, so they are hypocritical

- Heartbleed bug was fixed way back for 4.1.1

For the last point, it's a bullshit comparison because

a) 4.1.1 was one point release where upgrading to 4.1.2 fixed the issue (it was already fixed back when 4.1.2 was released)

b) The fix was one file, as evident by XDA members patched it themselves on phones manufacturers refused to upgrade to 4.1.2 SOURCE: http://forum.xda-developers.com/showthread.php?t=2712916

c) As shown by the link, a lot of manufacturers DIDN'T update certain 4.1.1 devices to 4.1.2, hence proving Google's point. The fix there was SIMPLE, but the OEMs didn't bother to do it

With Webview, not only is webview involved, but so is the webkit rendering engine, so the fix for all those previously releases is much more complicated

As for the second point, Google did catch it, with KitKat, and furthermore made KitKat supported on more low-end devices so theoretically older 512mb or less devices could be updated

For example, HTC said (when Jelly Bean 4.1 came out) that they would not update any device with 512 mb of RAM (SOURCE: http://www.cnet.com/news/htc-one-v-and-desire-c-will-never-get-jelly-bean/ ), so naturally when KitKat came out, they updated those devices because the OS officially was designed for such low ram devices

oh wait

http://www.androidpit.com/android-4-4-kitkat-update-plans

"Later this year, the entry-level smartphone the HTC Desire 500, should also be seeing the KitKat update. However, the One X, One X+, One S, and One V will be left in the dust and will be receiving no more official updates from HTC."

So the OEMs are at fault for not upgrading the devices, not Google, which leads to point 1 - Google doesn't control the Android OEMs like Microsoft does OEM pay Microsoft for the support whereby Microsoft controls all updates, Google doesn't get paid or have the agreemeent in that way

OEMs like HTC could easily fix this by porting Kitkat to those devices, but they won't cause they want you to buy a new HTC phone or whatever phone brand

Techrights did not cover that (except in daily links) because it should be self-evident that free-of-charge Android upgrades make it inhernetly different from proprietary software and keeping up to data typically ensures security. A lot of the analogies (Android and Windows) were inherently flawed and the FUD rather shallow. ⬆