zlacker

I was with you until the parsing with memory unsafe languages. Isn’t that exactly the kind of “random security not based on a threat model” type comment you so rightly criticised in the first half of your comment?

>>blowsk+(OP)
Based on the hundreds, perhaps thousands of critical vulnerabilities that are due directly to parsing user input in memory-unsafe languages, usually resulting in remote code execution, how's this for a threat model: attacker can send crafted input that contains machine code that subsequently runs with the privileges of the process parsing the input. That's bad.

>>blowsk+(OP)
I mean, the threat model is that 1. Memory leaks/errors are bad 2. Programmers make those mistakes all the time 3. Using memory safe languages is cheap Therefore, 4. We should use memory safe languages more often

>>blowsk+(OP)
I think you must have misunderstood the point the parent comment was trying to make. Memory-safety issues are responsible for a majority of real-world vulnerabilities. They are probably the most prevalent extant threat in the entire software ecosystem.

>>blowsk+(OP)
There are very few threat models that a memory unsafe parser does not break.

Even the "unskilled attacker trying other people's vulns" threat basically depends on the existence of memory-safety related vulnerabilities.

>>blowsk+(OP)
The attack surface is the parser. The ability to access it is arbitrary. I can't build a threat model beyond that for any specific case, but in the case of a text messaging app I absolutely expect "attacker can text you" to be in your threat model.

>>kmeist+O5
Then we’re right back in the checklist mentality of “500 things secure apps never do”. I could talk to somebody else and they’d tell me the real threat to worry about is phishing or poor CI/CD or insecure passwords or whatever.

>>blowsk+yb
There is no "real threat". Definitely phishing is one of the top threats to an organization, left unmitigated. Thankfully, we now have unphishable 2FA, so you can mitigate it. When you choose to prioritize a threat is going to be a call you have to make as the owner of your company's security posture - maybe phishing is above memory safety for you, I can't say.

What I can say is that parsing untrusted data in C is very risky. I can't say it is more risky than phishing for you, or more risky than anything else. I lack the context to do so.

That said, a really easy solution might be to just not do that. Just like... don't parse untrusted input in C. If that's hard for you, so be it, again I lack context. But that's my general advice - don't do it.

>>static+Tc
In-arguable these days.

>>blowsk+(OP)
Add this language absolutism to the list of things we need to avoid.

>>lisper+p2
Buffer overflows are common in CVEs because it's the kind of thing programmers are very familiar with. But I'm pretty sure that in terms of real-world exploits things like SQL injection, cross-site scripting, authentication logic bugs, etc, are still far more common. Almost all of those are in bespoke, proprietary software. A Facebook XSS exploit doesn't get a CVE.

>>wahern+In
First Microsoft, then two different teams at Google, and then Mozilla, and then someone else, all found that roughly 70% of security vulnerabilities reported in their products are due to memory unsafety issues. That roughly that number keeps coming up across all of the biggest companies in our industry lends it some weight.

Here's the first Microsoft one: https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

And Chrome: https://www.zdnet.com/article/chrome-70-of-all-security-bugs...

>>stevek+to
Yes, I'm well aware of what the data says, as well as what the data is measuring--CVEs and bug reports in well-known C/C++/Java projects.

But not too long ago, before SaaS, social media, etc, displaced phpBB, WordPress, and other open source platforms, things like SQL injection reigned supreme even in the reported data. Back then CVEs more closely represented the state of deployed, forward-facing software. But now the bulk of this software is proprietary, bespoke, and opaque--literally and to vulnerability data collection and analysis.

How many of the large state-sponsored penetrations (i.e. the ones we're most likely to hear about) used buffer overflows? Some, like Stuxnet, but they're considered exceptionally complex; and even in Stuxnet buffer overflows were just one of several different classes of exploits chained together.

Bad attackers are usually pursuing sensitive, confidential data. Access to most data is protected by often poorly written logic in otherwise memory-safe languages.

>>lisper+p2
It may sound like I’m being snarky, but I’m not:

Aren’t users / social engineering make up the actual majority of real-world vulnerabilities, and pose the most prevalent extant threat in the entire software ecosystem?

>>IggleS+qu
A fair point, but that's not really a problem with the technology. (And I did hedge with "probably" :-)

>>wahern+dr
My understanding was that while some of these are about CVEs and such, not all are. Like my understanding was the Microsoft numbers are from across all products, proprietary and open source.

>>wahern+dr
> How many of the large state-sponsored penetrations (i.e. the ones we're most likely to hear about) used buffer overflows?

It really depends on the target. If you’re attacking a website, then sure, you’re more likely to find vulnerability classes like XSS that can exist in memory-safe code. When you’re talking about client-side exploits like the ones used by NSO Group, though, almost all of them use memory corruption vulnerabilities of some sort. (That doesn’t only include buffer overflows; use-after-free vulnerabilities seem to be the most common ones these days.)

>>IggleS+qu
Yes, but I think that within the context of discussing a memory safety vulnerability in a text messaging app it's reasonable to talk about memory safe parsers, no?

Beyond that, I've already addressed phishing at our company, it just didn't seem worth pointing out.

>>wahern+dr
The thing is, SQL injection and cross-site scripting are both trivial to defend against — at least compared to memory safety. It has a small surface area and most frameworks do help with it, or at least it is in their realm of possibility.

Preventing buffer overruns require language-level support.

>>wahern+dr
SQL Injection is a good lesson here. How is it mitigated effectively? By telling devs to write code carefully? No. It is mitigated by prepared statement libraries that are structurally resistant to SQL Injection. Similarly, "here are some static analysis tools - try your best to write safe C" is not a winning move.

>>blowsk+(OP)
The threat-model there is that the attacker controls the text that is parsed.