Most organizations are aware of cybercrime attempts such as phishing, installing malware from dodgy websites or ransomware attacks and undertake countermeasures. However, relatively little attention has been given to memory safety vulnerabilities such as buffer overflows or over-reads. For decades industry has created billions of lines of C & C++ code but addressing the resulting memory safety risks has been a tough challenge. This blog series will explore memory vulnerabilities, the causes of memory unsafety and potential preventative measures.
Data breaches are very costly
Memory vulnerabilities are often the means for an attacker to steal confidential information such as passwords, financial data or intellectual property. In their Cost of a Data Breach Report 2023, IBM estimates the global average cost of a data breach to be $4.45 million. Some vulnerabilities can cost considerably more, for example, the Heartbleed vulnerability in OpenSSL was estimated to have cost in excess of $500 million.
Some data breaches involve multi-stage attacks going from an entry point to servers deep inside a company’s network. For example, with Operation Soft Cell attackers were able to access web-facing servers of telecom companies using a code injection attack enabled by a buffer overflow. Account credentials were stolen and used to create high privilege user accounts. The attackers were able to take over the IT networks and establish VPNs as back doors. They stole call record information and potentially could have even shut down the phone networks.
Firmware and embedded systems are under attack too
Firmware has been an attractive target for attackers in recent years as a successful attack can access hardware downwards and the main OS upwards. National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD) showed a fivefold increase in cyberattacks on embedded systems between 2017 and the end of 2022. In 2021, Microsoft’s Security Signals report showed that 80 percent of enterprises had experienced firmware attacks in the previous two years. However, the same report indicated that few companies were investing in preventing firmware attacks.
Compromised firmware can be very costly in terms of critical infrastructure downtime, unsafe systems and loss of control.
It is not just corporate networks that are vulnerable to unsafe programming practice but also embedded systems. Twenty years ago, most embedded systems were isolated and could only be attacked by invasive methods or side-channel attacks. With many embedded devices connected due to IoT there is a much greater attack surface including over-the-air (OTA) firmware updates and attacks on communication protocols such as man-in-the-middle attacks. There are also risks from rogue devices being added to an IoT network for malicious purposes. Embedded systems control critical infrastructure, implement safety systems and are used widely in vehicles, medical devices and homes so their integrity is essential.
Memory vulnerabilities are increasingly common
Major software vendors consistently report memory safety problems. For example, Microsoft’s Security Response Center (MSRC) has stated that consistently ~70% of CVE (Common Vulnerabilities and Exposures) reported relate to memory safety.
As the chart above shows, the percentage of reports has remained consistent for over a decade. The Chromium project and Ubuntu project have reported 70% and 65% respectively which is very consistent with Microsoft’s figures.
However, what this chart does not show is that CVEs are becoming more and more common. Memory overflow CVEs more than doubled from 844 in 2013 to 1,881 in 2022. Memory corruption CVEs increased almost sixfold in the same period from 577 to 3,420.
Assembling software complicates the problem
Modern software development makes use of multiple sources of code. A top-level application might be created from scratch but in the interests of development efficiency it is normal that software libraries would be used. In some cases, it is also economical to license some code from a specialist supplier.
Much code has been written in C or C++ because the high degree of control over resources means that high performance can be achieved. Memory management is manual which means that great care must be taken to avoid memory safety problems. However, given that multiple sources of code are used it is challenging to check the safety of all sources used.
Checking multiple sources of code is hugely challenging and there may be other complications including:
- Old libraries
Some libraries may be well-used but if they are old, it is possible that the original developers are no longer available. They may have changed company or have even retired.
- Binaries
If a third-party licenses source code, it is possible to inspect it for good coding practice. However, if binaries are licensed it is impossible to assess the source code that was used to generate them.
- Open-source security risks
On the whole, open-source software such as Linux has been very successful. However, its very openness can potentially allow bad actors to deliberately introduce code vulnerabilities.
Now is the time to act
With the number of vulnerabilities increasing year by year and with a huge amount of legacy code at risk, if you have not considered the dangers of unsafe memory accesses then it now is good to consider the issue as a matter of urgency.
Attackers are always innovating. Closing loopholes in security is imperative just to keep abreast of attackers.
In the following post we will look at common approaches to protecting processor systems and their limitations. We will then look at some specific memory vulnerabilities and give an overview of how they happen. Finally, we will consider different approaches to improving memory safety using both software and hardware.
