Feds want devs to stop coding 'unforgivable' buffer overflow vulnerabilities US authorities have labelled buffer overflow vulnerabilities "unforgivable defects”, pointed to the presence of the holes in products from the likes of Microsoft and VMware, and urged all software developers to adopt secure-by-design practices to avoid creating more of them. Buffer overflow vulnerabilities occur when software …
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...
Is lawyers have to start arguing that these types of vulnerabilities constitute negligence on the part of the coder/company. Both people & companies respond to incentives, especially economic ones. Make it cost real money when miscreants gain entry via things like buffer overflows & cause real economic loss. Don't allow the EULA to shield anyone from the consequences of their incompetence or negligence.
`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!
I'm a bit fed up with vague quotes attributed to "US authorities", "security experts" and the like. Unattributed sources could be anything or anyone and, as we often find out in real life, are often the product of organizations with an agenda.
(AFAIK there's no such thing as a "US Authority".)
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)..
> "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.
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.
I'm not sure why you're annoyed. Rust code is safe by default to the vulnerability this article talks about thanks to the efforts of the compiler and runtime. Not just buffer overflows but also null pointers, double frees, concurrency & ownership issues. If you don't write the code in a way to satisfy the borrow check it results in a compiler error or a panic rather than becoming code that breaks later.
As for unsafe blocks, yes it supports it as a way to talk to C. It wouldn't be much use as a real world language if it couldn't bind to C which is seen as a the lowest common denominator. But those blocks are explicitly marked in code and very easy to search for if you suffer an issue. Certainly much better than everything being unsafe and where the cause of an issue, or the attack surface being literally anything.
Ah, I may see why you don't understand Dostoevsky's annoyance!
If a Rust application doesn't have exclusive control of the memory regions that it has access to, the assurances of the borrow checker and runtime are wholly obliterated. In those circumstances, using the fact that the language was memory-safe to excuse the need for additional validation may result in a less safe application than one written in a memory-unsafe language where additional scrutiny is applied due to the unsafeness. Calling a C function within a Rust application, dealing with MMIO, or running code on a machine with a compromised kernel could lead to these circumstances (and a compromised kernel wouldn't even require the code to be explicitly unsafe).
The lack of granularity in unsafe could potentially be exploited for some pretty neat FFI-based supply chain attacks, unless cargo update automatically warns about changes to unsafe functions that are being called by the main application. I know for a fact that I wouldn't do a manual deep-dive into my unsafe dependencies at every update, so I have to imagine that other folks in positions of power are out there with the same shortcoming.
My personal issues with Rust are its aggressively homogeneous community of "rustaceans" who think that their language is objectively superior to all other languages in every way and its contributions towards the continued normalization of the language-as-a-package-manager trend. Despite those attributes, it's a beautifully-designed language, the documentation doesn't require Internet access, and Cargo has flags to suppress its desire to infect my machine with automatically-sourced third-party dependencies.
Right... except for 99% of the time, Rust DOES have control of the memory regions it has access to. And if it doesn't then your operating system is broken or you're dealing with volatile memory and you'll be using unsafe block to deal with it. Everywhere else will be safe by default. A sane response would be to say "hey that's a tangible improvement on C where everything is unsafe" rather than contrive some silly examples, or shift the goalposts and pretend somehow the compiler and runtime checks mean nothing.
Also, I don't know why you're going off into a rant about Rust in general. I'm sure Cargo is vulnerable to some attacks. So too is vcpkg and conan. What's your point? Or moaning about the Rust community for some straw man attack. It's bizarre.
I, at least don't question the tangible benefits; I question the cost.
There have been countless virtually unusable languages which make these sorts of guarantees.
The earliest I encountered was Euclid, which was 40 years ago.
Although Euclid lacked Rust's punctuation flamboyance both are similarly difficult to work in.
I think it is possible to keep the baby, and discard the bathwater.
"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.
that's from someone else's budget though so it doesn't count. Until the cost of supporting and fixing these systems (including all downtime, workarounds etc incurred by the user community) come from the same budget that 'saved' money by squeezing dev and testing time then these things will never get fixed.
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.
Hold it HOLD IT!
Those 20 to 30 year old dialogs are the reason why still anything is working! That code is so old, any bug would have been visible for a long time. And we NEED those old dialogues since the new-fancy-more-whitespace-please are inferior and miss many options. I already have to replace some completely removed (not even rundll calls work any more) dialogues with powershell commands...
Though I would love MS to update some of it, like any MMC/MSC having the divider bar move 120 pixels to the right as defalut, and make it a pixel wider to make it easier to grab... Unchanged since Windows 2000. Or to update gpedit/gpmc (for GPOs) to use the same scheduled task dialogue as Server 2012 with more options, or to import an .XML there.
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.
You cannot prove zero defects in non-trivial software, so a hard lemon law wouldn't work. However, softer versions should be fine.
Valgrind, Dmalloc and Electric Fence mean buffer overflows and memory leaks can be detected in Linux software trivially. So those defects are 100% avoidable.
There are plenty of static checkers (eg: Coverity, Klokwirk, PVS-Studio), so common defective coding practices can be avoided.
For mission-critical software, a development strategy similar to that used by SEL4 would be able to reach extremely high levels of software assurance. This is a market where the extra cost can reasonably be included.
So we can, quite reasonably, argue that certain classes of defect should be 100% absent from specific classes of software.i think that is perfectly reasonable.
From this, we can argue that limited lemon laws should be in place.
Since we can also estimate software defect density, it would also be possible to have software certified to some established level of quality, entitling the vendor to market the software accordingly.
The user then gets to see the specific risk level for that product.
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
I'm not sure that follows. Just because the US Government doesn't practise what it preaches doesn't necessarily mean that what it preaches is wrong. The principle that certain software security vulnerabilities can easily be avoided and should not be tolerated applies regardless of who is saying it. Of course it would be better if the Government led by example, but the idea is still sound.
Either pay me a shedload of money or screw off.
I'm CANADIAN, and not subject to your tyrannical rule.
Thank the Universe for that lucky break in life! I came to my senses post 9/11 and abandoned my pursuit of an H1-B and Green Card when you turned paradise into a police state in response to a terrorist attack. The terrorists killed the American Spirit that day, and set a festering poison of mistrust, fear, and hatred in it's place that has resulted in the deep divides and the rise of a Pumpkin Hitler that shouldn't have even been eligible to run after trying to overthrow the duly elected government of the United States during the previous election...
I'm CANADIAN, and not subject to your tyrannical rule.
Not yet, anyway.
The terrorists killed the American Spirit that day, and set a festering poison of mistrust, fear, and hatred in it's place that has resulted in the deep divides and the rise of a Pumpkin Hitler that shouldn't have even been eligible to run after trying to overthrow the duly elected government of the United States during the previous election...
Brazil didn't mess around. If Brazil can do it, I have no idea why US couldn't.
I guess at least 50% of these bugs would go away. But no, C still have to rely on character arrays designed to output sometimes a few lines ot text to a teletype using clumsy functions calls in the 1970s.
Until this mindset is left were it belongs, in an outdated past, it will be impossibile to build secure systems.
It's easy to switch to C++ified C and use strings instead of fixed-length character arrays. It doesn't even take a lot of time to convert existing code but it's not done because that would mean slightly less profit at the end of the quarter.
Yes there is a problem with mindset, but it's not the programmers' mindset rather management mindset.
C libraries, lots of libraries, which are integral to *using* the language (not part of the language proper, although you can *generally*, not always, get an initial set of "get you started with 'Hello World'" standardised libraries with the compiler).
One subset of those My First C Libraries are a few routines that let you do basic manipulation on strings represented in the way that the compiler presents constant strings that you put into the source code. After all, the compiler needs *some* way of presenting those to you and there is no point in doing anything complicated. Because...
Anyone who wants to do anything more exciting with strings in a C program can simply use a library that provides a representation that best fits their needs.
I am quite fond of using structs for the (buffer, buffer len, how full now) representation. But also like a one-codepoint-per-cons-cell approach when digging in and doing macro expansions: less space efficient but constant-time insertions and deletions.
The same goes for C++ by the way: the compiler uses the simplest possible form for constants, you get to choose which library to use for your code (many people use the STL).
Any language that promotes use of libraries can do the same, although more recent languages do promote a more complicated compiler/interpreter representation for constants - even though there is nor, and can never be, One True Representation Of Strings that is Optimal In All Circumstances. The same goes for numbers as well, of course.
The problem with that is that, unless there is a relatively standard library, you can only do that within your own code. Find a string library you like, hope they've got all the Unicode support you'll need in there, but if you ever need to include code from someone else, you can be quite certain that they did not use the same library you did. All the strings going back and forth to that will either be C strings or they'll have their own internal format, maybe because it's similar to whatever library they picked. Only some types of programs can use the model you describe. This is one reason that a lot of other languages have treated strings as a primitive. You are still welcome to get a library that implements them differently if you want that, but there is a more full-featured option as default.
> a lot of other languages ... there is a more full-featured option as default
Absolutely. And more power to them.
However, the question was about C (and C++), which - we all admit - has only the absolute bare minimum work done by the compiler to deal with the necessary evil of allowing (static) constant strings to be defined in your source code.
> Only some types of programs can use the model you describe
True.
Then again, that is trivially true for every single model you could ever describe. The interesting bit is whether the "some type" is a large number of programs (or even a large subset of programs).
> All the strings going back and forth to that will either be C strings...
When you look at it, all those inter-library strings tend to be passed as a buffer+length pair (preferably also null-terminated, if not hope for a better library) or even buffer+bufsize+strlen. In really well-behaved cases you can get a lock token included as well. Yes, often using a struct to keep that info together, but that doesn't imply that struct actually is "their own internal format", just a simple way to pass the data between libraries. The "pointer to a null terminated buffer" also happens to be a C string, useful for a quick printout.
All of which sounds terribly nasty to deal with, but: you get exactly the same effect with other forms of data, once you get beyond simple numerics; anything that can be a non-trivial size. Strings are not unique in that respect[1]. So image handling libraries all have their own formats (some choose to be compatible with a.n.other popular library, which is fine - until that library changes it's format or just gets overshadowed by the next big thing). Again, when you need to pass images from one library to another, you tend to end up being handed a buffer plus some metadata and you do the impedance matching as necessary.
[1] although you can argue that more people use strings than any other type, but I'd suggest looking at how many actually manipulate strings[2] versus just spitting out fixed text: hello_world.c doesn't do any string processing, the M4 macro processor does.
[2] I'd also look at how many (try to) write code to manipulate strings when they really don't need to. A lot of code will (sensibly) pass image handling over to a subprocess using, say, ImageMagick via it's executable, rather than linking it in as a library. Ditto ffmpeg or cURL. If you are really doing a lot of work to manipulate strings and your main program is in C, you can do a lot worse than invoking a specialised string footling program rather than a library.
Somehow, those old C programs manage character I/O with modern hardware. If you do find a Teletype™, it's likely to still work if you apply some WD-40 to the appropriate spots.
There's a lot good to be said about hardware and software which continues to do its work correctly.
(If you do get a Teletype™, I'd recommend wearing ear protection while using it.)
It is part of the freedom definition: You can do and release many things completely unsafe (not limited to programming) and don't have to do a thing about it unless it is proven unsafe by death of injury. It is part of the customer freedom self responsibility to notice those dangers, of be able to choose the dangerous version at will. See food additives as most prominent example, a lot of it is forbidden in Europe, China and India. The whole success of the country rests upon that "safety" is NOT the first priority in almost all areas. Yes, there are some famous lawsuits, which only result in having more fine-print and nonsense like "objects in the mirror look further away than they really are" "don't put living things into a micro wave". But for most of the part the customer is frigged, and has no way to go against scamming. Or against corpo which, for example, make your tap water flammable.
There is a reason why there are so many USCBS videos... (anybody got a good suggestion for more content like that channel?)
It is part of the customer freedom self responsibility to notice those dangers, of be able to choose the dangerous version at will.
It is unreasonable and less than fair on your part to expect the average Joe|Joesephine Q. Public to understand the technical details of computer programming!
C for Linux has valgrind, dmalloc, and Electric Fence.
For Windows, there are copious commercial memory debuggers that integrate well with Visual Studio.
Yes, memory-safe languages prevent other memory-related bugs, but for simple stuff like overflows, there has never been a shortage of tools, just a shortage of common sense.
It's about supply chain attacks - they want us to use a single source compiler that can be attacked.
The rest is some handwavy bullshit - If you want to have bug free code - you test it. That's it. C using explicit data structures is a productive language
It's not cheap, it requires skill, time and diligent attention to the work, design and tooling but it's a fantastic tool. Rust is being pushed by people who would happily see me die sick and starving but claim to preoccupation with my safety.
C will shrug it off. We been talking about bounds and range checking for 30 years. And there have been lots of safe alternatives that could have been used. But nothing has changed and C is still held up at the example of what not to do. We won't see C replaced in my lifetime.
Then start creating a list of which offense style results in which punishment...
- Buffer overrun
- missing check on return data
- off by on error
- is ZERO or ONE the base now
- using singed where unsinged should be used, only to be discovered decades later when, for example, the storage devices reach INT32 limit, and UINT32 should have been used in first place
- using too small data type, like the time when UINT32::MaxValue was reached for Warren Buffets stuff
- using too large data type for wasting space
- erroneous conversions, for example string to number.
- erroneous conversions, neglecting the local language whether "," "." " ' " is either an actual separator between number and fraction, or just a thousand separator (Hello Excel, thanks for silently converting 10.100.100.100 to 10100100100 just 'cause the thousand separator is ".", and leaving 10.100.10.100 a string as it should be) (Hello Libreoffice for silently converting TRUE to 1 and FALSE to 0 when not expected, though LO allows a simpler way to avoid that)...
- punish for silently converting an array with one entry to a non array (powershell)
We will end up with no programmers at all, either 'cause their hands were cut off by returning to middle-age punishment, or by fear.
What will be next on you list? Oh, what about mathematicians? Physicists? Carpenters? Metal workers? The one in your group responsible to keep the fire burning so you can have warm food the next day?
…those that from afar look like flies…
The biggest problem is that you often can't know that something is a bug until someone works out how to exploit it. This is the reasoning behind the general exemption from liability that software has enjoyed for the last 40 odd years.
In other trades, unlimited liability does apply in the US but has occasionally led to curious outcomes: once it became possible to identify the sex of a foetus early in pregnancy, it didn't take long for the first class actions and then for obstetricians to refuse to tell patients or even take them on.
What we could probably do with is a better culture of accepting responsibility and mitigating the issues in a way that can be applied both to commercial and open source code.
> a better culture of accepting responsibility
you mean the way politicians do? Once discovered go away and let others clean up the mess? Or the variant where, once discovered, a scapegoat is found to make go away in place of the one who did the mess? Or the variant where you appoint someone to find the scapegoat for you to fire?
As for "applied to open source code": You'd need to make it mandatory for everyone to register and pay for the support if they intend to use that open source code in another project, with a very well worked out contract about liability. Especially fun when multiple people work on it.
No, I don't mean that. I mean it much more generally. Currently, we don't have a culture and legal framework that will accept that, while bugs may occur, these are rarely malicious, deliberate, or even the result of poor practices, mitigation is more important. Threatening sanctions could be useless — think of the many at least partly abandoned open source projects — or even counterproductive. But neither is the current shoulder-shrugging promise to do better next time from the likes of Microsoft and Apple.
But the responsibility isn't solely with the developers because — and I don't mean you should get out the jossticks and whalesong — in a sense we're all involved in this. Can we come up with ways to set and follow standards and, where necessary pay for mitigation? Difficult to see how current approaches avoid creating a gravy train for those probably least suited to improving things! And limited sanctions for commercial offerings may be part of the solution, though I suspect stricter disclosure and resolution timeframes may be both more acceptable and effective. We are going to have to do something because at some point, some awful disaster is going to be directly attributable to a software error.
Let’s be clear: negligence in software development is no different from negligence in engineering, medicine, or construction. If a faulty bridge or misdiagnosed illness warrants accountability, why not a buffer overflow that compromises millions of systems? Bugs cause real harm - financial losses, data breaches, even life-threatening failures in critical systems.
A clear, enforceable framework of consequences would instil discipline, responsibility, and quality. Developers wouldn’t dare ship insecure code if a stint at His Majesty’s pleasure loomed overhead. Rust and other “safety nets” are just tools to compensate for recklessness. Accountability, will do far more to eliminate these blunders.
So, why not start drafting that offence list? Precision is a virtue programmers clearly need to learn - preferably before the next catastrophic integer overflow.
I'll back this one.
In my world of robot wrangling, incorrect code does'nt result in a blue screen or the application showing an "Unhandled exception error, please report" it can result on 5 lbs of steel spinning at 2000 rpm coming out of the machinery closely followed by the remains of the tooling. oh and needing a clean set of underwear.... and maybe 3 hrs in a shocked state because it just whizzed past your head on its way to punching a good dent in the wall.
Software IS engineering, and should be regulated and approved just as civil, mechanical, electrical and airspace engineers have to be. and it should be expected that someone certificated in software engineering wont be putting buffer overruns into his/her code.
Anyway... back to the precision bit... somehow I have to make 10 000 widgets with a hole 7mm hole +/- 0.0015mm aiieee I wanna do software
No, it is mathematics. Specifically, the claim, "The following code, when compiled, linked and executed on perfect systems, does exactly what it is supposed to do" is a mathematical theorem.
And I'm not talking about the "theorems" we glossed you with in calculus. I mean the real stuff that you only get to in graduate school.
Yeah, I got into the PhD program in Austin. That's about the minimum requirement, by the way.
" it can result on 5 lbs of steel spinning at 2000 rpm coming out of the machinery"
So the bug only becomes dangerous when it is part of a larger piece of engineering, where presumably there is already a legal requirement that it should be safe and fit for purpose.
I'm not seeing a need to specifically regulate the software aspects. Existing laws are sufficient. If you make and sell a product from shoddy materials and someone gets hurt then you get sued.
Perhaps what needs to change is the legal system's awareness that buffer overflows are not an Act of God but, in many cases, indicate a failure to do rudimentary testing with standard tools, starting with enabling compiler warnings for unset variables, array overruns, and uses of library functions that don't bother with a "buffer size" parameter.
Negligence in all of those areas is covered by regulations, guidelines and contracts that are applicable to the field and end use. That already includes the software components: if you are writing critical systems then you follow, eg, SIL and are held to it.
> So, why not start drafting that offence list?
It makes as much sense to create an offence of allowing a buffer overflow as it does to create an offence of a dry solder joint or an under-torqued bolt: the bolt was in my Meccano Eiffel Tower, the solder was for my light-up-beanie and the software was for my Moog emulator.
If you want to incarcerate the coder who let that overflow slip by then you have to use the same mechanism that would allow you to incarcerate the spanner jockey who failed to tighten the bolt - and so far I've failed to come up with a search result for a law that created the offence of under-torquing.
They probably have a point when the unforgivable functions gets(3), sprintf(3) or getwd(3) were responsible for the overflow.
Arrays not being a first class type in C was always a flaw and not being able to determine a vector's capacity at runtime probably a cause for more forgivable overflows.
Most of the trivial causes of buffer overflows never existed in Pascal, Modula2 and Ada with the last the US government (or at least the DoD) mandated replacement for all their software projects. That worked out well, didn't it?
> Arrays not being a first class type in C was always a flaw and not being able to determine a vector's capacity at runtime probably a cause for more forgivable overflows.
As much as I enjoy(ed) using C, I have to agree - you can (should - MUST) use libraries to manage such structures safely. Because the language (for perfectly sensible reasons, at the time it was created) uses array-notation[1] as a shortcut.
It is a "flaw" when you get into the modern situation where we *do* have the CPU/memory resources (compile- and run- time) to make using a pro-actively safer language feasible - and once feasible, preferable.
It is just a damn shame that we are all caught in the trap that creating (and getting into wide use) new languages is such a costly exercise. Which leads directly into bad side-effects such as making the jump from one language to the next too large to allow for simple changeover - and the emotional outbursts that inevitably come from that, which then creates polarisations etc etc.
Personally, I would be quite happy to have a new language[3] that is almost-C (or almost-C++) but which simply disallowed the array-notation syntactic sugar, then provided a meta-syntax to define safe usage for that syntax (i.e. called into appropriate routines for the type it was applied to). With a supplied set of basic implementations for char, int etc. If I pull out my old text books (I see Dragons!) I'm confident I could mangle, say, TCC to make the change, but that isn't likely to gain any traction outside of my LAN (for good reasons!)!
[1] perhaps it would help if everyone understood, deep in their bones, that C was never *created* with arrays, just syntactic sugar[2] to pretty up code that derefs - something that used to be demonstrable by using foo[bar] as a synonym for bar[foo] - but then the whole problem of buffer overflows everywhere comes from the fact that we want code to be written by people who don't have the right sort of bones.
[2] ditto for-loops, of course, another area - which also "helps" with causing buffer issues - where errors occur and people get into a huff about what you can, or can not, put into the sugar wrapping.
[3] no, it would NOT "still be C", it would be a different language, different filename extension etc etc
Buffer overflows are a consequence of languages like C and C++ that don't enforce buffer limits and where things pointer arithmetic can easily step outside of a buffer. You could scream at developers to not do the bad thing, but as long as they use languages allow it, it will happen forever. The only mitigations are layer upon layer of static analysis and rules like MISRA but really the sane option is to use a language not vulnerable to the exploits in the first place.
Buffer overflows are not the fault of the language.
If you are a C programmer and you don't sanitise input, don't check for overflow when using arrays, don't use strncpy where appropriate, don't check arguments to your functions, don't check the return value of functions that you call, etc, etc, etc - you as the lazy programmer are the cause of the buffer overflow!
Do a professional job. Think about what you are doing.
Blaming the language is just excusing all the programmers who are incapable of using the language properly and writing good code.
Erm yes, they're the fault of the language and then you go on to admit it by saying if programmer doesn't do X, Y, and Z then bad things may happen. i.e. the language is shit. The language and compiler could have stopped the bad thing happening but it doesn't care. And then we get the C and C++ defence force leaping out of the woodwork moaning that if only if everyone were a Super Programmer (tm) just like them then of course bad things wouldn't happen. Except they keep happening over and over and over again because nobody is Super Programmer and the language is shit. Is this so hard to understand? Even when you're writing a comment against an article by a government begging people not to use shit languages?
Quote: "....Feds want devs to stop coding 'unforgivable' buffer overflow vulnerabilities...."
Yup....and UK citizens want Met Police officers to STOP kidnapping, raping and murdering people like Sarah Everard!!!!
Yup....and UK citizens want KNOWN bonkers individuals to stop killing nine year olds at dance classes!!!
What's your point????
I've personally tried telling my team lead politely multiple times that it would be a good idea to run a static code analysis utility such as Cppcheck, Coverity, or the MS Visual Studio static code analysis feature as part of the Bamboo build to generate a log file that gets triaged as part of the release process, and to please pass along my concerns to Management, and it just goes in one ear and out the other.
MS Visual Studio has a C/C++ Debug build memory corruption detection feature for runtime application testing. Considering buffer overruns can overwrite other unrelated variables in memory and cause the wrong logic to run, corrupt data values, and cause errant pointers that will crash a safety critical C/C++ embedded device or video game.
Not to mention when it can be a combination of two or more issues where the code isn't thread-safe and there are buffer overruns.
The reality is they are needle in the haystack problems that can be difficult to spot or find in huge codebases with a looming release date.
Some Directors of Engineering and Managers will jerk you around on a PIP to downsize or fire you if you don't keep your mouth shut.
and development managers who know how to focus on code quality.
A big reason that we have so many such code bugs is because so many companies can't figure out who is actually able to write good quality (secure) code, so they just hire the cheapest workers and ignore what they don't measure.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
