The Capability Hardware Enhanced RISC Instructions ( CHERI) research project uses modified processors to give memory unsafe languages like C and C++ protection against many widely exploited vulnerabilities. First, there are some promising memory safety mitigations in hardware. There are, however, a few areas that every software company should investigate. Despite these efforts (and associated costs in complexity, time, and money), memory unsafety has been the most common type of software security defect for decades. There are also several parallel efforts to improve the memory safety of existing C/C++ code. In addition to those tools, organizations have spent significant time and money training their developers to avoid unsafe memory operations. Over the years, software engineers have invented numerous clever, but ultimately insufficient mitigations for this class of vulnerability, including tools like memory randomization and sandboxing techniques that reduce impact, and tools for static and dynamic code analysis that reduce occurrence. In what other industry would the market tolerate such well-understood and severe dangers for users of products for decades? They report that “out of the 58 for the year, 39, or 67% were memory corruption vulnerabilities.” Citizen Lab uncovered spyware used against civil society organizations that exploited memory safety vulnerabilities. For example, Google’s Project Zero team analyzed vulnerabilities that were used in the wild by attackers before they were reported to software providers (also called “zero-day vulnerabilities”). Attackers use them in the commission of attacks against real people. These vulnerabilities are not theoretical. Just how big a problem is memory unsafety? In a blog post, Microsoft reported that “~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues.” Google likewise reported that “the Chromium project finds that around 70% of our serious security bugs are memory safety problems.” Mozilla reports that in an analysis of security vulnerabilities, that “of the 34 critical/high bugs, 32 were memory-related.” Memory unsafe code even led to a major internet outage in 1988. During that time, experts have repeatedly warned of the problems associated with memory safety vulnerabilities. The guide strongly encourages executives of software manufacturers to prioritize using memory safe programing languages, write and publish memory safe roadmaps and implement changes to eliminate this class of vulnerability and protect their customers.įor over half a century, software engineers have known malicious actors could exploit a class of software defect called “memory safety vulnerabilities” to compromise applications and systems. ![]() and international cyber agencies published, “The Case for Memory Safe Roadmaps: Why both C-Suite Executives and Technical Experts Need to Take Memory Safe Coding Seriously”, as part of our collective Secure by Design campaign to address the critical issue of memory safety vulnerabilities in programming languages.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |