Live data from Hacker News

Serious Chrome zero-day

nakedsecurity.sophos.com

81–90 of 377 posts

Re: Serious Chrome zero-day

#81
This looks bad for Google. EdgeSpot detected an in-the-wild exploit and told Google about this in December, but Google wasn't going to fix the bug until late April.

Google only released a patch early because the finder blogged about it.

https://blog.edgespot.io/2019/02/edgespot-detects-pdf-zero-d...

Re: Serious Chrome zero-day

#82

I'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…

So what language should they've written it in?

Re: Serious Chrome zero-day

#83
post #18
post #3

What does this mean for Electron Apps?

If the Electron app never shows untrusted HTML with Javascript enabled, then it's not an issue. Generally, only Electron apps with arbitrary web browsing functionality would do that.

The thing seems to be linked to FileReader. Maybe just linking to an external image is enough.

Re: Serious Chrome zero-day

#84

I'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…

No codebase will ever be fully free of security bugs, but having 7 million lines of code definitely doesn't help.

Re: Serious Chrome zero-day

#85
post #82

I'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…

So what language should they've written it in?

[deleted]

Re: Serious Chrome zero-day

#86
post #82

I'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…

So what language should they've written it in?

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 language.

Re: Serious Chrome zero-day

#87
post #82

I'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…

So what language should they've written it in?

Use-after-free is ruled out by e.g. Rust's type system

Re: Serious Chrome zero-day

#88

I'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.

Do they distrust their own coders to the same degree they distrust the processes they sandbox? I suspect the answer to this is "no" but I would like to hear from someone who actually codes there.

I think the truth is more like this: You can write safe C++, just like you can keep a secret. It's just that the odds that you fail go up with the size of the team involved, and it does that by compounding. So by the time you get to the size of the Google Chrome team, the odds of failure are very, very close to 1.

Re: Serious Chrome zero-day

#89

Earlier quoted context omitted.

I used it because it was fast, now I use Brave and it is fast and private.

Brave is based on Chromium and has a recent update.

These faster release cycles haven’t been around since sandboxing was implemented but it feels strange when browsers are allowing known security holes to be around. It doesn’t seem like they are trying to patch many other bugs.

Re: Serious Chrome zero-day

#90

This looks bad for Google. EdgeSpot detected an in-the-wild exploit and told Google about this in December, but Google wasn't going to fix the bug until late April. Google only released a patch early because the finder blogged about it. https://blog.edgespot.io/2019/02/edgespot-detects-pdf-zero-d...

[deleted]
Post reply on HN