Vulnerability (computer security)

Last updated

Vulnerabilities are flaws in a computer system that weaken the overall security of the system.

Contents

Despite intentions to achieve complete correctness, virtually all hardware and software contains bugs where the system does not behave as expected. If the bug could enable an attacker to compromise the confidentiality, integrity, or availability of system resources, it is called a vulnerability. Insecure software development practices as well as design factors such as complexity can increase the burden of vulnerabilities. There are different types most common in different components such as hardware, operating systems, and applications.

Vulnerability management is a process that includes identifying systems and prioritizing which are most important, scanning for vulnerabilities, and taking action to secure the system. Vulnerability management typically is a combination of remediation (fixing the vulnerability), mitigation (increasing the difficulty or reducing the danger of exploits), and accepting risks that are not economical or practical to eliminate. Vulnerabilities can be scored for risk according to the Common Vulnerability Scoring System or other systems, and added to vulnerability databases. As of November 2024, there are more than 240,000 vulnerabilities [1] catalogued in the Common Vulnerabilities and Exposures (CVE) database.


A vulnerability is initiated when it is introduced into hardware or software. It becomes active and exploitable when the software or hardware containing the vulnerability is running. The vulnerability may be discovered by the vendor or a third party. Disclosing the vulnerability (as a patch or otherwise) is associated with an increased risk of compromise because attackers often move faster than patches are rolled out. Regardless of whether a patch is ever released to remediate the vulnerability, its lifecycle will eventually end when the system, or older versions of it, fall out of use.

Causes

Despite developers' goal of delivering a product that works entirely as intended, virtually all software and hardware contains bugs. [2] If a bug creates a security risk, it is called a vulnerability. [3] [4] [5] Software patches are often released to fix identified vulnerabilities, but those that remain unknown (zero days) as well as those that have not been patched are still liable for exploitation. [6] Vulnerabilities vary in their ability to be exploited by malicious actors, [3] and the actual risk is dependent on the nature of the vulnerability as well as the value of the surrounding system. [7] Although some vulnerabilities can only be used for denial of service attacks, more dangerous ones allow the attacker to inject and run their own code (called malware), without the user being aware of it. [3] Only a minority of vulnerabilities allow for privilege escalation, which is necessary for more severe attacks. [8] Without a vulnerability, the exploit cannot gain access. [9] It is also possible for malware to be installed directly, without an exploit, if the attacker uses social engineering or implants the malware in legitimate software that is downloaded deliberately. [10]

Design factors

Fundamental design factors that can increase the burden of vulnerabilities include:

Development factors

Some software development practices can affect the risk of vulnerabilities being introduced to a code base. Lack of knowledge about secure software development or excessive pressure to deliver features quickly can lead to avoidable vulnerabilities to enter production code, especially if security is not prioritized by the company culture. This can lead to unintended vulnerabilities. The more complex the system is, the easier it is for vulnerabilities to go undetected. Some vulnerabilities are deliberately planted, which could be for any reason from a disgruntled employee selling access to hackers, to sophisticated state-sponsored schemes to introduce vulnerabilities to software. [15] Inadequate code reviews can lead to missed bugs, but there are also static code analysis tools that can be used as part of code reviews and may find some vulnerabilities. [16]

DevOps, a development workflow that emphasizes automated testing and deployment to speed up the deployment of new features, often requires that many developers be granted access to change configurations, which can lead to deliberate or inadvertent inclusion of vulnerabilities. [17] Compartmentalizing dependencies, which is often part of DevOps workflows, can reduce the attack surface by paring down dependencies to only what is necessary. [18] If software as a service is used, rather than the organization's own hardware and software, the organization is dependent on the cloud services provider to prevent vulnerabilities. [19]

National Vulnerability Database classification

The National Vulnerability Database classifies vulnerabilities into eight root causes that may be overlapping, including: [20]

  1. Input validation (including buffer overflow and boundary condition) vulnerabilities occur when input checking is not sufficient to prevent the attacker from injecting malicious code. [21]
  2. Access control vulnerabilities enable an attacker to access a system that is supposed to be restricted to them, or engage in privilege escalation. [21]
  3. When the system fails to handle and exceptional or unanticipated condition correctly, an attacker can exploit the situation to gain access. [22]
  4. A configuration vulnerability comes into existence when configuration settings cause risks to the system security, leading to such faults as unpatched software or file system permissions that do not sufficiently restrict access. [22]
  5. A race condition—when timing or other external factors change the outcome and lead to inconsistent or unpredictable results—can cause a vulnerability. [22]

Vulnerabilities by component

Hardware

Deliberate security bugs can be introduced during or after manufacturing and cause the integrated circuit not to behave as expected under certain specific circumstances. Testing for security bugs in hardware is quite difficult due to limited time and the complexity of twenty-first century chips, [23] while the globalization of design and manufacturing has increased the opportunity for these bugs to be introduced by malicious actors. [24]

Operating system

Although operating system vulnerabilities vary depending on the operating system in use, a common problem is privilege escalation bugs that enable the attacker to gain more access than they should be allowed. Open-source operating systems such as Linux and Android have a freely accessible source code and allow anyone to contribute, which could enable the introduction of vulnerabilities. However, the same vulnerabilities also occur in proprietary operating systems such as Microsoft Windows and Apple operating systems. [25] All reputable vendors of operating systems provide patches regularly. [26]

Client–server applications

Client–server applications are downloaded onto the end user's computers and are typically updated less frequently than web applications. Unlike web applications, they interact directly with a user's operating system. Common vulnerabilities in these applications include: [27]

Web applications

Web applications run on many websites. Because they are inherently less secure than other applications, they are a leading source of data breaches and other security incidents. [28] [29] They can include:


Attacks used against vulnerabilities in web applications include:

Management

There is little evidence about the effectiveness and cost-effectiveness of different cyberattack prevention measures. [32] Although estimating the risk of an attack is not straightforward, the mean time to breach and expected cost can be considered to determine the priority for remediating or mitigating an identified vulnerability and whether it is cost effective to do so. [33] Although attention to security can reduce the risk of attack, achieving perfect security for a complex system is impossible, and many security measures have unacceptable cost or usability downsides. [34] For example, reducing the complexity and functionality of the system is effective at reducing the attack surface. [35]

Successful vulnerability management usually involves a combination of remediation (closing a vulnerability), mitigation (increasing the difficulty, and reducing the consequences, of exploits), and accepting some residual risk. Often a defense in depth strategy is used for multiple barriers to attack. [36] Some organizations scan for only the highest-risk vulnerabilities as this enables prioritization in the context of lacking the resources to fix every vulnerability. [37] Increasing expenses is likely to have diminishing returns. [33]

Remediation

Remediation fixes vulnerabilities, for example by downloading a software patch. [38] Software vulnerability scanners are typically unable to detect zero-day vulnerabilities, but are more effective at finding known vulnerabilities based on a database. These systems can find some known vulnerabilities and advise fixes, such as a patch. [39] [40] However, they have limitations including false positives. [38]

Vulnerabilities can only be exploited when they are active-the software in which they are embedded is actively running on the system. [41] Before the code containing the vulnerability is configured to run on the system, it is considered a carrier. [42] Dormant vulnerabilities can run, but are not currently running. Software containing dormant and carrier vulnerabilities can sometimes be uninstalled or disabled, removing the risk. [43] Active vulnerabilities, if distinguished from the other types, can be prioritized for patching. [41]

Mitigation

Vulnerability mitigation is measures that do not close the vulnerability, but make it more difficult to exploit or reduce the consequences of an attack. [44] Reducing the attack surface, particularly for parts of the system with root (administrator) access, and closing off opportunities for exploits to engage in privilege exploitation is a common strategy for reducing the harm that a cyberattack can cause. [38] If a patch for third-party software is unavailable, it may be possible to temporarily disable the software. [45]

Testing

A penetration test attempts to enter the system via an exploit to see if the system is insecure. [46] If a penetration test fails, it does not necessarily mean that the system is secure. [47] Some penetration tests can be conducted with automated software that tests against existing exploits for known vulnerabilities. [48] Other penetration tests are conducted by trained hackers. Many companies prefer to contract out this work as it simulates an outsider attack. [47]

Vulnerability lifecycle

Vulnerability timeline Vulnerability timeline.png
Vulnerability timeline

The vulnerability lifecycle begins when vulnerabilities are introduced into hardware or software. [49] Detection of vulnerabilities can be by the software vendor, or by a third party. In the latter case, it is considered most ethical to immediately disclose the vulnerability to the vendor so it can be fixed. [50] Government or intelligence agencies buy vulnerabilities that have not been publicly disclosed and may use them in an attack, stockpile them, or notify the vendor. [51] As of 2013, the Five Eyes (United States, United Kingdom, Canada, Australia, and New Zealand) captured the plurality of the market and other significant purchasers included Russia, India, Brazil, Malaysia, Singapore, North Korea, and Iran. [52] Organized criminal groups also buy vulnerabilities, although they typically prefer exploit kits. [53]

Even vulnerabilities that are publicly known or patched are often exploitable for an extended period. [54] [55] Security patches can take months to develop, [56] or may never be developed. [55] A patch can have negative effects on the functionality of software [55] and users may need to test the patch to confirm functionality and compatibility. [57] Larger organizations may fail to identify and patch all dependencies, while smaller enterprises and personal users may not install patches. [55] Research suggests that risk of cyberattack increases if the vulnerability is made publicly known or a patch is released. [58] Cybercriminals can reverse engineer the patch to find the underlying vulnerability and develop exploits, [59] often faster than users install the patch. [58]

Vulnerabilities become deprecated when the software or vulnerable versions fall out of use. [50] This can take an extended period of time; in particular, industrial software may not be feasible to replace even if the manufacturer stops supporting it. [60]

Assessment, disclosure, and inventory

Assessment

A commonly used scale for assessing the severity of vulnerabilities is the open-source specification Common Vulnerability Scoring System (CVSS). CVSS evaluates the possibility to exploit the vulnerability and compromise data confidentiality, availability, and integrity. It also considers how the vulnerability could be used and how complex an exploit would need to be. The amount of access needed for exploitation and whether it could take place without user interaction are also factored in to the overall score. [61] [62]

Disclosure

Someone who discovers a vulnerability may disclose it immediately (full disclosure) or wait until a patch has been developed (responsible disclosure, or coordinated disclosure). The former approach is praised for its transparency, but the drawback is that the risk of attack is likely to be increased after disclosure with no patch available. [63] Some vendors pay bug bounties to those who report vulnerabilities to them. [64] [65] Not all companies respond positively to disclosures, as they can cause legal liability and operational overhead. [66] There is no law requiring disclosure of vulnerabilities. [67] If a vulnerability is discovered by a third party that does not disclose to the vendor or the public, it is called a zero-day vulnerability, often considered the most dangerous type because fewer defenses exist. [68]

Vulnerability inventory

The most commonly used vulnerability dataset is Common Vulnerabilities and Exposures (CVE), maintained by Mitre Corporation. [69] As of November 2024, it has over 240,000 entries [70] This information is shared into other databases, including the United States' National Vulnerability Database, [69] where each vulnerability is given a risk score using Common Vulnerability Scoring System (CVSS), Common Platform Enumeration (CPE) scheme, and Common Weakness Enumeration.[ citation needed ] CVE and other databases typically do not track vulnerabilities in software as a service products. [39] Submitting a CVE is voluntary for companies that discovered a vulnerability. [67]

Liability

The software vendor is usually not legally liable for the cost if a vulnerability is used in an attack, which creates an incentive to make cheaper but less secure software. [71] Some companies are covered by laws, such as PCI, HIPAA, and Sarbanes-Oxley, that place legal requirements on vulnerability management. [72]

Related Research Articles

<span class="mw-page-title-main">Software</span> Instructions a computer can execute

Software consists of computer programs that instruct the execution of a computer. Software also includes design documents and specifications.

An exploit is a method or piece of code that takes advantage of vulnerabilities in software, applications, networks, operating systems, or hardware, typically for malicious purposes. The term "exploit" derives from the English verb "to exploit," meaning "to use something to one’s own advantage." Exploits are designed to identify flaws, bypass security measures, gain unauthorized access to systems, take control of systems, install malware, or steal sensitive data. While an exploit by itself may not be a malware, it serves as a vehicle for delivering malicious software by breaching security controls.

Malware is any software intentionally designed to cause disruption to a computer, server, client, or computer network, leak private information, gain unauthorized access to information or systems, deprive access to information, or which unknowingly interferes with the user's computer security and privacy. Researchers tend to classify malware into one or more sub-types.

The Windows Metafile vulnerability—also called the Metafile Image Code Execution and abbreviated MICE—is a security vulnerability in the way some versions of the Microsoft Windows operating system handled images in the Windows Metafile format. It permits arbitrary code to be executed on affected computers without the permission of their users. It was discovered on December 27, 2005, and the first reports of affected computers were announced within 24 hours. Microsoft released a high-priority update to eliminate this vulnerability via Windows Update on January 5, 2006. Attacks using this vulnerability are known as WMF exploits.

A data breach, also known as data leakage, is "the unauthorized exposure, disclosure, or loss of personal information".

A zero-day is a vulnerability in software or hardware that is typically unknown to the vendor and for which no patch or other fix is available. The vendor has zero days to prepare a patch as the vulnerability has already been described or exploited.

The Pwnie Awards recognize both excellence and incompetence in the field of information security. Winners are selected by a committee of security industry professionals from nominations collected from the information security community. Nominees are announced yearly at Summercon, and the awards themselves are presented at the Black Hat Security Conference.

A cyberattack occurs when there is an unauthorized action against computer infrastructure that compromises the confidentiality, integrity, or availability of its content.

<span class="mw-page-title-main">Intel Management Engine</span> Autonomous computer subsystem

The Intel Management Engine (ME), also known as the Intel Manageability Engine, is an autonomous subsystem that has been incorporated in virtually all of Intel's processor chipsets since 2008. It is located in the Platform Controller Hub of modern Intel motherboards.

<span class="mw-page-title-main">Shellshock (software bug)</span> Security bug in the Unix Bash shell discovered in 2014

Shellshock, also known as Bashdoor, is a family of security bugs in the Unix Bash shell, the first of which was disclosed on 24 September 2014. Shellshock could enable an attacker to cause Bash to execute arbitrary commands and gain unauthorized access to many Internet-facing services, such as web servers, that use Bash to process requests.

Intel Software Guard Extensions (SGX) is a set of instruction codes implementing trusted execution environment that are built into some Intel central processing units (CPUs). They allow user-level and operating system code to define protected private regions of memory, called enclaves. SGX is designed to be useful for implementing secure remote computation, secure web browsing, and digital rights management (DRM). Other applications include concealment of proprietary algorithms and of encryption keys.

<span class="mw-page-title-main">Stagefright (bug)</span> Software bug in Android

Stagefright is the name given to a group of software bugs that affect versions from 2.2 "Froyo" up until 5.1.1 "Lollipop" of the Android operating system exposing an estimated 950 million devices at the time. The name is taken from the affected library, which among other things, is used to unpack MMS messages. Exploitation of the bug allows an attacker to perform arbitrary operations on the victim's device through remote code execution and privilege escalation. Security researchers demonstrate the bugs with a proof of concept that sends specially crafted MMS messages to the victim device and in most cases requires no end-user actions upon message reception to succeed—the user doesn't have to do anything to 'accept' exploits using the bug; it happens in the background. A phone number is the only information needed to carry out the attack.

<span class="mw-page-title-main">Dirty COW</span> Computer security vulnerability

Dirty COW is a computer security vulnerability of the Linux kernel that affected all Linux-based operating systems, including Android devices, that used older versions of the Linux kernel created before 2018. It is a local privilege escalation bug that exploits a race condition in the implementation of the copy-on-write mechanism in the kernel's memory-management subsystem. Computers and devices that still use the older kernels remain vulnerable.

EternalBlue is a computer exploit software developed by the U.S. National Security Agency (NSA). It is based on a vulnerability in Microsoft Windows that allowed users to gain access to any number of computers connected to a network. The NSA knew about this vulnerability but did not disclose it to Microsoft for several years, since they planned to use it as a defense mechanism against cyber attacks. In 2017, the NSA discovered that the software was stolen by a group of hackers known as the Shadow Brokers. Microsoft was informed of this and released security updates in March 2017 patching the vulnerability. While this was happening, the hacker group attempted to auction off the software, but did not succeed in finding a buyer. EternalBlue was then publicly released on April 14, 2017.

<span class="mw-page-title-main">Meltdown (security vulnerability)</span> Microprocessor security vulnerability

Meltdown is one of the two original transient execution CPU vulnerabilities. Meltdown affects Intel x86 microprocessors, IBM Power microprocessors, and some ARM-based microprocessors. It allows a rogue process to read all memory, even when it is not authorized to do so.

<span class="mw-page-title-main">Spectre (security vulnerability)</span> Processor security vulnerability

Spectre is one of the two original transient execution CPU vulnerabilities, which involve microarchitectural side-channel attacks. These affect modern microprocessors that perform branch prediction and other forms of speculation. On most processors, the speculative execution resulting from a branch misprediction may leave observable side effects that may reveal private data to attackers. For example, if the pattern of memory accesses performed by such speculative execution depends on private data, the resulting state of the data cache constitutes a side channel through which an attacker may be able to extract information about the private data using a timing attack.

Speculative Store Bypass (SSB) is the name given to a hardware security vulnerability and its exploitation that takes advantage of speculative execution in a similar way to the Meltdown and Spectre security vulnerabilities. It affects the ARM, AMD and Intel families of processors. It was discovered by researchers at Microsoft Security Response Center and Google Project Zero (GPZ). After being leaked on 3 May 2018 as part of a group of eight additional Spectre-class flaws provisionally named Spectre-NG, it was first disclosed to the public as "Variant 4" on 21 May 2018, alongside a related speculative execution vulnerability designated "Variant 3a".

Lazy FPU state leak, also referred to as Lazy FP State Restore or LazyFP, is a security vulnerability affecting Intel Core CPUs. The vulnerability is caused by a combination of flaws in the speculative execution technology present within the affected CPUs and how certain operating systems handle context switching on the floating point unit (FPU). By exploiting this vulnerability, a local process can leak the content of the FPU registers that belong to another process. This vulnerability is related to the Spectre and Meltdown vulnerabilities that were publicly disclosed in January 2018.

Transient execution CPU vulnerabilities are vulnerabilities in a computer system in which a speculative execution optimization implemented in a microprocessor is exploited to leak secret data to an unauthorized party. The archetype is Spectre, and transient execution attacks like Spectre belong to the cache-attack category, one of several categories of side-channel attacks. Since January 2018 many different cache-attack vulnerabilities have been identified.

Log4Shell (CVE-2021-44228) is a zero-day vulnerability reported in November 2021 in Log4j, a popular Java logging framework, involving arbitrary code execution. The vulnerability had existed unnoticed since 2013 and was privately disclosed to the Apache Software Foundation, of which Log4j is a project, by Chen Zhaojun of Alibaba Cloud's security team on 24 November 2021. Before an official CVE identifier was made available on 10 December 2021, the vulnerability circulated with the name "Log4Shell", given by Free Wortley of the LunaSec team, which was initially used to track the issue online. Apache gave Log4Shell a CVSS severity rating of 10, the highest available score. The exploit was simple to execute and is estimated to have had the potential to affect hundreds of millions of devices.

References

  1. ↑ "CVE - Program Metrics". 15 November 2024.{{cite web}}: CS1 maint: url-status (link)
  2. ↑ Ablon & Bogart 2017, p. 1.
  3. 1 2 3 Ablon & Bogart 2017, p. 2.
  4. ↑ Daswani & Elbayadi 2021, p. 25.
  5. ↑ Seaman 2020, pp. 47–48.
  6. ↑ Daswani & Elbayadi 2021, pp. 26–27.
  7. ↑ Haber & Hibbert 2018, pp. 5–6.
  8. ↑ Haber & Hibbert 2018, p. 6.
  9. ↑ Haber & Hibbert 2018, p. 10.
  10. ↑ Haber & Hibbert 2018, pp. 13–14.
  11. ↑ Kakareka, Almantas (2009). "23". In Vacca, John (ed.). Computer and Information Security Handbook. Morgan Kaufmann Publications. Elsevier Inc. p. 393. ISBN   978-0-12-374354-1.
  12. ↑ Krsul, Ivan (April 15, 1997). Technical Report CSD-TR-97-026. The COAST Laboratory Department of Computer Sciences, Purdue University. CiteSeerX   10.1.1.26.5435 .
  13. ↑ Linkov & Kott 2019, p. 2.
  14. ↑ Haber & Hibbert 2018, p. 155.
  15. ↑ Strout 2023, p. 17.
  16. ↑ Haber & Hibbert 2018, p. 143.
  17. ↑ Haber & Hibbert 2018, p. 141.
  18. ↑ Haber & Hibbert 2018, p. 142.
  19. ↑ Haber & Hibbert 2018, pp. 135–137.
  20. ↑ Garg & Baliyan 2023, pp. 17–18.
  21. 1 2 Garg & Baliyan 2023, p. 17.
  22. 1 2 3 Garg & Baliyan 2023, p. 18.
  23. ↑ Salmani 2018, p. 1.
  24. ↑ Salmani 2018, p. 11.
  25. ↑ Garg & Baliyan 2023, pp. 20–25.
  26. ↑ Sharp 2024, p. 271.
  27. 1 2 3 Strout 2023, p. 15.
  28. 1 2 3 4 Strout 2023, p. 13.
  29. ↑ Haber & Hibbert 2018, p. 129.
  30. 1 2 3 4 5 Strout 2023, p. 14.
  31. ↑ Strout 2023, pp. 14–15.
  32. ↑ Agrafiotis et al. 2018, p. 2.
  33. 1 2 Haber & Hibbert 2018, pp. 97–98.
  34. ↑ Tjoa et al. 2024, p. 63.
  35. ↑ Tjoa et al. 2024, pp. 68, 70.
  36. ↑ Magnusson 2020, p. 34.
  37. ↑ Haber & Hibbert 2018, pp. 166–167.
  38. 1 2 3 Haber & Hibbert 2018, p. 11.
  39. 1 2 Strout 2023, p. 8.
  40. ↑ Haber & Hibbert 2018, pp. 12–13.
  41. 1 2 Haber & Hibbert 2018, p. 84.
  42. ↑ Haber & Hibbert 2018, p. 85.
  43. ↑ Haber & Hibbert 2018, pp. 84–85.
  44. ↑ Magnusson 2020, p. 32.
  45. ↑ Magnusson 2020, p. 33.
  46. ↑ Haber & Hibbert 2018, p. 93.
  47. 1 2 Haber & Hibbert 2018, p. 96.
  48. ↑ Haber & Hibbert 2018, p. 94.
  49. ↑ Strout 2023, p. 16.
  50. 1 2 Strout 2023, p. 18.
  51. ↑ Libicki, Ablon & Webb 2015, p. 44.
  52. ↑ Perlroth 2021, p. 145.
  53. ↑ Libicki, Ablon & Webb 2015, pp. 44, 46.
  54. ↑ Ablon & Bogart 2017, p. 8.
  55. 1 2 3 4 Sood & Enbody 2014, p. 42.
  56. ↑ Strout 2023, p. 26.
  57. ↑ Libicki, Ablon & Webb 2015, p. 50.
  58. 1 2 Libicki, Ablon & Webb 2015, pp. 49–50.
  59. ↑ Strout 2023, p. 28.
  60. ↑ Strout 2023, p. 19.
  61. ↑ Strout 2023, pp. 5–6.
  62. ↑ Haber & Hibbert 2018, pp. 73–74.
  63. ↑ "Ask an Ethicist: Vulnerability Disclosure". Association for Computing Machinery's Committee on Professional Ethics. 17 July 2018. Retrieved 3 May 2024.
  64. ↑ O'Harrow 2013, p. 18.
  65. ↑ Libicki, Ablon & Webb 2015, p. 45.
  66. ↑ Strout 2023, p. 36.
  67. 1 2 Haber & Hibbert 2018, p. 110.
  68. ↑ Strout 2023, p. 22.
  69. 1 2 Strout 2023, p. 6.
  70. ↑ "CVE - Program Metrics". 15 November 2024.{{cite web}}: CS1 maint: url-status (link)
  71. ↑ Sloan & Warner 2019, pp. 104–105.
  72. ↑ Haber & Hibbert 2018, p. 111.

Sources

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.