Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CWE Top Most Dangerous Software Weaknesses

cwe.mitre.org

Post reply on HN
Print view View original

51–60 of 131 posts

Re: CWE Top Most Dangerous Software Weaknesses

#51

Post by loup-vaillant »

pulse7 wrote: post #14

Here are Language-Specific ones: 1. CWE-787 Out-of-bounds Write: C, C++, Assembly 4. CWE-416 Use After Free: C, C++ 7. CWE-125 Out-of-bounds Read: C, C++ 10. CWE-434 Unrestricted Upload of File with Dangerous Type: ASP.NET, PHP, Class: Not Language-Specific 12. CWE-476 NULL Pointer Dereference: C, C++, Java, C#, Go 15. CWE-502 Deserialization of Untrusted Data: Java, Ruby, PHP, Python, JavaScript 17. CWE-119 Improper…

So, the memory related ones are in position 1, 4, 7, 12, 17, and 21.

I understand memory safety is important, but still: only one in the podium (though it is first), only 3 in the top 10… clearly security is about much more than memory safety.

Re: CWE Top Most Dangerous Software Weaknesses

#52

Post by deadletters »

littlestymaar wrote: post #6
tumdum_ wrote: post #3

Earlier quoted context omitted.

"But modern c++ is safe, preventing all those errors is as easy as not making them!..."

In fairness, only 2 of those 4 are actually memory-related.

And both have existing tools to find those bugs that people often just don't use.

Re: CWE Top Most Dangerous Software Weaknesses

#53

Post by pjmlp »

citrin_ru wrote: post #9
tumdum_ wrote: post #3

Earlier quoted context omitted.

"But modern c++ is safe, preventing all those errors is as easy as not making them!..."

Is there some authoritative source for what is considered modern C++ and what is old? Most projects I've seen use a wide mix of C++ features of varying age. If you use some C++23 futures it would not make it modern if you still use C++98 features you not supposed to use.

Originally it refers to what was already possible in C++98, when one leaves behind the legacy ways of coding C with a C++ compiler.

Started with the publishing of "Modern C++ Design" from Andrei Alexandrescu in 2001.

https://en.wikipedia.org/wiki/Modern_C%2B%2B_Design

When ISO C++11 came to be, many re-used the term to mean C++11 or higher.

Given that many keep updating this to mean more modern versions, a well known developer in the community (Tony Van Eerd) has made the joke of that by C++17 time we were in Postmodern C++.

https://www.youtube.com/watch?v=QTLn3goa3A8

No idea what kind of modernism to call C++23, when C++17 was already postmodern, maybe Revivalist C++.

However it basically comes back to Andrei Alexandrescu's original ideas of programming in C++ as its own language, leave the C ways and pitfalls of resource management behind, learn to embrace a modern language for systems programming.

I should also note that there are developers against this philosophy, they advocate that the C++ as understood by CFront is what one should care about, thus Orthodox C++ movement was born.

https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b

Re: CWE Top Most Dangerous Software Weaknesses

#54

Post by vacuity »

throwawaaarrgh wrote: post #31
pulse7 wrote: post #14

Here are Language-Specific ones: 1. CWE-787 Out-of-bounds Write: C, C++, Assembly 4. CWE-416 Use After Free: C, C++ 7. CWE-125 Out-of-bounds Read: C, C++ 10. CWE-434 Unrestricted Upload of File with Dangerous Type: ASP.NET, PHP, Class: Not Language-Specific 12. CWE-476 NULL Pointer Dereference: C, C++, Java, C#, Go 15. CWE-502 Deserialization of Untrusted Data: Java, Ruby, PHP, Python, JavaScript 17. CWE-119 Improper…

People have language blinders on. It's not like if you only focus on the ones that affect your language specifically, suddenly you're secure. There's still another 16 bug classes to worry about. If you don't think about the other classes, I'm still gonna escalate privileges, root your box, ransom your data, send spam, charge a half million dollars in cloud spend to your account, steal your customers' PII/PHI, etc etc…

Yes, but such neglect of other bug classes suggests that those developers aren't focusing on security anyways. For those who do want reasonable security, using a memory-safe language suddenly makes the most pervasive errors go away, and then it's easier to focus on building robust applications.

Re: CWE Top Most Dangerous Software Weaknesses

#55

Post by pjmlp »

deadletters wrote: post #52
littlestymaar wrote: post #6

Earlier quoted context omitted.

In fairness, only 2 of those 4 are actually memory-related.

And both have existing tools to find those bugs that people often just don't use.

Since 1979 with the invention of lint by Stephen Johnson at Bell Labs.

https://en.wikipedia.org/wiki/Lint_(software)

Re: CWE Top Most Dangerous Software Weaknesses

#56

Post by pjmlp »

jacquesm wrote: post #26
speedgoose wrote: post #18

Earlier quoted context omitted.

2 of the 4 listed.

It could, but it will be decades before Rust adoption is where C/C++ is today so in the meantime it would be nice to see some other, more practical and short term solution to these problems. Otherwise I can predict the the top 4 at least 50% for a decade ahead.

Hence why all major OS vendors are embracing designs with hardware memory tagging, that is the last frontier from possible mitigations.

Re: CWE Top Most Dangerous Software Weaknesses

#57

Post by Therenas »

BoppreH wrote: post #48

Aside from Memory Management, there's another general category that always comes up in these lists, but is not talked about much: in-band signaling (i.e., "Strings are Evil"): - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (#2) - Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (#3) - Improper Neutralization of Special Elements used in an OS…

What‘s the alternative though? For URLs for example, would you have to put a JSON structure into the browser? That‘s obviously not going to happen.

Re: CWE Top Most Dangerous Software Weaknesses

#58

Post by ludovicianul »

BoppreH wrote: post #48

Aside from Memory Management, there's another general category that always comes up in these lists, but is not talked about much: in-band signaling (i.e., "Strings are Evil"): - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (#2) - Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (#3) - Improper Neutralization of Special Elements used in an OS…

Out of this frustration I've built: https://github.com/Endava/cats. It's for APIs, but mostly addressing exactly this case: don't use strings for everything, if you choose to use it though, make sure you add patterns for checking if things are valid, make sure you think about all the corner cases and all the weird characters that can brake you app, and so on.

Re: CWE Top Most Dangerous Software Weaknesses

#59

Post by deadletters »

amelius wrote: post #40

Is anyone using Valgrind even anymore these days? I've noticed that using Valgrind on Python systems is almost impossible because most modules have not been built with Valgrind in mind and thus you get swamped in noise. I suppose the same is true for any large system that uses many different third party libraries.

ASan is better for finding memory corruption afaik

Re: CWE Top Most Dangerous Software Weaknesses

#60

Post by pjmlp »

jiggawatts wrote: post #45
Xeamek wrote: post #29

Earlier quoted context omitted.

>12. Null pointer deref. In java you'll get an exception, while in C you might dissapear your cat. Those 2 are quite incomparable when talking about "dangerous-ness" of a mistake

And C# is making references non-nullable by default.

Kind of, it doesn't work that well with existing libraries, and because of that, even when you enable it, it is only a warning.
Post reply on HN