71–80 of 131 posts
Earlier quoted context omitted.
Since 1979 with the invention of lint by Stephen Johnson at Bell Labs. https://en.wikipedia.org/wiki/Lint_(software)
Static analysis as a bugfinding tool has proven to be insufficient, especially for large C++ binaries and JS programs. Both languages are nightmares for precise and scalable analysis. Coverity exists. They've got a great product. But it doesn't solve the problem.
Earlier quoted context omitted.
How many of these rust can solve? (Not in use rust for everything bandwagon, genuinely curious)
2 of the 4 listed.
However, existing libraries for statically-typed languages often don't do the work or apply the creativity and end up roughly as unsafe as the dynamically typed languages.
It's a bit of a pet peeve of mine.
Earlier quoted context omitted.
Then ask yourself: how much have you done to prevent people choosing the wrong programming language? Because the PL has such a major influence, it's by far the most low hanging fruit to tackle those many of those issues.
Personally? I've done quite a bit here although there's always more. I worked at Google to fund Rust development internally and externally, helped sponsor the work that eventually led to getting Rust adopted in the Linux kernel, and now run a company that's building a new Linux distribution that prioritizes shipping code written in memory safe languages. https://security.googleblog.com/2021/02/mitigating-memory-sa...…
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
for 1 scan all the code base and warn any use of strcpy/strncpy/etc and replace them with snprintf, no APIs without length argument shall be allowed. for 4 the static analyzer should help, and, also set your pointer to NULL immediately after free too(for double free)
Changing everything to take lengths is definitely a good change - but challenging to retrofit into existing codebases. Apple has a neat idea for automatically passing lengths along via compilation changes rather than source changes, but if you want to do things in source you have to deal with the fact that there is some function somewhere that takes a void*, increments it locally, reinterpret_casts it to some type, and then accesses one of its fields and you've got a fucking mess of a refactor on your hands.
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…
No, IMHO escaping is an elegantly simple concept; it's just that for some reason (like basic arithmetic) people don't seem to be taught enough about it to understand. Two visually identical file names may map to different files (because confusables[1]), or two different names map to the same file (because normalization[2]), or the ".jpg" at the end may not actually be the extension (because right-to-left override[3])…
> it's just that for some reason (like basic arithmetic) people don't seem to be taught enough about it to understand.
That's the same argument used to defend manual memory management. But education is not enough. Escaping is something you have to remember to do every time*, or it'll blow up spectacularly. Even knowledgeable professionals mess it up, or it wouldn't occupy 6 of the 25 spots in this list.
> Those are all because of Unicode, which is an even worse idea in general.
What's the alternative? Japanese speakers writing file names in ASCII? Unicode is a modern marvel, it's our fault we use it where it doesn't belong.
* Not necessarily every input/output, but at least every system that interacts with it.
Earlier quoted context omitted.
It's somewhat disheartening as a security enthusiast that people only focus on "popular" security bugs and ignore the rest. The other top 21 bug classes aren't as "cool" but they will let me hack your app just the same.
Sure, but SQL Injection will let a script kiddie steal and/or drop your entire poorly configured production DB.
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.
But it is embarrassing that we've been living with memory safety issues for 50 years and they still remain very common and very severe, despite being addressable via type systems in ways that something like a logical bug that leads to data leakage isn't.
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.
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 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. Even if you do have one of the rare cases when you need it, and you only need a very particular variant of it (reading bytes in memory of one type as bytes of another type, you never need to write out of the scope of an array or dereference into an unallocated memory page), you can still get it through explicit unsafe support that every language has one way or another. You do not need a language that is pervasively unsafe with every line you write so that on those three lines of code out of millions that you actually need it, you can have it with slightly less ceremony. That's just a mind-blowingly bad tradeoff and engineering decision.
How are we supposed to address the other issues from a foundation of a memory unsafe language? If we can't even have such a basic guarantee, we sure aren't going to get more complicated ones later.
Earlier quoted context omitted.
> and actually knowing, on code level, how it manifests and how you avoid these things You avoid them by using tools that make it difficult or impossible to introduce such vulnerabilities to begin with. Such as modern, memory safe programming languages. For many decades, carpenters have been educated about table saw safety. But what finally stopped thousands of fingers getting chopped off every year was the introduct…
Memory safety won't stop you writing SQL queries or dynamically generating HTML that accepts unsanitised user input.
Earlier quoted context omitted.
Static analysis as a bugfinding tool has proven to be insufficient, especially for large C++ binaries and JS programs. Both languages are nightmares for precise and scalable analysis. Coverity exists. They've got a great product. But it doesn't solve the problem.
It doesn't solve everything, it solves even less when it isn't used.
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.