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

141–150 of 377 posts

Re: Serious Chrome zero-day

#141

Post by pcwalton »

nitwit005 wrote: post #140
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…

In a general sense, I'd agree, but from the description in that article, it's interaction with native files or file dialogs. Even if you use Java, you're susceptible to this sort of bug, because your Java code calls into layer of C code to handle the native interaction. Realistically, any browser is probably going to have a decent amount of unsafe code surrounding the native windowing, files, graphics, and so on.

Look at the patch; it's a use-after-free bug involving DOMArrayBuffer and ArrayBuffer, which are Chrome objects, not native OS objects.

Re: Serious Chrome zero-day

#142

Post by kllrnohj »

pcwalton wrote: post #135
bla3 wrote: post #124

Earlier quoted context omitted.

If there's ever a project as large as Chrome written in a non-C++ language, I guarantee you it will have these bugs as well -- due to use of `unsafe`, or bugs in the compiler, or what have you.

How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. †I explicitly say "not running arbitrary Java code" to emphasize the difference between this scenario and JS engine vulnerabilities. JS engine vulnerabilities are a problem because JS engines execute untrusted code, but I'm talking about compiler bugs in t…

> How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one.

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?

But in terms of Java runtime's security it's not particularly stellar. The entire category of "Java deserialization" is the never ending fountain of remotely exploitable security bugs in Java apps that don't run untrusted code.

Re: Serious Chrome zero-day

#143

Post by stcredzero »

Johnny555 wrote: post #129
nothrabannosir wrote: post #106

Earlier quoted context omitted.

The number of people required was a function of the "this complex" qualifier. I can write a safe C++ app on my own. I can't write Chrome on my own.

I can write a safe C++ app on my own But only if you don't use any external libraries, once you link in someone else's code, you can no longer be sure your program is "safe".

once you link in someone else's code, you can no longer be sure your program is "safe"

This also fits in with the "keeping a secret" analogy. Good luck keeping something secret, if it has to be shared between organizations.

Re: Serious Chrome zero-day

#144

Post by Roboprog »

doctorpangloss wrote: post #107
staticassertion wrote: post #86

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

Their egos have priced them out of a lot of stuff though. The Chrome team is great but when you're surrounded by people who think they're god damn gods on Earth it's hard to question orthodoxies, especially old ones.

As trollish as that sounds, there's a painful amount of truth there.

Program in GNU Pascal or some such thing? Not us. Pedal to the metal!

Re: Serious Chrome zero-day

#145

Post by Jach »

NeoBasilisk wrote: post #68
tcbasche wrote: post #31

Earlier quoted context omitted.

I gave Firefox an honest go, but some web apps just don't work 100% in it. Chrome does not have this issue. Most of us drive cars filled with fuel from evil oil companies, why do we all drive cars?

Is the stuff not working in Firefox due to lazy devs too young to remember IE6?

It's partly that, but it's also partly that the pace at which new standards of useful things get implemented (pre-ratification and post ratification) entails patchy support plus differing implementation decisions from under-specified standards. My favorite example area right now is all the fun that is CSP. Firefox supports the SecurityPolicyViolation Event, which is useful so that you can let non-power users know about CSP issues without having to open the console, except it's gated by a setting in about:config that is off by default. Additionally for CSP's report-uri endpoint, Firefox won't send up any cookies with a request to that endpoint (https://bugzilla.mozilla.org/show_bug.cgi?id=1506992) which sucks if the endpoint relied on authentication that way. Chrome just works, meanwhile, on both of these issues. (Of course personally, if something doesn't work in Firefox, then I just don't use that something, or if I really need to (e.g. test business feature), I use chromium for just that one thing.)

Re: Serious Chrome zero-day

#146

Post by kllrnohj »

staticassertion wrote: post #132
kllrnohj wrote: post #128

Earlier quoted context omitted.

Sure, but is your goal maximal safety no matter the cost, or are you trying to strike a balance with other factors? If all you want is to keep users safe then it'd be easy - ban JavaScript wholesale. Bam, done, instantly made the web safer & faster. Don't even need to deal with the huge security can of worms that is WebGL, either. But safety is rarely the exclusive factor in play, now is it? Things like memory usage…

To be clear, I'm not saying "Chrome should be rewritten in a memory safe language", I'm saying that Chrome is an excellent project to point to, say "Wow, no one does as much to secure a codebase as them", and to follow that up with "and they still got owned".

But to what end? Pure-java apps get owned all the time, too. If you look over there you'd just give up on ever trying to transmit data, as the number of Java de-serialization exploits is nothing short of stunning.

The only semi-proven way to not get owned at this point is to never go online.

Re: Serious Chrome zero-day

#147

Post by pcwalton »

kllrnohj wrote: post #142
pcwalton wrote: post #135

Earlier quoted context omitted.

How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. †I explicitly say "not running arbitrary Java code" to emphasize the difference between this scenario and JS engine vulnerabilities. JS engine vulnerabilities are a problem because JS engines execute untrusted code, but I'm talking about compiler bugs in t…

> How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. 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? But in terms of Java runtime's security it's not part…

> 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 category of "Java deserialization" is the never ending fountain of remotely exploitable security bugs in Java apps that don't run untrusted code.

Java deserialization RCEs, while pernicious, are nowhere near as common as use-after-free and related bugs in C++ code. Furthermore, you can effectively mitigate them by statically banning OutputObjectStream and whatnot. There's no such easy foolproof static mitigation available for C++ UAF.

Re: Serious Chrome zero-day

#148

Post by beefsack »

kllrnohj wrote: post #142
pcwalton wrote: post #135

Earlier quoted context omitted.

How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. †I explicitly say "not running arbitrary Java code" to emphasize the difference between this scenario and JS engine vulnerabilities. JS engine vulnerabilities are a problem because JS engines execute untrusted code, but I'm talking about compiler bugs in t…

> How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. 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? But in terms of Java runtime's security it's not part…

Here's a specific example for a C++ compiler: CVE-2019-0546

I have a feeling you could find Java ones too if you looked hard enough. Compilers are complex beasts.

[1]: https://nvd.nist.gov/vuln/detail/CVE-2019-0546

Re: Serious Chrome zero-day

#149

Post by pcwalton »

beefsack wrote: post #148
kllrnohj wrote: post #142

Earlier quoted context omitted.

> How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. 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? But in terms of Java runtime's security it's not part…

Here's a specific example for a C++ compiler: CVE-2019-0546 I have a feeling you could find Java ones too if you looked hard enough. Compilers are complex beasts. [1]: https://nvd.nist.gov/vuln/detail/CVE-2019-0546

That seems to be this one: https://www.thezdi.com/blog/2019/2/28/finding-unicorns-when-...

It's a straightforward miscompilation. I'm not sure why they even classify it as a vulnerability.

From Microsoft, per the article: "The said vulnerability is about downloading and running untrusted code, which has always existed in all releases prior VS2017 Update 9 that supported lambdas. The scenario is not common coding practice and considering we've always had this in all our prior releases and have not seen any evidences of exploit it would not make sense to port the change as hotfix from 15.9 to prior VS releases."

In other words, it's never made into a product in an exploitable way. I'd just call this a miscompilation.

Post reply on HN