Open Source Sucks, Says Ballsy Infosec Firm
https://www.ispeech.org/text.to.speech
Security bugs are exploding in open source software. A ‘courageous’ vulnerability management service makes this bold claim in a recent research white paper.
Not only that, but many popular open source projects are doing a lousy job of notifying people about vulnerabilities, says said company. And they give an extreme example: A critical Postgres bug that got ignored for almost five years. Ouch.
Light your flaming pitchforks; the F(L)OSS community ain’t gonna take this one lying down. In today’s SB Blogwatch, we fire up the popcorn machine.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Linux sucks.
Duck and Cover
What’s the craic? Lance Whitney reports—“Open source software vulnerabilities create risk for organizations”:
The total number of CVEs … in OSS are on the rise, more than doubling … in 2019. [It] doesn’t seem to be an anomaly as the number of new CVEs has stayed at a high level … during the first three months of 2020.
…
OSS vulnerabilities often take a long time to get added to the US National Vulnerability Database (NVD), a valued resource for information on security flaws. … The long waits create a risk for organizations and users.
…
OSS products as … Jenkins … MySQL … HashiCorp’s Vagrant … Apache Tomcat, Magento, Kubernetes, Elasticsearch, and JBoss all had security flaws that were popular in real-world attacks. … OSS vulnerabilities can be a “blind spot” for many organizations who may not be aware of all the open source projects and dependencies found in the applications they use.
And Catalin Cimpanu adds—“Vulnerabilities in popular open source projects doubled”:
A study that analyzed the top 54 open source projects found that security vulnerabilities in these tools doubled in 2019. … It usually took on average around 54 days for bugs found in these 54 projects to be reported to the NVD, with PostgreSQL seeing reporting delays that [averaging] eight months.
…
The report didn’t include projects like Linux, WordPress, Drupal, and other super-popular free tools. [It] looked at other popular open source projects that aren’t as well known but broadly adopted by the tech and software community. This included tools like Jenkins, MongoDB, Elasticsearch, Chef, GitLab, Spark, [and] Puppet.
…
The delays in reporting resulted in situations where companies remained … open to attacks. It also allowed threat actors to create and deploy exploits – resulting in the “weaponization” of a security bug. …
Open source projects now part of roughly 99% of all commercial software projects.
Says who? RiskSense’s Jennifer Hom, John Dasher and Srinivas Mukkamala call it, “The Dark Reality of Open Source”:
NVD disclosure latency is dangerously long. … These very long lags were seen across all severities including vulnerabilities rated as ‘Critical’ and those that were weaponized. … The longest observed lag was 1,817 days for a critical PostgreSQL vulnerability. 119 CVEs had lags of more than 1 year.
…
[We] used a variety of factors to build the list of OSS projects to study, including popularity on GitHub, market value of companies based on specific open source projects [and] lists such as the BOSS index. … Data from 2015 through the first three months of 2020 was gathered and analyzed, which yielded a total of 2,694 CVEs.
…
Since open source is used and reused everywhere today, when vulnerabilities are found, they can have incredibly far-reaching consequences. … The now infamous Heartbleed bug demonstrated how a relatively simple vulnerability in the OpenSSL library, could reach around the globe. [And] the Equifax breach showed the severity, when a vulnerability in the open source Apache Struts framework led to one of the biggest data breaches in U.S. history. … Open source software is increasingly being targeted by cryptominers, ransomware, and leveraged in DDoS attacks.
Conversely, nagora smashes that headline right back at ’em:
The Dark Reality of Closed Source is that you have no idea how many bugs there are. And even if you did no one could do anything about them except the provider, who may be disinterested or long gone.
All software has bugs. That’s not what’s different about open source.
True, dat? Alain Williams vehemently agrees:
Quite. This report is meaningless without a comparison of similar closed source projects/products.
The other problem with this is that it just says “security vulnerabilities” without any attempt to dig deeper. Not all security problems are the same; how easy are they to exploit, what is the potential impact, etc.? A remote exploitable root shell bug needs to be fixed much more quickly than, say, a local exploit that just lets you see a list of file names.
Open? Closed? jqpabc123 wishes a plague on both their houses:
”Open source” is primarily a coding phenomenon. … Producing a viable, productive ecosystem requires much more than just open source code. It requires design, implementation, incentive and marketing.
If code was all that was needed, Linux distros should be dominate by now. Instead, after 30 years of effort by some of the best and brightest and billions of lines of code later and the result is – a big yawn from the … public.
And here come the Rust goons again. Morgaine manages to avoid using the R-word:
Open source projects are not all made in the same way. One crucial difference between them is in their respective languages of implementation, a detail which can be presumed to be highly relevant yet which does not seem to have been studied nor recognized in the report.
Some programming languages are safer than others by design, and in principle this should translate into application bugs being less easily exploitable than in applications written using less safe languages. This deserves to be studied and detailed in reports such as [this] to provide evidence for best practice recommendations.
So Oleg Balbekov asks, “How is open-source code different from regular everyday code?”:
When you make your source code available, you gain a lot of additional responsibilities. Your code is publicly accessible, meaning anyone can use it, and you, as the author, are responsible for the quality of the code … and responding to bug reports in a timely manner.
…
Therefore, your approach to writing open-source code that the whole world will see is often more complex and involved than your approach to writing code for a project just to make it work. [It] lives its own life, built by the community that forms around it. Ideas, feedback, bug reports, discussions, and gratitude from other members of the community directly affect you and the project.
Meanwhile, let’s at least read the report. This Anonymous Coward fell at the first hurdle:
I tried to obtain a copy from its download page … but their braindead webbies are rejecting Gmail addresses.
And Finally:
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.
Image sauce: Alexas Fotos (Pixabay)
Gloss