Feds want devs to stop coding 'unforgivable' buffer overflow vulnerabilities
- Reference: 1739410187
- News link: https://www.theregister.co.uk/2025/02/13/fbi_cisa_unforgivable_buffer_overflow/
- Source link:
Buffer overflow vulnerabilities occur when software unexpectedly writes more data to memory storage than has been allocated for that data. The extra information spills into other memory, altering it. Smart attackers can feed carefully crafted data into software with these bugs to hijack the flow of the program so that it can be made to do malicious things, or simply crash it.
(You can learn how to exploit these sorts of holes, and then how not to make these bugs in the first place, by [1]studying [2]books and then playing [3]through wargames .)
[4]
In a Wednesday [5]advisory the FBI and Uncle Sam's Cybersecurity and Infrastructure Security Agency (CISA) labelled such memory safety flaws “unforgivable” because they’re avoidable if developers stop using outdated and unsafe coding practices and languages.
[6]
[7]
The agencies highlighted a half-dozen buffer overflow vulnerabilities, some of which attackers exploited before manufacturers issued patches:
[8]CVE-2025-21333 , a privilege-escalation flaw in [9]Microsoft's Hyper-V NT Kernel Integration VSP component that could allow a local attacker in container-based environments to gain SYSTEM privileges.
[10]CVE-2025-0282 , a critical stack-based buffer overflow bug leading to unauthenticated remote code execution (RCE) in [11]Ivanti's Connect Secure that was exploited as a zero-day.
[12]CVE-2024-49138 , another [13]Microsoft bug , this one also exploited as a zero-day. It allows escalation of privilege attacks on the Windows Common Log File System Driver that can lead to full system access.
[14]CVE-2024-38812 , a critical [15]VMware vCenter heap-overflow vulnerability that leads to RCE and was exploited in attacks after Broadcom's first attempt to fix it didn't work.
[16]CVE-2023-6549 , a memory buffer flaw in [17]Citrix Netscaler ADC and Gateway products that allow out-of-bounds memory read and denial-of-service attacks.
[18]CVE-2022-0185 , a heap-based buffer overflow flaw in the [19]Linux kernel 's legacy_parse_param() function could allow local users in a Linux user namespace to escalate privileges if unprivileged user namespaces are enabled. It was exploited by [20]Chinese spies .
"CISA and FBI maintain that the use of unsafe software development practices that allow the persistence of buffer overflow vulnerabilities — especially the use of memory-unsafe programming languages — poses unacceptable risk to our national and economic security," the two government agencies wrote in their joint security alert.
The Feds point out that developers can avoid creating such flaws using [21]memory-safe coding languages such as Rust, Go, and Swift.
[22]Dump C++ and in Rust you should trust, Five Eyes agencies urge
[23]Boffins carve up C so code can be converted to Rust
[24]Rust haters, unite! Fil-C aims to Make C Great Again
[25]The US government wants developers to stop using C and C++
Both agencies understand that rewriting entire codebases in memory-safe languages will require "significant effort," and as such recommend manufacturers implement a phased transition plan. While making this shift, "manufacturers should also consider leveraging technologies to limit memory safety vulnerabilities in their existing code bases," CISA and the FBI note.
The Feds also fancy compiler flags that implement compile-time and runtime protections might help.
Running unit tests with an instrumented toolchain – one with [26]AddressSanitizer and [27]MemorySanitizer enabled, basically – is also mentioned as a helpful tactic. Both tools can perform runtime checks for memory safety issues.
[28]
The government also urged software developers to "conduct aggressive adversarial product testing, including static analysis, fuzzing, and manual reviews" throughout the entire development lifecycle.
Undertaking root-cause analysis of past vulnerabilities was also recommended, so developers can learn from past mistakes. ®
Get our [29]Tech Resources
[1] https://www.amazon.com/Guide-Kernel-Exploitation-Attacking-Core/dp/1597494860
[2] https://www.amazon.com/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441/
[3] https://overthewire.org/wargames/behemoth/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z618ce8-7pcEO11KTVWmiAAAAJg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://www.cisa.gov/resources-tools/resources/secure-design-alert-eliminating-buffer-overflow-vulnerabilities
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z618ce8-7pcEO11KTVWmiAAAAJg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z618ce8-7pcEO11KTVWmiAAAAJg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.cve.org/cverecord?id=CVE-2025-21333
[9] https://www.theregister.com/2025/01/15/patch_tuesday_january_2025/
[10] https://www.cve.org/CVERecord?id=CVE-2025-0282
[11] https://www.theregister.com/2025/01/09/zeroday_exploits_ivanti/
[12] https://www.cve.org/CVERecord?id=CVE-2024-49138
[13] https://www.theregister.com/2024/12/10/microsoft_patch_tuesday/
[14] https://www.cve.org/CVERecord?id=CVE-2024-38812
[15] https://www.theregister.com/2024/11/18/vmware_vcenter_rce_exploited/
[16] https://www.cve.org/CVERecord?id=CVE-2023-6549
[17] https://www.theregister.com/2024/01/18/citrix_netscaler_bugs_attacked/
[18] https://www.cve.org/CVERecord?id=CVE-2022-0185
[19] https://www.theregister.com/2022/01/20/ubuntu_2104_eol/
[20] https://www.theregister.com/2024/03/22/china_f5_connectwise_unc5174/
[21] https://www.theregister.com/2023/12/07/memory_correction_five_eyes/
[22] https://www.theregister.com/2023/12/07/memory_correction_five_eyes/
[23] https://www.theregister.com/2025/01/03/mini_c_microsoft_inria/
[24] https://www.theregister.com/2024/11/16/rusthaters_unite_filc/
[25] https://www.theregister.com/2024/11/08/the_us_government_wants_developers/
[26] https://github.com/google/sanitizers/wiki/addresssanitizer
[27] https://github.com/google/sanitizers/wiki/memorysanitizer
[28] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z618ce8-7pcEO11KTVWmiAAAAJg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[29] https://whitepapers.theregister.com/
hmmm. FP!
`US authorities have labelled buffer overflow vulnerabilities "unforgivable defects”,`
I don't know how to resolve this; first "US authorities" == "unforgivable defects".
Thus:
"unforgivable defects" have labelled buffer overflow vulnerabilities "unforgivable defects".
Somewhat ambiguously,
"US authorities" have labelled buffer overflow vulnerabilities "US authorities"
which is amusing if unproductive.
I suppose, if you looked at it as a yacc-ish thing:
nonsense: US_authorities mumble_fuck US_authorities ;
US_authorities: "US authorities" | "unforgivable defects" ;
mumble_fuck: "have labelled buffer overflow vulnerabilities" ;
Well done brave heroes!
Are the Feds willing to pay for it?
It will be interesting to see if they put their (our taxpayer's) dollars where their mouth is.
Regardless of how much technical politics are playing into this stance, a couple of things will become evident:
1) Proposals will likely be overstated cost-wise due to the justification of finding devs with experience with the newer languages (Rust). Whether or not the increased cost is justified or not, remains to be seen.
2) "Memory safe" languages, at least in the case of Rust, are not so memory safe when dealing directly (or indirectly via 3rd-party libs written in, for example C/C++) with hardware mapped registers. So while upper level modules may be safer the low-level modules are not. This has been my direct experience when dealing with both writing and using low level device "driver" modules/libs. I have never personally seen any java code (other than a serial port) that deals with hardware at any level of efficiency/speed. This doesn't mean it doesn't exist, just that I have never seen anything remotely useful at the hardware level that was implemented in java.
3) If the Feds demand this, then the future may be bright for Devs with the requisite experience (or those that claim to have it). At least for the first couple of years once contracts with these types of requirements go out for bid.
Personally, I have been using the *"_s" (_s = "secure") Win32 C++ functions/libs from MS for quite a few years now that go a long way for preventing buff overflows. That along with ASAN (Address Sanitizer) finds problems readily during unit tests. Of course, some constructs require code to "check and guarantee" memory safety, but that's what comes with experience and code reviews (one would hope)..
FFI Libraries
> "Memory safe" languages, at least in the case of Rust, are not so memory safe when dealing directly (or indirectly via 3rd-party libs written in, for example C/C++) with hardware mapped registers.
That's why the focus on memory safety annoys me. Yes, the borrow checker is amazing. I love it. But we should also apply design by contract a lot more than we do—especially when calling unsafe code outside the type system. Assertions at the beginning and end of each routine can do wonders for catching errors before they blow up into vulnerabilities.
Re: FFI Libraries
I have no idea why this was down voted as it is obviously correct. I've never seen anyone claim otherwise although I have no doubt that someone has. With the advent of "new truth" AKA alternative facts all bets are off.
As for buffer overruns, if you use a buffer in C/C++ or any other non memory safe language check for overruns/under runs before reading/writing it and use library routines that enforce buffer size limitations. I mean this is not difficult or particularly time consuming, programming 101 folks.
Re: Are the Feds willing to pay for it?
"Are the Feds willing to pay for it?"
They pay for it one way or another. It's been my experience that you pay more when it has not been fixed. It's also been my experience that nobody that has any real say in the matter seems to have learned that lesson.
Microsoft?!
They have so many 20-30 year old dialogs built into major products, what do you want, they should clean them all up? They've probably lost the source code to most of them, LOL.
Re: Microsoft?!
Way back in the day I had a chance to talk briefly with the product manager for MSDOS 4.0 not long after it's release. In the course of discussing other things she mentioned that there were parts of it that they didn't dare touch -- they'd lost the source code. So yeah, it happens.
How about we make software vendors legally liable for product defects, as in just about every other critical infrastructure industry? Maybe even have professional certification required.
Yeah, it'd slow things down a lot, but would that be such a bad thing? It would keep Windows 12 at bay, for starters.
Really?
Software security lecture from the Government that couldn't build a secure and reliable healthcare marketplace website. Lectured about security by a Federal Law Enforcement agency that has blatantly ignored and violated the very laws they have sworn to uphold. The FBI has been caught repeatedly abusing the FISA database, caught taking data and photos from State Drivers License computers for their facial recognition database without warrants or permissions. They helped and did their own hacking after 9/11 with the NSA in backdooring anything and everything they could get their hands on, inside and outside the U.S. While pushing for backdoors in encryption algorithms. Do you know what security is or means? Software engineering lecture from a Government that still uses ancient mainframes reliant on COBOL, secure only in their inability to connect to or run anything remotely modern, being 30+ years old. When the CISA allows months to years for a patch or update to be applied on systems that are vital to the nations ability to function and defend. I don't think they have any room to lecture anyone about security in any form!
Lots of "talk" about securing our nations borders, cyber, infrastructure...etc, but the Government can't manage to update or secure it's own systems. The State Department runs Windows XP, an OS that has not received security updates for 11 years. Real secure!!
"Bureaucrats ought to be spelled burro like they act." -Comedian Gallagher
Dr. Evil: How can we make our program better? We need innovative ideas people!
Frau Fabrissa: Let's make it fun! We can rearrange the menus and getting work done will be like playing hide and seek.
Number 2: Let's create a new UI over all the already existing UIs and it will seem like anew product, people love new things.
Scott: Why don't we just focus on finding and patching vulneraibilities and fixing bugs so we can have a stable and bulletproof UI?
[Everybody laughing]
Dr. Evil: Scott unless you have something smart to say, ssshshh zip it...