Honest question - why do people use Chrome? It’s from an arguably as-evil company as Facebook. Alternatives exist. What’s the draw?
[deleted]
Serious Chrome zero-day
221–230 of 377 posts
Re: Serious Chrome zero-day
#222> Like, seriously, update your Chrome installs… like right this minute.
If so serious, remove the 2 likes from the sentence.
Re: Serious Chrome zero-day
#223I'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.
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 language, separate syntax, generics that work differently than templates, different standard library, etc.
This interacts with the finite amount of time I have to learn a new language, making it take longer before I feel proficient enough in it to start using it for real work. Sufficiently long that the day that I do is still in the future.
I understand the desire to make changes. Many of the changes are improvements, and C++ can be ugly. But it's the devil we know. A version of it with the minimum necessary changes to add a borrow checker would have me using it already, and I expect I am not the only such person.
Re: Serious Chrome zero-day
#224Earlier quoted context omitted.
OK, but this bug isn't in jitcode.
I never said it was. I said it implicated JIT'd code and the complex GC subsystem. The context is a JavaScript ArrayBuffer, the very type of object that JIT engines are built to optimize access to, and thus it's reasonable to infer that there may be some sort of cross-runtime scoping aspect at play. Such code by definition not only bypasses language protections, most relevant to this case it implicates interfaces tha…
To be clear, regarding my rant about WebAssembly, it would be nice to see a WASM specification that permitted, for example, pluggable WebAssembly engines. Though performance may limit it's popularity, I'd like the choice to use an engine written entirely in a language like Rust or ATS. Many people here would use it, and it would add a useful competitive dimension that emphasizes security. Also, as I previously mentioned, such an interface could limit the risk of introducing and the scope of dangerous cross-subsystem dependencies invisible to host languages and which result in memory issues.
But that can never happen if the WASM specification insists on semantics that all but require tight integration with the browsers' JavaScript engine and GC.
Re: Serious Chrome zero-day
#225Honest question - why do people use Chrome? It’s from an arguably as-evil company as Facebook. Alternatives exist. What’s the draw?
I’d like to use Firefox, but their lack of AppleScript supports makes that unfeasible. I could get past its atrocious performance, but not past a missing feature I require multiple times a day. I don’t use Safari because it lacks other features. I can’t disable JavaScript on a per-site basis, and the content blockers are a joke compared to uBlock Origin. Most other browsers are Chromium based, so might as well use Ch…
What do you do that requires AppleScript support?
Re: Serious Chrome zero-day
#226Earlier quoted context omitted.
OK, but this bug isn't in jitcode.
I never said it was. I said it implicated JIT'd code and the complex GC subsystem. The context is a JavaScript ArrayBuffer, the very type of object that JIT engines are built to optimize access to, and thus it's reasonable to infer that there may be some sort of cross-runtime scoping aspect at play. Such code by definition not only bypasses language protections, most relevant to this case it implicates interfaces tha…
Yes, there has to be some unsafe glue code somewhere. So what? You write it once and wrap it in a safe interface (there are at least three relevant options in the crate ecosystem that I mentioned). That way, programmers who hack on FileBuffer don't have to worry about introducing zero-days like this.
This is not feasible in C++, because the language isn't safe to begin with.
Re: Serious Chrome zero-day
#227This 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?
no, I want to abbr I use v, and a for att.
Re: Serious Chrome zero-day
#228This is a blog post that seems to just be reporting on this tweet: https://twitter.com/justinschuh/status/1103087046661267456 which in turn is referencing this new release from this past Friday: https://chromereleases.googleblog.com/2019/03/stable-channel... which seems to have been motivated by "CVE-2019-5786: Use-after-free in FileReader. Reported by Clement Lecigne of Google's Threat Analysis Group on 2019-02-27".…
And here we have a great example of an obvious, uh, violation of this HN guideline:
> Please submit the original source. If a post reports on something found on another site, submit the latter.
Clickbait blogspam, right to the top! Nice work HN!
Re: Serious Chrome zero-day
#229I'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. 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.
Re: Serious Chrome zero-day
#230Earlier quoted context omitted.
> What I'm saying is that Chrome is an example of a project with more security funding than just about any other project out there, and it still can't save users from the footguns of C++. You can certainly make that argument but this doesn't seem to really be a compelling example. They had one security issue caused by a use-after-free over a decade. That's... a pretty fucking stellar track record and does not at all…
This is not the first chrome security issue in over a decade.
There was even another UAF just a few months ago. https://chromereleases.googleblog.com/2018/11/stable-channel...