Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serious Chrome zero-day

nakedsecurity.sophos.com

Post reply on HN
Print view View original

291–300 of 377 posts

Re: Serious Chrome zero-day

#291

Post by chriswarbo »

sanxiyn wrote: post #243
Grue3 wrote: post #238

Earlier quoted context omitted.

The real problem is that the web is now too complex to the point that it's impossible to safely implement it. And W3C keeps trying to add new features to it. At some point we have to stop and consider whether all this cruft is even necessary.

Of course all the cruft is necessary due to compatibility. (Browsers monitor usage statistics and do remove crufts when possible.)

"Polyfills" are quite common in Web development, and are also proof that browsers do a whole bunch of unneeded stuff (if it were needed, there would be no way to polyfill it).

I actually think polyfill usage is backwards: the current approach allows code targetting new features to be made compatible with old browsers, by the site providing polyfills.

I think it's much better for new browsers to be leaner, simpler and more well-thought-out than their predecessors. Such browsers can provide polyfills to allow compatibility with code targetting old features that have been dropped.

In other words, browsers should be getting smaller (e.g. a canvas, audio stream, input method and language interpreter); more and more functionality should be offloaded into interpreted libraries (parsing, text rendering, DOM, event loops, layout, Javascript, etc.)

Re: Serious Chrome zero-day

#292

Post by detaro »

chriswarbo wrote: post #291
sanxiyn wrote: post #243

Earlier quoted context omitted.

Of course all the cruft is necessary due to compatibility. (Browsers monitor usage statistics and do remove crufts when possible.)

"Polyfills" are quite common in Web development, and are also proof that browsers do a whole bunch of unneeded stuff (if it were needed, there would be no way to polyfill it). I actually think polyfill usage is backwards: the current approach allows code targetting new features to be made compatible with old browsers, by the site providing polyfills. I think it's much better for new browsers to be leaner, simpler and…

Polyfills often are worse (slower, only provide parts of the functionality, ...) than the native implementation provided by newer browsers, so the browser implementation isn't strictly "unneeded".

Re: Serious Chrome zero-day

#293

Post by sureaboutthis »

pjmlp wrote: post #290
sureaboutthis wrote: post #288

Earlier quoted context omitted.

And almost every operating system in the world is written in C by top developers who are in the know. If there was a better way, everyone would do it, but they don't. Let's quit pretending that any software written in any other language would be more secure and have less bugs.

Let stop hand waving C security exploits caused by top developers, in spite of best practices. C only got outside UNIX in the mid-90's. Its ubiquity is an historical accident, by no means permanent, and thankfully some vendors are finally walking away from it, as proven by Microsoft security advisor for future Windows development best practices.

I'm pretty sure C was pretty well thought out and wasn't used by accident in any way. After almost 50 years of usage, I'm not sure we can say it's "by no means permanent" either.

Re: Serious Chrome zero-day

#294

Post by Eldt »

sureaboutthis wrote: post #288
pjmlp wrote: post #246

Earlier quoted context omitted.

Linux is another good example how C doesn't cut it, even among top developers. They have a very strict patch review process in place. They have kernel static analysers. The kernel has been adding security gates through the years. Yet 68% of 2018 CVE's were caused by memory corruption bugs, with the others ones left out being UB, numeric conversions, and very tiny fraction remaining of the logic error kind that are bo…

And almost every operating system in the world is written in C by top developers who are in the know. If there was a better way, everyone would do it, but they don't. Let's quit pretending that any software written in any other language would be more secure and have less bugs.

Humans are fallible. Relying on them to make the same safety decisions afforded by languages such as Rust is asinine.

Re: Serious Chrome zero-day

#295

Post by tha_nose »

staticassertion wrote: post #77

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…

There isn't a "safe or bug free" codebase in any language for any complex software project. The only code that you could possibly verify as "safe" are simplest of programs.

There is always a trade-off between complexity, security and performance.

Re: Serious Chrome zero-day

#296

Post by chriswarbo »

a13n wrote: post #274
staticassertion wrote: post #77

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. Well, humans can't. And computers can't, yet.

> And computers can't, yet.

Yes they can. Computers have been writing safe code in various languages for decades: they're called compilers/transpilers. Maybe this is one of those situations where we define AI as "things we don't know how to program yet": we said being good at chess would require intelligence, once computers got good at chess they became 'just tree search'. It sounds like you're imagining that automating programming requires some currently-unknown approach, when others would say it's 'just compiling'.

Of course, we need to tell the computer what code to write. We do that using a programming language.

It could be the same language (C++), but that seems a bit pointless. Furthermore, since C++ allows unsafe code, using C++ to tell the computer what we want means that we're able to ask for unsafe things (if we want to). That makes the computer's job ambiguous:

- Should it always do what it's told, and hence write unsafe code when asked? (In which case, it doesn't solve the "write safe code" task we're talking about)

- Should it always write safe code, and hence not always do what it's told? (In which case, where do we draw the line? Would it be valid to ignore all input and always write out `int main() { return 0; }`?)

We can avoid this ambiguity if we forbid ourselves from asking for unsafe things. In other words, providing a guarantee about the code that the computer writes is the same as providing that guarantee for the instructions we give it (i.e. the input programming language).

For example, if we don't want the computer to ever write memory-unsafe code, that's the same as saying we can't ever tell it to write memory-unsafe code, which is the same as saying that we should instruct it using a memory-safe language.

That way, it's possible for a computer to not only write safe C++ in a codebase of arbitrary complexity; but (more importantly) to write safe C++ code that does something we want, and the instructions specifying what we want can be arbitrarily complex.

Re: Serious Chrome zero-day

#297

Post by chriswarbo »

zrm wrote: post #223
staticassertion wrote: post #77

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

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

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

What you say would make sense if Rust were based on C++. I've never heard anyone say that.

I was under the impression that Rust is a derivative of ML, and (to me, at least) it looks very much like StandardML or OCaml with a borrow checker.

(I don't know C++, so I can't personally comment on how similar or different it is from Rust)

Re: Serious Chrome zero-day

#298

Post by sciurus »

staticassertion wrote: post #77

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…

"Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security."

Let's conservatively say Google pays 1,000 developers to work on Chrome, and on average those developers cost Google $300k each. That's $300 million a year just in payroll. Google has invested far more than a billion in Chrome by this point.

Re: Serious Chrome zero-day

#299

Post by tapoxi »

neoromantique wrote: post #284
blub wrote: post #279

Earlier quoted context omitted.

Your claim that Chrome can be used a lesson in choosing programming languages is quite weak, because almost no one will build such a complex application and despite the risk all successful browsers still chose C++. An application that: a) has downloading and executing untrusted code as its main feature b) supports a ton of media formats, with DRM to boot c) is going through rapid changes, including adding very comple…

>Firefox is the only odd one out, slowly but surely sliding into irrelevance. That is very false.

The highest number I've seen for Firefox's marketshare is 5.8%, which is Wikipedia's metrics: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Su...

Re: Serious Chrome zero-day

#300

Post by SamBam »

sciurus wrote: post #298
staticassertion wrote: post #77

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…

"Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security." Let's conservatively say Google pays 1,000 developers to work on Chrome, and on average those developers cost Google $300k each. That's $300 million a year just in payroll. Google has invested far more than a billion in Chrome by this point.

I'm amazed. Are there really, "conservatively," 1000 developers working on Chrome full-time, for years? That seems incredibly high to me, but maybe I just don't realize what it takes to build an app like Chrome.
Post reply on HN