Bicol University Polangui Campus
Polangui, Albay
Computer Studies Department
Vulnerabilities from using
Open-Source Software
BSCS – 3B
Group members:
Tyrone Jay R. Tiñana
Sean Emerick Ferrer
King Louie S. Martinez
Ralph Rafael Terrible
Emmanuelle Navales
I. Introduction
Software selection is an important risk management consideration for information
security. Utilizing software packages with strong security features can reduce the information
security risk exposure of an organization. Additionally, the underlying quality and security of
a technology under consideration has become increasingly important in total cost of
ownership (TCO) and other calculations of business value. Open source software (OSS) has
been cited as a possible solution to the information security problems and vulnerabilities
often reported in propriety software. Open source software is software that by license
provides unlimited access to the source code, so that the source code can be examined and
modified according to the user’s wishes. There are also prescriptions for the distribution of
the software and subsequent modifications. According to a recent Wall Street Journal article,
supporters of open source software, particularly Linux, a pc-based operating system, viewed
such software as less vulnerable to viruses and worms, making OSS a favorable choice over
other operating systems, such as Windows XP. Open source software is often developed and
maintained by large numbers of volunteers. One of the oft promoted features of open source
software is that the wide availability of source code, and hence the large number of critical
eyes examining the source code, results in more robust and therefore more secure software
and application. Many critics also suggest the push to market pressures among proprietary
software vendors result in more problematic end products, including an increased number of
software bugs and vulnerabilities. In light of these commonly-held beliefs, there is a growing
perception that open source software, for example the various instantiations of the Linux
operating system and various software applications, is inherently more secure, due to the
freely available source code and greater levels of critical scrutiny. Information security
activities, in theory, are driven by risk management principles. Anti-virus software, firewalls,
access control, and intrusion detection systems are certainly important in managing the risk
exposure of the organization. Increasingly, organizations are looking to the information
technology infrastructure itself, to ensure that components are utilized that provide the most
functional and secure platform possible while minimizing the total cost of ownership. Given
the general low acquisition costs and perceived higher levels of security, OSS such as Linux,
Apache, and MySQL has received significant attention from the popular press. However, it
remains unclear whether or not the deployment of OSS results in greater levels of security
and therefore lower levels of risk to the organization. The question of reduced TCO remains
for future research.
Open source is not inherently safer. It might be a little bit, due to the following reasons:
1. Potentially more people look at the code, so bugs allowing for security vulnerabilities
are more easily spotted. (Also, it's not true that open source means attackers can just
slip in hacks, as some people might be led to think - code is still checked before
included in any project. Unless of course the project itself is malicious.)
2. An openly governed project creates an ethos of contributing back, e.g. when a security
flaw is found, this is reported (and subsequently fixed), rather than exploited).
3. The creators of an open source project often have no incentive to deny that
vulnerabilities exist until a fix is found -- the more people know about it, the more
likely it is someone will know how to fix this.
This will only marginally make it safer, though, since bugs will still exist and people will be
using their powers for Bad rather than Good.
When it comes to Ubuntu and all other Linux distributions, though, fact is that it has been
designed from the ground up from a multi-user perspective, with one user being able to make
modifications to the system and the rest only being allowed to change what's relevant to them
- in Windows this was rather tacked on later on (though probably works pretty well by now
(Windows 7)).
Still, one could easily write a virus that removes all of a user's personal files. The biggest
reason for there being no virus for Ubuntu, is simply that it has a really, really small market
share. Thus, there is little to gain and little incentive for a hacker to go through the extra
trouble of supporting Ubuntu when they could just target Windows and gain a lot. That, and
users of Linux are often more well-versed technically, so would be less likely to install
something of which they do not know what it does (though then again, the absence of viruses
may lead them to trust everything they download).
II. Context
Any bug or error in a user-application or a network application that can be exploited to
compromise a system, or cause a security breach, is termed a vulnerability. Vulnerabilities
can be classified according to the types of problems or breaches it can cause, or the potential
damage it may inflict. The problems or threats created by vulnerabilities are qualified based
on the nature of possible security attacks and the level of severity of the attacks. Typically,
developers working on software take preventive measures to counter these threats due to
known vulnerabilities by releasing what is known as a fix or a patch to eliminate the
vulnerability.
There are numerous issues with patching vulnerabilities. First of all, the vulnerability
must be discovered and reported. There are different mechanisms by which vulnerabilities
can be reported. For example, CERT ([Link] is a partnership between the
federal government and public and private companies, and acts as an infomediary between
those who identify vulnerabilities and software users. The ICAT Metabase is a database
maintained by the National Institute of Standards and Technology (NIST)
([Link] that stores 6and maintains vulnerability and patch information,
collected from various other security advisories maintained by the Center for Education and
Research in Information Assurance and Security (CERIAS), Security Focus, Bugtraq, etc.
There also exist market-based infomediaries such as iDefense ([Link]
providing incentives like monetary rewards for vulnerability identifiers. Arora, Telang and
Xu (2004) examine a number of scenarios to study optimal vulnerability disclosure policy
and find that the social welfare is maximized by the use of a neutral intermediary. However,
there is a contingent of users who believe in immediate and full disclosure
([Link] The chief concern is that if a
particular vulnerability is known, an attack can be executed before affected systems are
somehow patched or secured.
Next, a patch must be created, delivered or made accessible to all relevant users of the
affected systems. The current system of patch delivery depends on the particular source or
vendor of the technology. Some might be automatically located and applied via the Internet,
whereas others might require far more work and expertise to locate. Third, the patch must be
applied once it is obtained. While some patches and updates are simple to download and
install, others have been known to cause further problems and system instability, for example
Microsoft’s Service Pack 2 (SP2) (Sliwa, 2004). It has been conjectured that such patches
might introduce further vulnerabilities as they are sometimes quickly put together without
sufficient development and testing procedures.
The proliferation of patches in itself has resulted in a new area of practice and research,
namely patch management. Certainly, keeping up with the volume of patches for various
systems is no easy task for organizations. Intuitively, well-developed software that was
engineered for both functionality and security should result in fewer bugs, and therefore,
fewer vulnerabilities and subsequent patches. From a TCO perspective, patching is quite
expensive. Much effort is required to determine which patches should be downloaded and
applied at what times, to which systems and follow-up must be performed to ensure adequate
systems operations and stability (Silver and Pescatore, 2004). From a risk management
perspective, the application of large numbers of patches implies that further problems,
complexities and instability could be introduced to a system, therefore increasing the
likelihood of more problems or failure. Both TCO and risk management dictate that fewer
patches as a result of fewer vulnerabilities in software is desirous.
Open source software advocates claim that OSS is much less prone to attacks from
viruses and other information security problems as there are fewer vulnerabilities to exploit.
Others have proposed that the issue is more of simply being an interesting target to attack.
For example, as Microsoft is the dominant player in the personal computer operating system
market, (Hamm, 2005) they are the most interesting target for attackers and others with
malevolent agendas. As Linux makes further inroads into the PC operating system market
space, will the various instantiations of Linux become popular targets for virus writers and
other attackers as well? The next section sets forth several research questions, along with the
research framework in 8which we attempt to address the research questions.
III. Approach
Open source is neither more nor less secure than custom, proprietary code. However,
there are certain characteristics of open source that make vulnerabilities in popular open-
source components attractive to attackers: Open source is target-rich, traditional testing tools
are ineffective in identifying open source, and few companies understand the breadth of open
source being used in their applications (more on these points below).
This lack of knowledge translates into a lack of awareness about vulnerable
components, leaving organizations exposed to attack. Here are five steps you can take now to
manage open-source risks.
1. Inventory your open source
You can’t secure what you’re not tracking, so your first step needs to be an inventory
of all open-source components your teams use to develop software. A complete open-source
inventory must include all open-source components, the version(s) in use, and the download
locations for each project in use or in development. You’ll also need to include all
dependencies—the libraries your code is calling to and/or the libraries that your dependencies
are linked to—in your inventory.
2. Map your open source to known security vulnerabilities
Sources such as the National Vulnerability Database (NVD) can provide information
on publicly disclosed vulnerabilities in open-source software. But be aware that not all
vulnerabilities are reported to the NVD in a timely fashion and that the format of NVD
records often makes it difficult to determine which versions of a given open-source
component are affected by a vulnerability. You should not rely on the NVD as your
sole source of vulnerability information.
3. Identify other open-source risks you may face
Failure to comply with open-source licenses can put organizations at significant risk
of litigation and compromise of intellectual property. Similarly, the use of outdated or poor-
quality components can compromise the quality of applications that use them. Are you using
a current version of the open-source component? Is it the most stable? Is the component
actively maintained by a robust community?
4. Create and enforce open-source use policies
Many organizations lack even basic documentation of open-source policies that would
help them mitigate risks. You should have a single responsible entity—either a person
or a committee—overseeing open-source usage, documented policies, and developers'
awareness of their responsibilities when it comes to open-source use.
5. Continuously monitor for new open-source risks
With more than 3,600 new open-source vulnerabilities discovered every year, the job
of tracking vulnerabilities doesn’t end when applications leave development.
Organizations need to continuously monitor for new threats as long as their
applications remain in service.
According to the National Security Agency (NSA), the average SAST tool can only find 14
percent of the problems in any given application. Most open-source vulnerabilities are
reported by security researchers and not found by application development teams using
DAST and SAST application security tools.
With over 3,600 new open-source component vulnerabilities reported in 2016—almost 10 per
day on average and a 10 percent increase from 2015—the need for effective open-source
security and management is clear. However, Black Duck audits of client code consistently
reveal that many organizations are blind to the security and license compliance risk that their
use of open source may expose them to.
IV. Evaluation
In this section we illustrate how our approach works and to illustrate the benefits of our
approach. Security researchers, bug bounty programs, and product vendors are discovering
and reporting new vulnerabilities daily. These vulnerabilities are frequently caused by either
coding errors or by security misconfigurations. Coding errors, including the failure to check
user input, allow attackers to improperly access system memory, data, or to execute
commands (including buffer overflow and injection attacks). Of the vulnerabilities reported
in Q1 2017, 68.1% are due to insufficient or improper input validation, often allowing
attackers to steal company data. The failure to detect and mitigate vulnerabilities often makes
front page news: there have been 1,254 publicly reported data breaches in Q1 2017 alone.
WannaCry, a massive ransomware attack affecting organizations around the world, targeted
the EternalBlue vulnerability, first reported on April 14, 2017 before being used in the
WannaCry attack on May 12, 2017. EternalBlue exploited a vulnerability in the Windows
SMB protocol that allowed remote attackers to execute arbitrary code via crafted packets.
Although Microsoft released a patch for the vulnerability on March 14, 2017, many
organizations had not applied the patch in time and fell victim to WannaCry.
Organizations with strong vulnerability assessment programs were able to detect the
vulnerability involved in WannaCry – CVE-2017-0144 – and apply the necessary patch,
preventing disaster.
A vulnerability assessment informs organizations on the weaknesses present in their
environment and provides direction on how to reduce the risk those weaknesses cause. The
vulnerability assessment process helps to reduce the chances an attacker is able to breach an
organization’s IT systems – yielding a better understanding of assets, their vulnerabilities,
and the overall risk to an organization.
For organizations seeking to reduce their security risk, a vulnerability assessment is a good
place to start. It provides a thorough, inclusive assessment of hardware and software assets,
identifying vulnerabilities and providing an intuitive risk score. A regular assessment
program assists organizations with managing their risk in the face of an ever-evolving threat
environment, identifying and scoring vulnerabilities so that attackers do not catch
organizations unprepared.
V. Scope
Our study contributes to the literature on software security. The key motivation remains
to carry the software reliability model forward. Maintaining a comprehensive knowledge-
base of rich, detailed vulnerability data is critical to all vulnerability management approaches
and requires considerable effort. While this effort could be substantially reduced creating
specialized tools, we strongly believe that the maintenance of this knowledge-base should
become an industry-wide, coordinated effort, whose outcome would benefit the whole
software industry. We seek to further examine this data through an analytical framework
from the perspective of security as reliability. The insights available from the software
reliability literature will be applied accordingly. Another issue worth pursuing is that of
staffing questions for software development. Some critics state that open source software has
too many 26developers than is efficient, and thus wastes resources. Others purport that
perhaps open source software has naturally evolved to rely on the relatively large numbers of
programmers used to manage the software. We hope to eventually shed light on this issue as
well.
VI. References
• Vincent, May 1, 2012
[Link]
to-viruses
• Kemal Altinkemer,Purdue University; Jackie Rees Ulmer,Iowa State
University; Sanjay Sridhar
[Link]
k_Management_of_Open_Source_Software_An_Empirical_Study
• Mike Pittenger-Vice President, Security Strategy, Black Duck
[Link]
• Hitachi Systems Security on 4 July 2017
[Link]
assessment/