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

121–130 of 131 posts

Re: CWE Top Most Dangerous Software Weaknesses

#121

Post by TheNewAndy »

deadletters wrote: post #59
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

I use valgrind regularly, and prefer it over asan. asan will result in a faster executable which is nice, but I far prefer valgrind's output than asan's (this might be preference, but I find it to be clearer), and various things break when building with asan so I never make it default. Being able to valgrind stuff without recompiling is very convenient.

I'm also not sure if asan has an equivalent to --leak-check=full

Re: CWE Top Most Dangerous Software Weaknesses

#123

Post by UncleMeat »

pjmlp wrote: post #92
UncleMeat wrote: post #80

Earlier quoted context omitted.

Of course. But these issues will remain near the top of the list indefinitely if people just leverage traditional analysis tools. I love static analysis. I did my PhD in it. But we'll still be talking about use after free in 2073 if we just try to chase higher K in our analysis implementations.

Naturally static analysis alone doesn't fix use after free in all possible cases, however it already does fix several of them when the analyser can see everything on the existing source code. The main issue is the community sub-culture of not adopting tooling as it isn't perfect 100% of the time. Many of the C++ security conscious folks end up being polyglot, as this subculture eventually wears one out.

Having spent well over a decade in this space, I assure you that the root cause of limitations for static analyzers doing lifetime analysis in C++ is not separate compilation or partial program analysis caused by shared libraries.

Re: CWE Top Most Dangerous Software Weaknesses

#124

Post by poiuyt098 »

mattgreenrocks wrote: post #7
dlor wrote: post #2

It's somewhat disheartening as a software developer focused on security that the top four elements are still: * Out-of-bounds Write * Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') * Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') * Use After Free

Our industry is ageist and anti-intellectual. These are the symptoms of those.

Could be worded as Low barrier to entry and highly compensated.

Kids get into it just by having the tenacity to do whatever it takes to make it chooch. It's all that counts.

Re: CWE Top Most Dangerous Software Weaknesses

#125

Post by pjmlp »

UncleMeat wrote: post #123
pjmlp wrote: post #92

Earlier quoted context omitted.

Naturally static analysis alone doesn't fix use after free in all possible cases, however it already does fix several of them when the analyser can see everything on the existing source code. The main issue is the community sub-culture of not adopting tooling as it isn't perfect 100% of the time. Many of the C++ security conscious folks end up being polyglot, as this subculture eventually wears one out.

Having spent well over a decade in this space, I assure you that the root cause of limitations for static analyzers doing lifetime analysis in C++ is not separate compilation or partial program analysis caused by shared libraries.

Naturally it isn't.

Again, even if not perfect, and doesn't cover all use cases, what about people would actually use something at all?

During that decade, how much time did you spent looking at the human side of the problem instead of what the tools can achive?

Re: CWE Top Most Dangerous Software Weaknesses

#126

Post by actualwitch »

dlor wrote: post #2

It's somewhat disheartening as a software developer focused on security that the top four elements are still: * Out-of-bounds Write * Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') * Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') * Use After Free

> top four elements are still

Use after free is actually gaining popularity, up 3 since last year.

Re: CWE Top Most Dangerous Software Weaknesses

#127

Post by UncleMeat »

pjmlp wrote: post #125
UncleMeat wrote: post #123

Earlier quoted context omitted.

Having spent well over a decade in this space, I assure you that the root cause of limitations for static analyzers doing lifetime analysis in C++ is not separate compilation or partial program analysis caused by shared libraries.

Naturally it isn't. Again, even if not perfect, and doesn't cover all use cases, what about people would actually use something at all? During that decade, how much time did you spent looking at the human side of the problem instead of what the tools can achive?

Nowhere did I suggest that we shouldn’t use these tools or spend time improving them. UX for tools more powerful than local AST matching indeed tends to be quite bad because explaining the chain of reasoning for an alarm is difficult.

My only point is that without a different approach we will continue to have the same problems in 2073.

Re: CWE Top Most Dangerous Software Weaknesses

#128

Post by tatersolid »

littlestymaar wrote: post #88
tumdum_ wrote: post #19

Earlier quoted context omitted.

In fairness, only C/C++ of all the currently commonly used languages can have half of the 4 top dangerous software weaknesses.

JavaScript routinely has the other half of the top4.

So do C and C++ when used in web or database applications. So they get 4/4

Re: CWE Top Most Dangerous Software Weaknesses

#129

Post by gavinhoward »

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.

Absolutely. I enable Valgrind on every default debug build of mine. It's my favorite tool.

I have even made it recognize my custom allocators and report bugs with them too.

When combined with my second favorite tool, AFL++, I have a good shot at eliminating most memory bugs. AFL++ finds paths through the software, and I run every single one of those paths through Valgrind. It's beautiful.

Re: CWE Top Most Dangerous Software Weaknesses

#130

Post by jerf »

tumdum_ wrote: post #113
jerf wrote: post #78

Earlier quoted context omitted.

This isn't about choosing security measures from a menu. This is about the foundations of what you build. To the extent that memory safety is slowly, oh so slowly, but steadily dropping down the list, it is because we are taking it seriously as a foundational issue and actually addressing it. To turn around and then use the success we've had as evidence that it isn't important is making a serious error. There is no r…

> There is no reason to use a memory unsafe language anymore, except legacy codebases, and that is also slowly but surely diminishing. I'm still yet to hear this amazingly compelling reason that you just need memory unsafe languages. In terms of cost/benefits analysis, memory unsafety is literally all costs. Tell that to the authors of new memory unsafe languages (like Zig) and creators of new projects in those langu…

I do tell them that. I see no reason to be memory unsafe.

It is a huge uphill battle to become a new general purpose language, and the smallest thing can kill it. The fact that Zig is memory unsafe means that I, who am not a bleeding-edge adopter, but am an early adopter and in a position to make decisions about what is used at work, have disqualified it and lost all interest. I have no use for such a language for greenfield projects. Simply offering a more convenient onramp to the sorts of problems that C has is not a compelling value proposition for me.

I extremely strongly suspect I am not even remotely alone.

Post reply on HN