MITRE has published this year’s list of vulnerability categories. The list of the top 25 types from the Common Weakness Enumeration (CWE) system shows that the top three are exactly the same as last year. Combined, just those three account for about half the problems.
CWE #1, #4, #7 and #17 are memory safety bugs. In this week’s Secure Software Blogwatch, we point the finger at C/C++.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Gary will send you the bill.
[ Get report: RL NVD Analysis: A Call to Action on Software Supply Chain Security ]
It’s not rocket surgery
What’s the craic? Sergiu Gatlan reports — “MITRE releases new list of top 25 most dangerous software bugs”:
“43,996 CVE entries”
The top 25 most dangerous weaknesses plaguing software … encompass a wide range of issues. … They can provide an entry point for malicious actors attempting to gain control over affected devices, access sensitive data, or trigger denial-of-service states.
…
MITRE scored each weakness based on its severity and prevalence after analyzing 43,996 CVE entries from NIST's National Vulnerability Database (NVD) … reported across 2021 and 2022. [It] focused on CVE records added to CISA's Known Exploited Vulnerabilities (KEV) catalog.
Quick, tell me more. Richard Speed obliges — “The annual list features the usual suspects”:
“Reminder that errors still slip in”
US not-for-profit cyber security research organization MITRE has … the top three remaining unchanged from last year … once again topped by out-of-bounds write flaws … (when a product writes data past the end or before the beginning of the intended buffer). … 70 such vulnerabilities were added to … KEV.
…
At second was improper neutralization of input during web page generation, also known as cross-site scripting (XSS). … Rounding out the top three is SQL Injection. … Moving up to positions four and five respectively were use after free flaws … and improper neutralization of special elements used in an OS command … also known as 'OS command injection.'
…
The list is a useful reference for enterprises seeking to harden their … environments. Despite the existence of scanning tools to check for vulnerabilities, the list is a reminder that errors still slip into even the most used products.
What’s the prescription? Jessica Lyons Hardcastle dispenses it — “Cough, cough, use Rust”:
“Will publish a series of reports”
Out-of-bounds write, sometimes labeled CWE-787, also took the top spot in 2022, showing a distinct lack of improvement. … Ideally, software should be written to prevent this kind of overwrite, and using memory-safe languages like Rust can help here.
…
Number four, however, was one of the "biggest movers" on the list, jumping from the seventh spot last year to the fourth-ranked most dangerous issue this year. It's … use-after-free: This type of exploitable bug is when a program, remote service, or operating system component releases memory that's no longer needed, and then continues to use it anyway. … Again, memory-safe languages are useful here.
…
MITRE … will publish a series of reports over the next few months that aim to help organizations "more effectively" use the Top 25 list. These will cover a range of topics including weaknesses that didn't quite make the Top 25 — but orgs should still be aware of them.
Have we learned nothing? Boris the Cockroach sounds exasperated:
Buffer overrun? Still?
Someone take me outside and shoot me. I feel like I'm trapped in that never ending circle of hell where whatever you do … you end up back in the same place every time.
So Rust is the answer? bestouff agrees:
By using a GC language you avoid a few of them. By using Rust with a proper framework you should avoid most of them — if not all. A proper type system can save your *** very often.
But bombastic bob broadly bickers: [You’re fired — Ed.]
No need to implement garbage collection memory control, nor use Rust to fix this. … There are warnings you can enable in llvm-based C/C++ compilers that find a lot of things.
Other C/C++ tricks include use of strncpy, snprintf, etc which have buffer checking built in, as well as avoiding more obvious things, by sanitizing "foreign" (and even internal) data and structures, and … the simple fix of 'fgets' vs 'gets' on stdin. Custom APIs with output to buffers should also do size checking and have the output buffer size specified. The simple things.
Yep, not everyone likes Rust. Or they, at least, want a choice — andrewstuart, for example:
We need more than one … memory safe language.
Perhaps it’s not really a language problem at all? Here’s Steve Crook:
Some years back I ran a small team of programmers along with my main job of designing the software they were writing. I got management complaining about the time one my programmers was taking to complete his work.
…
I pointed out that he had the best quality code, had fewer system, integration, unit test problems and virtually nothing reported by customers. He was, I pointed out, by far their best programmer. The response was that he was too slow, and that they had releases to get out. Rust will not fix that problem.
Meanwhile, if you don’t like Rust, how about Go? knorker points out a “fundamental flaw”:
It annoys me no end how Go could be created in the 21st century but willfully ignore so many lessons from the state of the art in language design. The more code I read and write … the more disappointed I am in how much of a missed opportunity Go is.
And Finally:
You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.
Image sauce: Glenn Carstens-Peters (via Unsplash; leveled and cropped)
