
Android Phones Can Be Hacked Remotely by Viewing Malicious PNG Image - air7
https://source.android.com/security/bulletin/2019-02-01.html
======
trulyrandom
It's kind of ridiculous that my Google Nexus 5X, which was released just over
3 years ago, will not receive updates to patch vulnerabilities like this
anymore.

~~~
outlog
Absolutely agree - there should be regulation demanding a 5 year period of
security updates (or similar)..

Check out [https://www.lineageos.org](https://www.lineageos.org) or one the
other dists out there - and get that loaded up..

~~~
qubex
Do you really want legislators defining what is and what is not a ‘security’
issue?

~~~
jononor
What is your proposal for fixing that devices are not updated these days?

~~~
rattlesnakedave
Get a new device and pick a manufacturer that provides updates.

~~~
felix_nagaand
So daydream. Such a company doesn't exist.

~~~
fghtr
Here you go:
[https://puri.sm/products/librem-5/](https://puri.sm/products/librem-5/)

~~~
votepaunchy
You do realize that phone is only available for preorder? They may not even be
around in 3 or 5 years. The OP likely suggested Apple (5s is in its 6th year
of updates).

~~~
fghtr
>You do realize that phone is only available for preorder?

Yes, it is only for preorder, but the devkit already exists [0].

> They may not even be around in 3 or 5 years.

If they manage to make the final version of the phone (which is quite likely),
it won't matter anymore, since the OS is just GNU/Linux. Correspondingly, the
updates do not so much depend on the phone manufacturers.

[0] [https://puri.sm/posts/how-we-designed-the-librem-5-dev-
kit-w...](https://puri.sm/posts/how-we-designed-the-librem-5-dev-kit-
with-100-free-software/)

~~~
SketchySeaBeast
So how does that solve a problem lineage os doesn't?

You're buying into a phone that _should_ get continued support for years to
come, assuming the company survives, and they don't end up finding the
maintenance burnden utterly untenable (once they on model version 3, I can't
see it being the easiest thing to support the older models - Apple does, but
Apples huge). It seems to be relatively underpowered (though that's really up
to how many resources the system uses), and I can't imagine will age well.
There will be little to no mainstream app support (they seem to be touting
"just run it in a browser" as a solution to that - I thought we left those
dark ages).

It seems like a neat, niche product, like a raspberry pi phone, but it doesn't
give me a lot of hope for the future.

~~~
fghtr
> So how does that solve a problem lineage os doesn't?

LineageOS depends on the proprietary drivers and/or undocumented devices,
which will never get any updates. If there is a security bug in your WiFi
driver, game over. This phone is being designed to work with free software,
anyone could do updates.

>assuming the company survives, and

Again, free software gives us the freedom to do updates ourselves (or pay to
someone to get them). GNU/Linux supports most of the old computers quite well.

>There will be little to no mainstream app support

"We will test the capabilities of powering Anbox or Shashlik to allow users
the ability to run Android applications within PureOS on the Librem 5",
[https://puri.sm/faq/](https://puri.sm/faq/)

>It seems to be relatively underpowered

True, but one has to start somewhere. Personally, I think this phone brings a
lot of hope for the future.

------
fulafel
If you follow the monthly Android Security Bulletin, there has been a long
stream fixes for remote-code-execution vulnerablities in codec
implementations. It got big in 2015 when the Stagefright branded vulnerability
got some publicity, and they continued testing & have continued to fix an
endless stream of codec vulns ever since.

There was also a Bluetooth RCE in this month's bulletin. And in November there
was yet another round of WiFi pwnage, this time in Qualcomm WiFi
(CVE-2018-11905). It's all quite bad.

~~~
Aissen
And this is exactly the reason why you need vendor support to apply fixes.
Half of those fixes are in binary blobs, so if you don't update those (e.g you
rely only on AOSP/Lineage updates), you're screwed.

~~~
Aissen
Apart from the fact that the only answer right now for security-conscious
android buyers is "get a Pixel" (I'm exagerating, flagship from a few vendors
are good to go for 1-2 years), this is once again a reminder of the damages of
binary blobs, here directly for consumers (they have non-updatable security
holes).

~~~
mediumdeviation
Actually Android One devices are also guaranteed (inasmuch as the tiny text at
the bottom of the Android One website [1] says) three years of security
updates

> Monthly security updates to be supported for at least 3 years after initial
> phone release.

(scroll down to the bottom of the page and look for the double asterisks
footnote. I don't know why they want to hide what is IMO the best reason to
get an Android One device)

[1]: [https://www.android.com/one/](https://www.android.com/one/)

~~~
Aissen
Good point. They previously removed this language from the website, glad they
put it back. So yeah, buy an Android One at launch is good advice for the 3
years of security support.

It's still a short window IMHO, and it's bad for the planet to throw working
devices after 3 years.

------
TwoNineA
>> We encourage all users to update to the latest version of Android where
possible.

Good luck with that.

~~~
tssva
My phone gets the latest Android updates the day they are released even though
it is a discontinued phone and not from Google.

The issue isn't Google or Android. It is phone manufacturers.

~~~
JeremyBanks
Heh. I got the Galaxy Nexus when it was the flagship, and I never got a single
update. I got the Nexus 5X a couple of years ago, and Google is failing to
provide this update for that phone.

If Google can't even get it right on their own devices, they can't be shifting
the blame to manufacturers.

The only remotely-safe choice is an iPhone.

------
jrochkind1
I have a Moto G6 Forge purchased a couple months ago, and it lists no updates
available with the last update Jan 1 2019.

This is just the android ecosystem these days, don't count on security
updates?

(This phone is actually my first smart phone, I can't even explain why I had a
flip phone for so long... except this. But I'm still figuring out what to
expect from em.)

~~~
TheCraiggers
If you want the quickest Android updates, you'll need either a carrier
unlocked Google Pixel, or an Android One device. These are devices where there
are fewer hurdles between a patch and your device.

If, for example, you have a Samsung device from Verizon, it goes something
like this: Google releases new source code containing patch. Samsung takes a
few months to roll it into their updates, and sends it to Verizon to Q&A.
Verizon either pushes back or accepts it after some time. That whole process
takes far longer than it should, partly because they are mixing security and
features in the same updates.

~~~
jrochkind1
Thanks, so I gather it's normal to expect significant delays in security
patches for most Android phones, with some exceptions.

People are talking about how _old_ phones don't get patches at all, but even
most _new_ phones have "zero-day" vulnerabilities (cause zero day lasts for
months apparently) for significant periods.

What a world! How is this okay?

~~~
TheCraiggers
How it's OK is likely because there hasn't been a huge category-5 fuck up yet.
Or at least none that we know of. Some of this is probably from sheer luck.
Some of it is probably from some decent security design baked in like
sandboxing and the like. The first time it becomes public that 80% or more of
Android users just had their personal info stolen, it'll suddenly become not
okay. Especially if that user group contains significant amounts of
celebrities and government types.

It's not all doom and gloom though- there have been improvements. Different
partitioning schemes, breaking out core services out of firmware and into the
play store, etc. It's just that thus far Samsung, the biggest Android player
by far, has decided not to implement all of them.

------
xiphias2
Shouldn't all code be gradually updated to use Rust libraries when they exist?
Is it a stupid idea?

I know it's a lot of work, but the Android/Chrome teams are big, and this is
important enough work that could improve the security of the systems.

~~~
yjftsjthsd-h
Well... Rust has some safety features, but 1. so do others (Go is a Google
project...), 2. it helps with some things and less with others. So yeah, if
you have the resources, using Rust/Go/whatever and taking a security-first
view is sensible. It's not a silver bullet, but it's probably helpful.

~~~
xiphias2
Actually Rust _is_ a silver bullet, that's why it's so exciting.

System level programming memory safety was a dream for a long time.

Go is not capable of this at all, so it's out of question for replacing low
level libraries.

~~~
cjbprime
Why isn't Go capable of system level programming memory safety?

~~~
zozbot123
It does not _actually_ provide memory safety in concurrent scenarios, only for
purely sequential code. Given the predicted use-case scenarios for Go, that's
pretty much a truck-sized hole in the language's purported guarantees,
especially in comparison with Rust.

------
billpg
Is there a test to see if my device is vulnerable?

------
debt
I remember a similar bug with gifs years ago. It was possible to embed html
inside gif and browsers would actually render the html.

It was great for stealing peoples sessions on forums using a malformed avatar.

~~~
DCoder
There was also the Windows Metafile mayhem [0].

[0]:
[https://en.wikipedia.org/wiki/Windows_Metafile_vulnerability](https://en.wikipedia.org/wiki/Windows_Metafile_vulnerability)

~~~
debt
yes! that one was a doozy.

------
microcolonel
Seems the vulnerability was in Skia, thankfully, rather than libpng.

------
craftoman
Is this another backdoor or am I being paranoid again cause this type of
exploit is like those who see in the movies, we start laughing ironically and
we are like "cmon now, that's insane...hack every phone using an image, not in
a billion"

~~~
closeparen
It’s notoriously hard to make parsers bulletproof against malicious input.

For a toy example, imagine the format says [number of bytes to come] [the
bytes]. Allocate an array with the specified size and then copy the rest of
the message into it. Right?

Now you’ve got a remote buffer overflow. How about [start sentinel byte] [up
to N data bytes] [end sentinel byte]? Just put more than the allowed bytes
before the end sentinel.

Unless a format is designed to facilitate secure implementation (which would
include being very simple), there are going to be at least a few vulnerable
implementations. Is it a backdoor? Read the patch yourself, decide whether the
original authors and reviewers knew what they were doing.

~~~
nineteen999
> For a toy example, imagine the format says [number of bytes to come] [the
> bytes]. Allocate an array with the specified size and then copy the rest of
> the message into it. Right? Now you’ve got a remote buffer overflow.

Well then you're doing it wrong. You copy [number of bytes to come] bytes, not
[rest of message] size bytes, only once you've validated that [rest of message
size] is not too large to begin with. That is a _completely_ toy example. A
decent programmer would _never_ trust the remote end to actually just send
[number of bytes to come] bytes.

~~~
Godel_unicode
> A decent programmer would never...

You might want to Google for ImageTragick. Or heartbleed. Or shell shock. Or
Java deserialization. Or flash. But please, tell me more about what a decent
programmer would never do.

~~~
pas
Decent programmers are also context dependent. For example when ImageMagick's
delegate functionality was envisioned (before 1999 - that's the earliest page
I was able to quickly found that mentions the feature), IT security was not
taken that seriously. Basically Mitnick was just arrested (1995), multi user
systems were all guarded and watched closely by bastard operators from hell
like dragons sitting on a mountain of gold.

And PHP was seen as harmless fun.

And malware was thought of as boot sector viruses and even though the first
worm (1988, the Morris) worked _exactly_ like what people are harping about
(buffer overrun), no one cared, because C++ was slow to compile, and managed
runtimes are evil.

And still no one cares. It takes some competence to stop using C, but it's
easier to simply shout at those who point out the obvious.

And when someone brings out the good old Therac-25 everyone starts to fall
silent. (Even if healthcare accreditation is very expensive, it's expensive
exactly because the whole IT field is still full of unverifiable code.)

~~~
nineteen999
> For example when ImageMagick's delegate functionality was envisioned ... IT
> security was not taken that seriously

Yes it might have been easy to get away with writing the OP's faulty
specification into code back then. After 25 years of people screaming about
the dangers of buffer/integer overflows, it's very hard for me to think that a
serious C/C++ programmer could look at that specification and not see the
issue before blindly committing it to code today. I suppose it could happen.

OpenSSL (which everyone else here is crying about as an example) is also over
20 years old.

> And still no one cares. It takes some competence to stop using C, but it's
> easier to simply shout at those who point out the obvious.

Well imagine trying to rewrite the Linux kernel today in a memory safe
language, without losing any support for any of the current target
architectures. Or NetBSD even more so for that matter. Nobody has convinced me
it could be done, and as of yet, it hasn't been.

Throwing away C and C++ for good is fine - if you don't want to do much in the
way right now of embedded programming, or working with sophisticated games
engines (eg. UE4), just for fun.

If you're not confident of the quality of the code, then maybe don't deliver
it to for all and sundry saying its fit for purpose. And if you are confident,
then check it again. That's all I'm saying.

~~~
pas
> Nobody has convinced me it could be done, and as of yet, it hasn't been.

Agreed. And even though it could be done, but it'd of course came at an
enormous cost to the current pace of driver and other updates.

Google is trying something with Fuchsia though.

And there are experiments similar to how Linux itself got started. (Redox OS
comes to mind.)

~~~
nineteen999
> Google is trying something with Fuchsia though. And there are experiments
> similar to how Linux itself got started. (Redox OS comes to mind.)

Aware of both of these, but yeah, wake me up when either are close to being
capable of being even a niche competitor, for example, as complete and
accessible as Haiku currently is.

~~~
pas
What's Haiku's offering? It's BeOS resurrected. It's in C++. (Which - IMHO -
has too much baggage, and still lacking sane module support.) In development
since 2009 and still lacking SMP, hm.

~~~
nineteen999
Oh nothing on a technical level, I agree with your critcisms there. Just in
the sense that it's available now. It has package management and you can
install applications, compile applications, run applications etc right now.
Unlike Fuchsia and Redox AFAIK.

Most of the BSD's didn't have decent working SMP for a period longer than that
either.

I think it's kind of sad that it takes a company the size of Google to create
something like Fuchsia, which we can't be sure will ever see the light of day
for most users, even given the vast pools of code available in Linux and BSD
they could reference.

Hardware has grown exponentially in complexity since Linux was initially
developed of course, which makes the job of writing a new OS much tougher. But
you could probably find 20-30 different hobby OS's over on osdev.org that are
more complete and accessible for the end user than Fuschsia or Redox right
now, even if they are just more boring POSIX clones.

~~~
pas
> Hardware has grown exponentially in complexity since Linux was initially
> developed of course, which makes the job of writing a new OS much tougher.

Though, interestingly hardware also got a lot smarter (because usually they
have some kind of microprocessor and RTOS on them), so in theory interfacing
with it should be more easier. (Serial buses, simple enumerate, simple
addressing, we have a lot of good abstractions, no need to fiddle with
registers, just use a PCI-E, DMA, I2C library.)

But of course at the same time just supporting these smart standards is hard
(because initialization of things is not trivial, even just getting DDR RAM to
work requires tinkering with MSRs, and ACPI is its own special hell).

------
mschuster91
Semi-OT: is there already a shellcode for this? The Chromecast should be
vulnerable to this too, given it's Android based?

~~~
atrilumen
Chromecast _was_ Chrome OS, which is _not_ Android. (And I doubt that's
changed.)

~~~
ComputerGuru
...which probably uses Skia as well.

~~~
atrilumen
For sure. This post freaked me out because my main machine now is a Pixelbook.

------
billpg
Is this going to be used as an opportunity to get us all to buy new phones
much earlier than we normally would?

------
throwaway2016a
I woke up this AM to an update on my Pixel 2 so at least Google is keeping on
top of their own phones (even though the Pixel 2 is one gen old now)

------
joeblau
If I have a Samsung Tab S3, do I need to wait until Samsung releases an update
to fix this?

edit: N/M I found the updates on Samsungs page that address these

[https://security.samsungmobile.com/securityUpdate.smsb](https://security.samsungmobile.com/securityUpdate.smsb)

