Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

2/18/2020
06:40 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

The Trouble with Free and Open Source Software

Insecure developer accounts, legacy software, and nonstandard naming schemes are major problems, Linux Foundation and Harvard study concludes.

A wide-ranging study by researchers at the Linux Foundation and the Laboratory for Innovation Science at Harvard has yielded vital new information on the most widely used free and open source software (FOSS) within enterprises — and potential security risks related to that use.

The researchers found that a lack of a standardized naming scheme for FOSS components has made it hard for organizations and other stakeholders to quickly and precisely identify questionable or vulnerable components.

They also discovered that accounts belonging to developers contributing most actively to some of the most widely deployed open source software need to be secured much better. A third finding was that legacy packages within the open source space are becoming riskier by the day, just like any other older hardware or software technology.

"FOSS components underpin nearly all other software out there — both open and proprietary — but we know so little about which ones might be the most widely used and most vulnerable," says Frank Nagle, professor at Harvard Business School and co-author of the report. "Given the estimated economic impact of FOSS, far too little attention is paid to systematic efforts to support and maintain this core infrastructure," he says.

For the study, the researchers from the Linux Foundation and Harvard analyzed enterprise software usage data provided by, among others, software composition analysis firms and application security companies such as Snyk and the Synopsys Cybersecurity Research Center. In trying to identify the most widely used open source software, the researchers considered all of the dependencies that might exist between a FOSS package or component and other enterprise applications and systems.

The goal was to identify and measure how widely used FOSS is within enterprise environments and to understand the security and other implications of using the software. FOSS components constitute between 80% and 90% of almost any application in use currently within enterprises. While many FOSS projects have received considerable security scrutiny, many others have not.

Vulnerabilities in widely used projects with smaller contributor bases, like OpenSSL, can often slip by unnoticed, the researchers said in a report released this week. The heavy and growing reliance on FOSS has prompted efforts by governments, researchers, and organizations to better understand the provenance and security of open source software via audits, bug bounty programs, hackathons and conferences. "The first step is to truly understand the FOSS components upon which organizations depend — whether it be through regular security scans and code audits or by adopting a software bill of materials for all of its digital products," Nagle says.

Top Projects & Top Risks
The joint research by the Linux Foundation and the Laboratory for Innovation Science at Harvard showed that the 10 most-used FOSS packages within enterprises are async, inherits, isarray, kindof, lodash, minimist, natives, qs, readable-stream, and string-decoder. The researchers also identified the top most-used non-JavaScript packages, which include com.fasterxml.jackson.core:jackson-core, com.fasterxml.jackson.core:Jackson-databind, com.google.guava:guava, and commons-codec.

After identifying the top projects, the researchers set about trying to find out whom the most active contributors to these projects were and identified company affiliations for about 75% of them. During the study, the researchers found that seven of the top most-used open source software projects were hosted on individual developer accounts with fewer protections than organizational accounts. "Changes to code under the control of these individual developer accounts are significantly easier to make, and to make without detection," the report warned.

According to the researchers, attacks on individual developer accounts are increasing, and there's a growing risk of account takeovers and of backdoors and other malicious code being installed on them that can later be used to access the code. "One option is for such individual accounts to implement two-factor authentication if their repository supports it," Nagle says.

Another risk in having widely used FOSS sitting on individual accounts is developers who might decide to delete their accounts or remove code over disputes and disagreements. "A broader and longer-term solution would be for such projects to move to organizational accounts, rather than individual accounts, to help enhance the accountability and future availability of the projects," Nagle notes.

The research showed the need for better naming conventions for FOSS components. Because FOSS can be freely modified and copied, it can exist in multiple versions, forks, and similarly named repositories, Nagle says. To ensure better security, it is important to have a common understanding of which instance of a FOSS component is being used and how well it is being supported and maintained.

Another discovery the researchers made was that older, legacy open source components present the same risks as older, non-supported versions of any software or hardware. As one example, Nagle pointed to version 0.70 of the frequently used PuTTY SSH software, which was released in July 2017. No updates for the software were released until version 0.71 was released nearly two years later, in March 2019. "The infrequency of updates and examination [of] such highly used software can lead to security issues existing in the code base for more than 20 years," he says.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "8 Things Users Do That Make Security Pros Miserable."

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...