Earlier quoted context omitted.
Can you use the STL? What boundary is considered trusted?
I can trust the compiler... I hope?
Not at all, check the Linux 5.0 bug introduced by a gcc "optimization" regarding UB.
Serious Chrome zero-day
251–260 of 377 posts
Re: Serious Chrome zero-day
#252Earlier quoted context omitted.
> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. And so, as they say, we should all be using Rust. But allow me to explain why I don't yet. Rust has one really outstanding feature -- a borrower checker that makes it memory safe. Adding that to C++ would be a compatibility-breaking change. So then, while they were at it, they changed lots of other things. It's a whole…
Different standard library is kind of unavoidable because you need standard library interface understood by borrow checker.
Microsoft already does that with their SAL annotations.
https://docs.microsoft.com/en-us/visualstudio/code-quality/u...
Which they are extending to also support their C++ lifetime checker.
Re: Serious Chrome zero-day
#253Earlier quoted context omitted.
A memory safe one. There are many of them. They could build their own if they chose to - they've built multiple languages in the past. Picking a language for the Chrome team doesn't seem practical - we all know where your question is going to head. The point is they have to not pick C++. Again, they've invested many, many millions of dollars into security. Let's not pretend that they're priced out of using another la…
Back when Chrome was getting started there were no memory safe languages that did not come with huge downsides. Now one could argue for Rust, but let's not pretend that C++ was a bad choice. C++ was the overwhelmingly best choice at the time.
I wonder what are the huge downsides of Modula-2, Ada, Delphi, ....
Re: Serious Chrome zero-day
#254This blog post is so watered down and manages to digress at every possible point that it is almost impossible to read. The only useful part of the text are the URLs. Also, this: > A vulnerability, or vuln for short, is a bug that makes software go wrong in a way that reduces computer security. Does anyone actually use this abbreviation?
As a security consultant, sure we do. But I'd never use it in a customer report or company blog post if I felt I needed to explain the abbreviation.
Re: Serious Chrome zero-day
#255Earlier quoted context omitted.
That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in…
> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.
Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go.
Android team also makes use of Go for their OpenGL/Vulkan debugger.
Now, lack of generics is really a big pain point.
Re: Serious Chrome zero-day
#256The vulnerability is in the browser’s code itself. If you have the stable channel for Chrome added into Linux, then you just have to run ‘sudo dnf update.’
Re: Serious Chrome zero-day
#257I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively . They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a wo…
if you think C or C++ programmers are ever going to admit this, you must never have met one
I was mainly a C and C++ developer until 2006 and you will see me praise C++, but also be an heavy critic of the copy-paste security exploits it inherited from C.
Re: Serious Chrome zero-day
#258I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively . They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a wo…
That's a weird and dishonest point to make here.
You can't write safe $ANYTHING for a codebase this complex. I am yet to see someone who has worked on a codebase this complex disagree. Security issues and crashes in general result from your program interacting with the outside world and something behaving in a way you did not account for.
Re: Serious Chrome zero-day
#259Earlier quoted context omitted.
I always thought it was from the patch date. As I understand it there are 1-days, and 2-days, where people rush to make exploits for released patches to capitalize on the lag time between patch availability and wide deployment (and also zero-days which were recently patched), which is why zero-day denotes that there has been no time since a patch is available (since there isn't one). So, I would say this was a zero-d…
You're both wrong for different reasons. 0day refers to vulnerabilities. t0 is when a vulnerability is discovered. t1 is either when the vendor issues a patch OR it is exploited and t2 is when >50% of vulnerable systems have applied the patch. tl;dr: something is 0day once it's discovered. It is no longer 0day once an action is taken with the vulnerability.
So it's possible that t1 < t0? Because something might had been exploited before whatever time is taken as the official "discovery date".
Re: Serious Chrome zero-day
#260Earlier quoted context omitted.
> Seems like an odd restriction to impose here. How many C++ exploitable bugs arose from a C++ compiler bug? I think the answer to that is also zero. Doesn't really seem like a useful thing to consider? Right, and that's why the fact that the Rust compiler has bugs is irrelevant. The language is meaningfully more memory-safe than C++. > But in terms of Java runtime's security it's not particularly stellar. The entire…
> Java deserialization RCEs, while pernicious, are nowhere near as common as use-after-free and related bugs in C++ code. Can you justify that? Actual exploits from Java deserialization RCEs are well known & published, but by contrast searching the CVE database reveals a rather small number for C++ or CPP. Use-after-free gets a large list, but the majority seem to be in C code not C++ code.
I'm not sure how you'd even search for those, because deserialisation doesn't have an exact, common equivalent in C land. There are almost no cases of arbitrary/named types being constructed from arbitrary inputs at runtime. You have to take into account the really low prior probability for the counts to make sense.