
Serious Chrome zero-day - LinuxBender
https://nakedsecurity.sophos.com/2019/03/06/serious-chrome-zero-day-google-says-update-right-this-minute/
======
staticassertion
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 world class bounty program.

They have a world class research team for finding vulns.

They invent or otherwise aggressively adopt mitigation techniques.

But someone out there did it.

Their track record for security is something to really be proud of - this is
the first public ITW exploit of its type that I am aware of. But users are
getting owned because of, at the very least, a Use After Free vulnerability.

Let's just collectively admit it, finally - you can't write safe C++ in a
codebase this complex.

edit: (From a post below)

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 by UAF".

~~~
elorant
So what language should they've written it in?

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

~~~
kllrnohj
Back when Chrome was getting started there were no memory safe languages that
did not come with _huge_ downsides.

Now one could argue for Rust, but let's not pretend that C++ was a bad choice.
C++ was the overwhelmingly best choice at the time.

~~~
naikrovek
That doesn't mean that they (or anyone) should still be using it.

The choice of language 15 years ago has nothing to do with the languages that
could be in use today on the same project.

Rust has `unsafe` all over the place; it's no more safe if you use that
keyword to do the same things that are done in C++.

Get more compiler people on Go and it will be even faster than it is now
(really fast), and Go is written in Go so there's no reliance on C++, unlike
Rust.

~~~
pcwalton
> Rust has `unsafe` all over the place; it's no more safe if you use that
> keyword to do the same things that are done in C++.

Yes, it is, because the language has the concept of safe code to begin with.
The problem with C++ is that all C++ code could potentially be unsafe.

> Get more compiler people on Go and it will be even faster than it is now
> (really fast), and Go is written in Go so there's no reliance on C++, unlike
> Rust.

This is a very confused comment. Rust is also written in Rust. If you're
thinking of LLVM, sure, the Rust _compiler_ uses that, but LLVM is nowhere to
be found in products written in Rust that are shipped to users. What matters
is how safe the runtime is, and there's no real difference between Go and Rust
in this regard. Go might theoretically have some kind of edge over Rust in
safety in that it calls syscalls directly instead of going through libc, but I
highly doubt it matters in practice, because (a) the libc wrappers are a drop
in the bucket compared to the complexity of the kernel; (b) Go only does that
on Linux these days anyhow.

~~~
piano
Yup, and besides, Go has the unsafe
([https://golang.org/pkg/unsafe/](https://golang.org/pkg/unsafe/)) package,
which allows for basically the same sort of unsafety as Rust's unsafe.

In fact, I would say Rust is typically more safe than Go, because in Rust you
can mark any code as unsafe, it doesn't necessarily have to involve unsafe
pointers. For example in Rust FFI functions are typically marked unsafe even
if they don't involve pointers. There's no way to do that in Go.

Another example is strings: Rust ensures that strings are always valid UTF-8
by marking any function that could break that as unsafe. OTOH in Go you
strings can contain invalid UTF-8 if I recall correctly.

------
apendleton
This is a blog post that seems to just be reporting on this tweet:
[https://twitter.com/justinschuh/status/1103087046661267456](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...](https://chromereleases.googleblog.com/2019/03/stable-channel-
update-for-desktop.html)

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

That CVE is still reserved/non-public on the Mitre NVD though.

~~~
saagarjha
From the code referenced, it seems like this might be the commit that fixes
this issue:
[https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0...](https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0d594e7edf7b2c07ea2a90449)

~~~
xfs
This interface raw_data_->ToArrayBuffer() sometimes returns a copy of its
internal buffer and sometimes returns a smart pointer to its internal buffer.
See
[https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d5...](https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d594e7edf7b2c07ea2a90449/third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer_builder.h#L63-L67)

But DOMArrayBuffer::Create() here takes ownership of the memory from
ToArrayBuffer(), so in the latter case of a smart pointer, the internal buffer
of raw_data_ is immediately invalidated and its value becomes undefined after
creating the DOMArrayBuffer. This is fine if file loading is finished at this
point because raw_data_ is reset to nullptr, but if the load is partial, then
the undefined value in raw_data_ will be reused to create another
DOMArrayBuffer which is then accessible in javascript. Hence the use after
free.

I'll attribute the root cause of this bug to unclear memory ownership passing
in interface design.

------
uniformlyrandom
This 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?

~~~
blattimwind
> Does anyone actually use this abbreviation?

More common in plural (vulns). However, it sounds oddly vulgar in my ears.

~~~
DC-3
It's weird because when you read vulnerability (or at least when I say it) the
first phoneme effectively becomes 'vun' \- but in the abbreviated form one
feels the need to mentally enunciate the 'l'.

~~~
qu4z-2
I think the dropped l might just be your locale. I certainly pronounce it in
the full word.

------
paulpauper
This write-up is not helpful and says nothing about how one would be infected.
it just says it can do code execution but no evidence anyone has been infected
in any way or how would would be infected. The worst 0day possible is un-
sandboxed code execution that is activated by merely visiting a webpage or
clickinig.

~~~
jrochkind1
This article has a _bit_ more information, including suggestions by some that
there are indeed exploits active in the wild.

[https://www.forbes.com/sites/daveywinder/2019/03/07/google-c...](https://www.forbes.com/sites/daveywinder/2019/03/07/google-
confirms-serious-chrome-security-problem-heres-how-to-fix-it/#f30ea7820029)

> Although information regarding CVE-2019-5786 remains scarce currently,
> Satnam Narang, a senior research engineer at Tenable, says it is a "Use-
> After-Free (UAF) vulnerability in FileReader, an application programming
> interface (API) included in browsers to allow web applications to read the
> contents of files stored on a user's computer." Some further digging by
> Catalin Cimpanu over at ZDNet suggests that there are malicious PDF files in
> the wild that are being used to exploit this vulnerability. "The PDF
> documents would contact a remote domain with information on the users'
> device --such as IP address, OS version, Chrome version, and the path of the
> PDF file on the user's computer" Cimpanu says. These could just be used for
> tracking purposes, but there is also the potential for more malicious
> behavior. The 'use-after-free' vulnerability is a memory corruption flaw
> that carries the risk of escalated privileges on a machine where a threat
> actor has modified data in memory through exploiting it.

~~~
zenexer
That's conflating two unrelated issues. The issue reported by EdgeSpot is much
less severe, and a Google engineer hinted that it may not even be a
vulnerability. CVE-2019-5786 has nothing to do with PDF files.

------
k_sze
I have a hard time believing that something written on sophos.com can be so
click-baity/devoid of substance.

Half of it is vulnerability vs exploit in eli5 style, and then the rest is
just mentioning FileReader in passing.

------
Rapzid
Oh 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!!!!"

------
yayr
What does this mean for Electron Apps?

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

~~~
cjones26
Which is a massive security issue in itself--Electron documentation even warns
you about this.

~~~
AgentME
Electron's docs ([https://electronjs.org/docs/tutorial/security#isolation-
for-...](https://electronjs.org/docs/tutorial/security#isolation-for-
untrusted-content)) mention that you should webview or BrowserView with a
certain option with untrusted content, not that it shouldn't be done at all.

------
lemoncucumber
> A vulnerability, or vuln for short, is a bug that makes software go wrong in
> a way that reduces computer security.

So glad the article cleared that up.

------
peterwwillis
_clicks Help- >About Google Chrome_

    
    
      Updates are disabled by your administrator.
    

welp.

~~~
commandlinefan
What you should do is find out how the referenced vulnerability works and then
exploit it to bypass administrator controls so you can update.

~~~
mdaniel
I hope this doesn't qualify me for a "whoosh" of your joke, but wouldn't an
RCE in Chrome run code as the current user? Or did you mean attack the domain
admin's computer?

------
dplgk
> Like, seriously, update your Chrome installs… like right this minute.

If so serious, remove the 2 likes from the sentence.

------
ktjfi
The version that includes the fix was released a few days ago... how is this a
0-day at this point?

~~~
arcticfox
It was exploited before the vendor was aware; IMO that earns it a permanent
"Zero-day" title. Obviously it's not currently a zero-day, given that we're
hearing about it from the vendor.

The moniker is pretty paradoxical otherwise, the discoverer writing a post
about a zero-day would make it no longer a zero-day.

~~~
kbenson
I always thought it was from the patch date. As I understand it there are
1-days, and 2-days, where people rush to make exploits for released patches to
capitalize on the lag time between patch availability and wide deployment (and
also zero-days which were recently patched), which is why zero-day denotes
that there has been no time since a patch is available (since there isn't
one). So, I would say this _was_ a zero-day up until the point Chrome released
a patch, and as of now it's some low X-day.

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

~~~
feanaro
So it's possible that t1 < t0? Because something might had been exploited
before whatever time is taken as the official "discovery date".

~~~
short_sells_poo
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).

~~~
feanaro
That's slightly inconsistent with the OP's interpretation because the
vulnerability would be traded so it could be exploited (presumably), but by
the OP's definition that would make it no longer be a 0day.

------
crushcrashcrush
Honest question - why do people use Chrome? It’s from an arguably as-evil
company as Facebook. Alternatives exist. What’s the draw?

~~~
tcbasche
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?

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

~~~
Jach
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](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.)

------
runn1ng
Why is this blogspam with no information upvoted in the first place? Does
anyone enjoy reading this?

~~~
C4stor
The post was awful, but I hadn't heard of this exploit before, and I wasn't
patched, so, thanks for that !

~~~
MivLives
That and it has update instructions which makes it easier to link non
technical people too.

------
FerosMorgen
This is why you don’t run TV ads stating you’re completely immune to viruses.

------
entropie
Hmm. Is the developer version affected too? Iam running Version 74.0.3717.0
(Official Build) dev (64-bit) compiled at march 5. (gentoo).

Looking for an update in portage right now.

~~~
entropie
There was actually an update in portage available, running now Version
74.0.3724.8 (Official Build) dev (64-bit)

------
llacb47
Darn, now I have to update chromium and get the new tab design. I've been
avoiding it for a while.

------
Griceraae50100
Note that you can also upgrade Google Chrome by going to he 3 vertical dots
menu, Help -> About Google Chrome. I reckon that’s a little less scary for
inexperienced users than typing in an arcane URL into the address bar…

------
aboutruby
TLDR: 72.0.3626.121 is the version you are looking for

~~~
yrro
Thanks!

------
GrryDucape
The vulnerability is in the browser’s code itself. If you have the stable
channel for Chrome added into Linux, then you just have to run ‘sudo dnf
update.’

------
chrononaut
There goes 1.5 million dollars in someone's money.[0]

[0]
[https://motherboard.vice.com/en_us/article/pax987/crowdfense...](https://motherboard.vice.com/en_us/article/pax987/crowdfense-
offers-3-million-for-iphone-android-hacks)

------
MichailP
Is Canary build safe? My version is 74.0.3726.0 (Official Build) canary
(64-bit)?

------
Wyndtroy2012
Just quit and restart Chrome. No need to fight with an link you can’t click.

------
IloveHN84
Seriously, remove the power given to developers to exploit JavaScript in every
kind of exotic mode and you'll have zero bugs.

------
javajosh
Updating Chrome is a _vaccination_ , which is great, but people already
affected by this exploit need a _cure_. I'd like to know more about who was
exploiting this and for what purpose, and how to undo it.

------
timkofu
Rust anyone?

------
outside1234
Glad Google released this as part of their Google Zero project.

Oh wait, they didn't. That's only for other people's bugs.

------
mnm1
Huh? Right now, my Chrome says:

Google Chrome is up to date Version 66.0.3359.117 (Official Build) (64-bit)
Automatic updates are turned on Learn more

I guess it's time to just delete this garbage, but I'm wondering why. Clearly
there are serious issues with Chrome on OS X.

------
MikeHolman
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...](https://blog.edgespot.io/2019/02/edgespot-detects-pdf-zero-day-
samples.html)

~~~
lima
That's an entirely different vulnerability.

~~~
sterlind
Yeah, I was going to say... it would make zero sense for an attacker to waste
a Chrome RCE 0day on tracking people who read academic books about Honduras!

Although, I'm not sure why they'd do that in the first place, even. Anti-
piracy? Seems a lot of effort..

