Yesterday the NSA released released guidelines on how organizations can implement protections against software memory safety issues Here’s an snippet from the press release on the topic:
The “Software Memory Safety” Cybersecurity Information Sheet highlights how malicious cyber actors can exploit poor memory management issues to access sensitive information, promulgate unauthorized code execution, and cause other negative impacts.
“Memory management issues have been exploited for decades and are still entirely too common today,” said Neal Ziring, Cybersecurity Technical Director. “We have to consistently use memory safe languages and other protections when developing software to eliminate these weaknesses from malicious cyber actors.”
Microsoft and Google have each stated that software memory safety issues are behind around 70 percent of their vulnerabilities. Poor memory management can lead to technical issues as well, such as incorrect program results, degradation of the program’s performance over time, and program crashes.
I got commentary from Yotam Perkal, Director, Vulnerability Research at Rezilion on this guidance:
Regarding the NSA guidelines, it is true that the majority of exploitable vulnerabilities in languages such as C and C++, are due to memory issues. That said, these languages are still extremely widely used especially in applications that are performance oriented. In the latest StackOverflow developer survey, close to 40% of developers claimed to be using either C or C++ in their daily work, even in open source projects over 15% of the code is still written in these languages (see here). Hence, I don’t see them disappearing any time soon.
It is also important to note that even with a memory safe language, memory management is not entirely memory safe as most of these languages allow the developers the flexibility to perform potentially unsafe memory management tasks. Moreover, for an existing project, migration of code from one language to another isn’t a trivial task and requires skilled workforce in both the source and target language. So all in all I think while the recommendation is valid, I don’t believe it will be widely adopted.
Organizations that do have applications written in memory unsafe languages, should definitely take efforts to make sure they perform proper testing (SAST and DAST) as part of the development cycle in order to identify potential memory issues before code makes its way to production. They should also make sure to enable various binary hardening mechanisms such as ASLR, CFG, NX bit and others while compiling code written in memory unsafe languages.These mechanisms make potential exploitation far more complex. There are open-source tools that enable evaluation of binary hardening status for existing binaries such as checksec.sh.
For open-source projects, there is a possibility to check eligibility to enroll to Google’s OSS-Fuzz project which aims to make common open source software more secure and stable by performing automated fuzzing.
I would recommend that software developers read this guidance and take Mr. Perkal’s advice to make sure that their applications are less exploitable. Because these are dangerous times that we live in, and anything that one can do to minimize the risk of an application that can be exploited is a good thing.
Like this:
Like Loading...
Related
This entry was posted on November 15, 2022 at 11:27 am and is filed under Commentary with tags NSA. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
NSA Releases Guidelines On Mitigating Software Memory Safety Issues
Yesterday the NSA released released guidelines on how organizations can implement protections against software memory safety issues Here’s an snippet from the press release on the topic:
The “Software Memory Safety” Cybersecurity Information Sheet highlights how malicious cyber actors can exploit poor memory management issues to access sensitive information, promulgate unauthorized code execution, and cause other negative impacts.
“Memory management issues have been exploited for decades and are still entirely too common today,” said Neal Ziring, Cybersecurity Technical Director. “We have to consistently use memory safe languages and other protections when developing software to eliminate these weaknesses from malicious cyber actors.”
Microsoft and Google have each stated that software memory safety issues are behind around 70 percent of their vulnerabilities. Poor memory management can lead to technical issues as well, such as incorrect program results, degradation of the program’s performance over time, and program crashes.
I got commentary from Yotam Perkal, Director, Vulnerability Research at Rezilion on this guidance:
Regarding the NSA guidelines, it is true that the majority of exploitable vulnerabilities in languages such as C and C++, are due to memory issues. That said, these languages are still extremely widely used especially in applications that are performance oriented. In the latest StackOverflow developer survey, close to 40% of developers claimed to be using either C or C++ in their daily work, even in open source projects over 15% of the code is still written in these languages (see here). Hence, I don’t see them disappearing any time soon.
It is also important to note that even with a memory safe language, memory management is not entirely memory safe as most of these languages allow the developers the flexibility to perform potentially unsafe memory management tasks. Moreover, for an existing project, migration of code from one language to another isn’t a trivial task and requires skilled workforce in both the source and target language. So all in all I think while the recommendation is valid, I don’t believe it will be widely adopted.
Organizations that do have applications written in memory unsafe languages, should definitely take efforts to make sure they perform proper testing (SAST and DAST) as part of the development cycle in order to identify potential memory issues before code makes its way to production. They should also make sure to enable various binary hardening mechanisms such as ASLR, CFG, NX bit and others while compiling code written in memory unsafe languages.These mechanisms make potential exploitation far more complex. There are open-source tools that enable evaluation of binary hardening status for existing binaries such as checksec.sh.
For open-source projects, there is a possibility to check eligibility to enroll to Google’s OSS-Fuzz project which aims to make common open source software more secure and stable by performing automated fuzzing.
I would recommend that software developers read this guidance and take Mr. Perkal’s advice to make sure that their applications are less exploitable. Because these are dangerous times that we live in, and anything that one can do to minimize the risk of an application that can be exploited is a good thing.
Share this:
Like this:
Related
This entry was posted on November 15, 2022 at 11:27 am and is filed under Commentary with tags NSA. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.