At $work, the standard solution to ASAN reporting use-after-free issues is to... not run ASAN builds. The fact that builds in CI exhibit random inexplicable crashes regularly every week doesn’t seem to make anyone have any second thoughts. A colleague once claimed that there is nothing wrong with out-of-bounds accesses as long as we don’t crash. The same bunch is also religiously opposed to using debuggers and regularly break debugger builds by removing debug information from builds at multiple levels, blocking ptrace debugging in system images through sysctl... This is all so toxic.
> A colleague once claimed that there is nothing wrong with out-of-bounds accesses as long as we don’t crash.
I need to find the source, but someone pointed out that the safety advantages of Rust are, in part, cultural and I increasingly agree. People use Rust because they care about memory safety and that care is reflected in the programs they write.
The optimist in me would like to delude themselves thinking that most of the people smart/experienced enough to make the jump to unique_ptr from new/delete realized this is closing a porthole on the titanic and made the jump to something that isn’t C++.
I am not sure. C++ is a tool. I use what my company and companies in my domain use. I wouldn't mind using Rust, but there's just very little momentum. So meanwhile I do my best with what we have.
Personally, I care more about what I do than which tool I am using.
Rust is not the only thing that “isn’t C++”. Go is not appropriate for every domain either but you can bet your bottom dollar that it has taken market share from C++ - which I think the world is on the overall balance better off for, and I don’t particularly like Go as a language.
Someone is making gobs of money off of OCaml.
> I care more about what I do than which tool I am using.
I don’t agree with the implication that these are independent factors.
And I do get it. The Rust ecosystem founders in many areas and the RIIR meme crew on forums is annoying. That doesn’t forgive the failings of the C++ ecosystem.
My personal opinion is that if companies would get real punishments for all of these goddamn security breaches, and the CTO's head was on the line, you'd see a shift in attitude real quick.
This in fact happened to Cloudflare with Cloudbleed and their decision was to switch to Rust.
There is a human factor at work here. Rationally speaking, Herb is right 98% reduction is sufficient. But when the CTO's head is on the line, they won't listen and switch to Rust.
Not all pieces of software are created equal. A desktop CAD application that doesn't do any networking and doesn't manipulate sensitive user data isn't worthy of binary exploitation. If there is adequate security at the system OS layer, at worst it will corrupt a user's file.
Infrastructure network code that runs on millions of servers worldwide is a completely different story. Being able to send a sequence of bytes that unlocks funny side-effects of a network service can be weaponised on a mass scale.
> Not all pieces of software are created equal. A desktop CAD application that doesn't do any networking and doesn't manipulate sensitive user data isn't worthy of binary exploitation. If there is adequate security at the system OS layer, at worst it will corrupt a user's file.
That software is almost certainly running on a network-connected machine though and likely has email access etc.. A spear-phising attack with a CAD file that contains an RCE exploit would be an excellent way to compromise that user and machine leading to attacks like industrial espionage, ransomwear, etc...
If you've fallen victim to phishing you're hosed anyway as a malicious process can read and write to the address space of another process, see /proc/$pid/mem, WriteProcessMemory(), etc.
There's a spread of things that can happen in phishing; I would expect that it's a lot harder to get a user to run an actual executable outright than to open a "data" file that makes a trusted application become malicious.
In order to read or write /proc/pid/mem your process needs to be allowed to ptrace() the target process. You can’t do that for arbitrary processes. Similar story for WriteProcessMemory().
Above your security context, no, but you can definitely WriteProcessMemory any other process that is in your same security context or lower (something similar holds for ptrace, although remember that SUID/SGID binaries are running not at a same security context)
Those are increasingly rare. Nowadays you have all these apps requiring subscriptions and expecting users to login and what not.
But I agree it depends heavily on exactly what application are we talking about. Is it running on server? Definitely needs to be security conscious. Is it a library that might at some point be used by an application running on a server? Needs to be more hardened than a nuclear bunker.
They are all pieces to a puzzle. If you can add or modify a CAD file to a location a user of the desktop software will access, a defect in file parsing could provide user level remote access to you. Then if any other application or library has a privilege escalation, you have rooted the box. And even if there is no privilege escalation on that box, how many more CAD files can that user modify to spread the remote access?
You're assuming they have security breaches due to C++.
I'm betting here they don't; if they have security breaches it's due to '1q2w3e' being the password to their world-accessible PHP admin panel, and not because of C++ code.
Using C++ doesn’t mean you must have security issues. It means that you have to do more things right in your other work to avoid them, and we have several decades of experience showing that even very good teams struggle with that. The more separate concerns teams need to manage, the more likely it is that someone will make a mistake with one of them – and since time is finite, the attention spent on memory management is taking away time which could be spent on other classes of error.
For every 1 security breach due to C++ memory management, there are at least 100000 due to shitty PHP code that doesn't escape strings or uses plaintext passwords that never change. (This is a conservative estimate.)
Can you cite your sources on that analysis? Be sure to include the relative affected numbers so we don’t count an exploit in Chrome the same as a PHP exploit affecting a dozen people using someone’s obscure WordPress plugin.
Another way of thinking about this, why are all of the browser teams who have some of the best C++ developers in the world and significant resources adopting memory-safe languages? Nobody at that level is doing that because it’s cool, so there might be something to be learned from their reasoning.
PHP (the language) has long since moved past awful practices like that, and we can definitely tell people to stop doing that and use the provided safe alternatives instead. In fact, the PHP docs do just that. PHP is no longer to blame here.
Also that number is greatly exaggerated. It's simply not true anymore, check the CVE website if you don't believe me.
