The 2017 Pwnie winner for lamest vendor response goes to Lennart Poettering for systemd. According to CSO which has reported on it, the Pwnie winners which were announced a few days ago, the summary for Lennart and systemd reads as follows:
The most spectacular mishandling of a security vulnerability by a vendor ended up winning a Pwnie for Lennart Poettering due to SystemD bugs 5998, 6225, 6214, 5144, 6237. The nomination reads: "Where you are dereferencing null pointers, or writing out of bounds, or not supporting fully qualified domain names, or giving root privileges to any user whose name begins with a number, there's no chance that the CVE number will referenced in either the change log or the commit message. But CVEs aren't really our currency any more, and only the lamest of vendors gets a Pwnie!"
(Score: 5, Insightful) by ledow on Monday July 31 2017, @08:13AM (3 children)
Yep.
Those small, modular, single-purpose commands that tend to work in perpetuity. Hell, I have a entire book on my shelf that describes the way that sed & awk can be used, and yet they are tiny and have barely changed in years.
And only change when NEW TYPES of attack come out (which is basically never if all you do it cat a given file to the screen, or act on stdin to output on stdout).
Gosh, I wonder why they were designed that way, rather than a hulking great thing that takes over all functions, inserts itself into critical code paths, reinvents the wheel badly, and offers all kinds of opportunities for misconfiguration, bad defaults (you wanted root, right?) and untested codepaths.
The irony is that systemd is possibly the antithesis of every bit of security-related advice anyone has ever given.
I blame Red Hat as much as Lennart, for allowing it to continue.
(Score: 2) by tonyPick on Monday July 31 2017, @08:29AM
+1 to this - Yes, using grep/sed/whatever from command line has a learning curve. I went through it in the mid 90's, and it's gained a couple of flags, but it's still all pretty much the same when it comes to getting useful work done.
Meanwhile you have to relearn the interface for shiny GUI toy of the month, which will be thrown away every six months, and is still less functional.
(Score: 1, Informative) by Anonymous Coward on Monday July 31 2017, @09:03AM (1 child)
You don't cat a file to the screen, you cat it to a terminal. And doing so with text from unknown origin may well be a security problem:
https://nvd.nist.gov/vuln/detail/CVE-2003-0063 [nist.gov]
https://nvd.nist.gov/vuln/detail/CVE-2008-2383 [nist.gov]
https://nvd.nist.gov/vuln/detail/CVE-2010-2713 [nist.gov]
https://nvd.nist.gov/vuln/detail/CVE-2012-3515 [nist.gov]
https://nvd.nist.gov/vuln/detail/CVE-2014-3121 [nist.gov]
Note that less by default converts those escape sequences to safe text, so it is a safer way to view text files.
(Score: 5, Insightful) by ledow on Monday July 31 2017, @11:13AM
Those are:
XTerm
XTerm
VTE
QEmu
and rxvt
DATA HANDLING ISSUES. Nothing to do with cat. It's like saying that "Apache" compromised your database because an employer put the whole list in a public_html folder.
And cat is dumb - it's the things that try to get clever and interpret data (e.g. terminals, less, etc.) that are the ones most likely to cause the problems. Acting on untrusted data is something that no program should mess with lightly. These programs did it and got it wrong. cat doesn't try. Which is why the CVEs listed have nothing to do with cat, but what happens when you put an escape sequence FROM ANY SOURCE into XTerm, etc. without checking it properly first.