Why is this blogspam with no information upvoted in the first place? Does anyone enjoy reading this?
Serious Chrome zero-day
261–270 of 377 posts
Re: Serious Chrome zero-day
#262I'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…
Is there an official explanation of the kind of bug? I cannot find it.
"Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex."
Pointing the finger and saying "see?" is a pretty low quality argument.
So, I guess we should wait for the first Rust or managed language remote exploit (or whatever) to say "admit it, finally - you can't write safe... programs?".
Re: Serious Chrome zero-day
#263Oh man.. Am I the only person who has been neglecting that little red arrow icon in Chrome for the past few days?!
I'll take some blame, but it would be great if Chrome popped up a blocking message that said "UPDATE NOW, DAY ZERO IS UPON THEE!!!!"
Re: Serious Chrome zero-day
#264Honest question - why do people use Chrome? It’s from an arguably as-evil company as Facebook. Alternatives exist. What’s the draw?
i've tried firefox, and chrome is simply faster in what i've experienced. I've tried the newer firefox too.
Having my privacy stolen? The moment they do something malicious with the data they have, they are dead. I trust them with my data because I know how the world works. Facebook is so much more dangerous as far as privacy is concerned
Re: Serious Chrome zero-day
#265I'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…
> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. I work on Chrome. The working assumption is there always exists a bug that allows remote code execution in the renderer.
Bad time to ask for browser extensions on mobile then?
Re: Serious Chrome zero-day
#266I'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…
Isn't it more a case of "you have to do everything right to keep the attackers out, they have millions of attempts and only have to get one right once to beat you".
Re: Serious Chrome zero-day
#267Just quit and restart Chrome. No need to fight with an link you can’t click.
Re: Serious Chrome zero-day
#268Earlier 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.
UAF are the most common, and the most commonly exploited kind of security bugs in Microsoft products for the last decade [1]. And Microsoft products are way more C++ than C.
[1] https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
Re: Serious Chrome zero-day
#269Earlier quoted context omitted.
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".
I assume it is 0day irrespective of who discovered it. It remains 0day until an action is taken to mitigate it. So you have 0day exploits being traded on various markets - those are exploits which are known to certain groups, but the affected party hasn't yet taken action to mitigate them (most likely because they don't know).
Re: Serious Chrome zero-day
#270Earlier quoted context omitted.
UAF by whom? If it's through a bare reference held in the JavaScript VM where operations don't access the C++ object as a C++ object or as some shared primitive object as in the JVM or CLR, then the error is in maintaining state consistency across distinct environments. Such bugs look exactly the same in every language, although the risk is compounded by (a) JIT'd environments and (b) asynchronous execution. In the c…
Can you provide an example of a dangling reference of any type (not just a UAF) being exploitable for RCE in a managed language like Java, Rust, or Go?
Yes, sure.
You write to a file, save the file name or file descriptor. Then when you read it back later, maybe you forget to validate the contents. This can be exploited depending on what you were doing with the data.
Do you now want to restrict what you mean by a 'reference'? You'll see that once you keep restricting that enough you first lose the ability to write fast programs and eventually useful programs(evidence: various 'unsafe' modes in so called safe languages).