Wallpaper that Crashes Android Phones

The image, a seemingly innocuous sunset (or dawn) sky above placid waters, may be viewed without harm. But if loaded as wallpaper, the phone will crash.

The fault does not appear to have been maliciously created. Rather, according to developers following Ice Universe’s Twitter thread, the problem lies in the way color space is handled by the Android OS.

The image was created using the RGB color space to display image hues, while Android 10 uses the sRGB color space protocol, according to 9to5Google contributor Dylan Roussel. When the Android phone cannot properly convert the Adobe RGB image, it crashes.

Tags: Android, phones, protocols

Posted on June 3, 2020 at 6:11 AM • 30 Comments

Comments

Clive Robinson • June 3, 2020 10:44 AM

@ All,

What is it with graphics, hardly a year goes by when we don’t get one causing problems. From causing people to have seizures through being transports for malware.

Of course the question arises from many years back,

If you can crash it with input, can it also be shellcoded?

It’s been a few years since I wrote a “shellcode and “NOP sledge” and many will tell you that it shouldn’t be possible with various changes made to stack handling. But I suspect there’s a few more uptodate tricks that can be used…

mark • June 3, 2020 11:27 AM

Phones that are more powerful than workstations in the 1990s… and the use of all that power and memory? Eye candy.

And you wonder why I have a flip phone, not a “smart” phone.

This also tells me that they refuse to pay for experienced people, hiring kids right out of college… WITH LITTLE TO NO ERROR HANDLING EXPERIENCE.

Phaete • June 3, 2020 11:40 AM

When the Android phone cannot properly convert the Adobe RGB image, it crashes

That’s why we will keep our bugs, vulnerabilities, overflows etc.
Error handling is known and used for half a century (give or take a year) and we still struggle to implement it fully.
Both Program and OS could have stepped in and handled the error, but they just went duh.

And error handling is several factors easier then the slew of other things to do to prevent vulns.

ADBElong • June 3, 2020 12:14 PM

Photoshop dates to 1988(creation) or 1990(Adobe release). Adobe RGB colorspace dates to 1998.

Wael • June 3, 2020 12:37 PM

@Clive Robinson, …

What is it with graphics, hardly a year goes by when we don’t get one causing problems

And that’s not intentional. Wait until the next HW malware comes into picture… bad people setting up posters and advertisements (QR code and otherwise) in public with graphical malware. Take a picture of some landmark, and bang! Your phone is owned. What a concept!

Spellucci • June 3, 2020 12:53 PM

Once a phone can be made to crash, isn’t it just a matter of time until the vector that made it crash can be turned into an exploit?

Wael • June 3, 2020 1:31 PM

@Spellucci,

… isn’t it just a matter of time until the vector that made it crash can be turned into an exploit?

Yes. Perhaps it’s a zero-day idea already!

lurker • June 3, 2020 1:56 PM

Is this a systemic problem in Android OS10? or only in those handsets listed whose makers had not patched this problem? It is a problem for the Android Bazaar[1] where every vendor is free to leave out or add in functions. My current phone will accept .aif .mp3 .mp4 and some others as Ringtones; but for Notification sounds it accepts none other than .ogg. Go figure.

thanks Eric Raymond

Petre Peter • June 3, 2020 2:09 PM

Let’s not also forget attack from competitors.

MK • June 3, 2020 5:28 PM

@ADBElong I think the ADBE RGB color space goes much further back — to 1991. I remember many discussions with the Adobe’s color guru about RGB vs sRGB. And Kodak’s color experts on why various color space mappings were so much voodoo.

sofa • June 3, 2020 6:19 PM

Photoshop dates to 1988(creation) or 1990(Adobe release). Adobe RGB colorspace dates to 1998.
LIKE

Anon Y. Mouse • June 3, 2020 6:36 PM

re: error handling, or lack thereof

And yet how many times have you seen an error check where
the code abruptly quits, and the comment says something like
“this should never happen”?

Lawrence D’Oliveiro • June 3, 2020 7:33 PM

For some reason this brings to mind Douglas Hofstadter’s wonderful book Godel, Escher, Bach: The Eternal Golden Braid. If you remember, in-between the more serious parts are some more light-hearted interludes featuring some Lewis-Carroll-esque characters. One or two of those featured a contest between two of the characters, where one would claim to have built a gramophone player (the book dates from before the popularity of CDs) that could play any record, while the other came up with a record that would not play on this player.

Hofstadter didn’t explicitly address the idea in the more formal parts of the discussion (that I recall), but let me make it more explicit thus: could it be that, whatever code you come up with for processing/displaying some data format X while correctly handling malformed files, you can always come up with some malformed file that will cause it to malfunction in undesirable ways? Is this even a computationally decidable question?

Lawrence D’Oliveiro • June 3, 2020 7:34 PM

Sorry, that should of course be “Gödel”.

lurker • June 3, 2020 11:08 PM

Presumably other apps on the phone are happy with vanilla RGB, and its only the Wallpaper function that throws a conniption. Its stretching credulity that nobody, nowhere within that list of high octane vendors, didn’t have a collection of old favorite pix to try out…

Clive Robinson • June 3, 2020 11:17 PM

@ mark,

This also tells me that they refuse to pay for experienced people, hiring kids right out of college… WITH LITTLE TO NO ERROR HANDLING EXPERIENCE.

It’s not just “errors” there are “exceptions” and a very bad habit of moving data error checking to the left, away from the functional code, to fruitlessly try to over come not being able to handle “errors or exceptions”, and why functional code has “suicide leaps to exit”.

If people want their code to be resilient thus get it’s foot on the lader towards being actualky usefull, then they need their code to be able to roll input back up the program flow to a point where switching to alternative functionality can deal effectively with any errors but more importantly exceptions.

Yes it’s harder to write code to be more resiliant and an exception handler might only be used in a develipers view one in a billion times… But consider the world population is heading for 8billion people that are working towards working from a keyboard half a working day every day not just for work but education, recreation, and social activities. That one in a billion is suddenly going to be several phone calls to tech support every day and worse…

Oh and remember your code has to “roll back” errors and exceptions not “jump back”, jumping back can cause endless loops more readily than you would expect, and in that direction lockup and zombies happens. There is a reason why network packets have a “Time To Live” (TTL) counter.

Clive Robinson • June 3, 2020 11:59 PM

@ Wael,

Take a picture of some landmark, and bang! Your phone is owned. What a concept!

It’s one I’ve been thinking about off and on for a while now…

As you may remember we had a discussion about extending the three authentication factors of,

1, Something you are (bio-metrics)
2, Something you have (tokens)
3, Something you know (passwords)

It had become clear that in many jurisdictions the first two were now useless due to compulsion by Law Enforcment and the Judiciary. And although we joke about the IC and “$5 wrench cryptanalysis” we know that various western countries quite cheerfully condone torture of various types by the IC to gain information.

Thus I suggested positional and temporal extentions to the something you know.

That is the “full emergancy” unlock code for your phone is being in a certain place at a certain time, that is out of jurisdiction etc. Easy for individuals to remember very dificult to fake if you use things like “live images” where software can use shadows to work out the time of day etc.

I got the idea from seeing those little “QR Code / NFC” tags in bus stop advertising hordings some years ago. And being a person who “thinks hinky” my first thoughts were how to abuse them to get malware on a phone… A little while before thinking up a way to use them constructively for security.

Frighteningly when I looked at early examples of code to read those advertising tags, abusing it to “pown-a-phone” was way way to easy. It was realy scary to see such poorly developed code even in prototype code…

Speaking of NFC, ever wondered about what those Electronic Point of Sale (EPoS) “Contactless Payment” system applications on your smartphone might be doing? Yup thr code is not exactly hot security wise either…

As for the “Intel Xmas Gift that keeps giving” and similar way down the computing stack hardware vulnerabilities, we don’t realy need to guess… Those reoccurring “Serial I/O” failings where you can plug a device in a port in the back of somebodies computer and get full access to system core memory happen often enough –a little under every decade since before the one “Apple first got notoriety for”– to confirm once again the idea that the ICT industry does not learn from it’s own history…

Wael • June 4, 2020 1:18 AM

@Clive Robinson,

As you may remember we had a discussion about extending the three authentication factors of

I do, as far back as 2012 and a few times after.

Something you are (bio-metrics)…

The folks[1] that wrote PSD2 requirements have changed the terminology:

Something you are (bio-metrics) → Inheritance factor
Something you have → possession factor
Something you know → knowledge factor (this one I’m not sure of and too tired to look up)

It had become clear that in many jurisdictions the first two were now useless due to compulsion by Law

We discussed that aspect as well with @Dirk Praet. And we talked about ways around it, including ancillary parameters (not factors) like location, time, etc. Apple, by the way, introduced a “Duress feature” where one can disable FaceID within five seconds, if one feels a need to protect against LE. But then we discussed tradeoffs between device security and owner’s.

Speaking of NFC, ever wondered about what those Electronic Point of Sale (EPoS) “Contactless Payment” system applications on your smartphone might be doing?

I more than wondered: I worked on their architecture, design and specifications. And no! That’s not why they suck.

As for the “Intel Xmas Gift that keeps giving”

I normally refuse wrapped gifts from strangers. But not easy way out!

1] I believe none of them have anything to do with security; one is an economist, another is … something else, I guess.

Robin • June 4, 2020 3:04 AM

@Lawrence D’Oliveiro, thank you for reminding me of Hofstadter’s marvellous book, one of my all-time favourites. It fills me with awe that someone is capable of writing such a rich, insightful, multidisciplinary book. I must re-read it.

You inspired me to get my copy down from my bookshelves – how the pages have yellowed! – to look up references to record players.

He does discuss the question in several places, but you won’t be at all surprised to learn that it moves on from the amusing to the profound so quickly that the reference seems to be lost.

William • June 4, 2020 3:54 AM

Years ago the OpenBSD community came up with a sandboxed wallpaper setting utility for X, xwallpaper. I never grasped the idea how a wallpaper setting utility could become an issue since you would have downloaded the wallpaper image with a browser at one time or another.

Now it makes sense to me.

There are just too many different approaches of parsing data, let it be images or XML as we have seen on this blog just a few posts ago. Just because chrome tells me the image is okay does not mean that the processor of the next tool thinks the same.

Has anybody seen something like this for chrome + feh? Since feh uses the deprecated imlib2 for file parsing and has ability to download files and execute binaries, I would not be surprised to see more than a crash on a GNU/Linux desktop.

Clive Robinson • June 4, 2020 4:03 AM

@ Wael,

Something you are (bio-metrics) → Inheritance factor

Your harsh mistress must be working you hard 😉

It’s not “Inheritance” but “Inherence” as in “something inherent about you”

Whilst it includs the physical bio-metrics it also unfortunately includes “muscle memory” type “learned things” that are realy something you know Knowledge.

Thus as Muscle Memory kind of crosses over into the “something you know” and they know it, they’ve ruled out some muscle memory types such as finger drag patterns… But to my mind it’s a breach of their own rules on the factors being independent of each other.

That is I put “muscle memory” down as an extention to “something you know” because,

1, It is learned behaviour as knowledge is.

2, It alows you to conciously change it if you wish as you can do with all knowledge.

Both of these are very definately the primary charecteristics of “something you know”, neither of which you can do with the normal physical bio-metrics such as hand geometry.

https://www.cryptomathic.com/news-events/blog/ebas-opinion-on-elements-of-strong-customer-authentication-under-psd2-part-i-inherence

To be honest what little I know about the European Banking Authority (EBA) requirments for Strong Customer Authentication (SCA) for compliance with the European Union, Revised Payment Services Directive (PSD2) the more convinced I am that at best it is a “fig leaf that has been got at by caterpillars”[1] thus is now an excercise in “profitable futility” by consultants, auditors, and similar boondoggle rent seeking activity (which an earlier “requirments process” alowed auditors to tick the 2FA box for the use of a predictable bank issued identifier and a weak password…).

Because if you look at what passes as factors, a smart phone and a PIN meets the EBA requirments, which we know is far less secure than a traditional bank card and PIN…

[1] That is banking and finance industry lobbyists have knobbled the PSD2 aims and have as a result provided the banking and finance industry with yet another way to externalise risk onto customers thus have no liability for the piss poor security systems they implement.

Wael • June 4, 2020 6:36 AM

@Clive Robinson,

Your harsh mistress must be working you hard 😉

Overtime too!

It’s not “Inheritance” but “Inherence” as in “something inherent about you”

Oh, well… what can I say?

Thus as Muscle Memory…

Reminds my of something in this early hour of the morning: how many senses do humans have? Obviously I don’t believe the answer is five, or I wouldn’t ask the question!

Clive Robinson • June 4, 2020 4:11 PM

@ Wael,

how many senses do humans have? Obviously I don’t believe the answer is five, or I wouldn’t ask the question!

Well it depends on how you look at things…

For instance “taste” it was assumed that the tongue was only sensitive to sweet, sour, salty, etc… Then along came unami (or however you spell it 😉 Thus clearly our existing senses can be extended.

Then there was that issue over pepermint flavour and orange favour, that has led some to believe we do not “smell” chemicaly but by molecular resonance effects. So even the way our existing senses work can be substantially reappraised, which raises up other detection possibilities.

So then take a look at “Touch” does that include “preasure” or not? As we can detect preasure by how hard it is to inflate our lungs, or make our ears pop, or in bones we have broken in the past, I would argue that it is not part off “touch”.

But the real eye opener, is magnetic pulses adjacent to certain areas of the brain, make people “twitch or jump”. So susceptability to magnetic fields is a new one to consoder putting on the list.

So yeah the old “five senses” has been modified by modern science.

Wael • June 4, 2020 4:44 PM

@Clive Robinson,

Add to that: muscle sense: we can tell approximately how much an object weighs by lifting it, even if we wear gloves that eliminate the sense of touch. We can also approximate a thickness of an object by “feeling” the distance between our index and thumb with our eyes closed and also wearing a glove. Net net, we have at least eight or nine known senses 😉

Then there’s also the sense of feeling imminent danger…

Jon • June 4, 2020 11:52 PM

@Clive Robinson

As an aside on “the five senses”, one might add the ability to perceive different colours extends vision, the same way different tastes extend taste.

However, before you go too far down those lines, note that some people (and dogs, notably!) are colourblind. Many people who have suffered from COVID-19 report loss of smell and taste (permanently? We’ll see).

So it is not only possible to ‘extend’ senses – it’s also possible to ‘retract’ (or just not have them to start with) senses. I have never seen a two-factor ‘token’ that can be used by the blind, for example.

They deserve as much security as everyone else. J.

Lawrence D’Oliveiro • June 5, 2020 7:36 PM

@Robin

…[the discussion] moves on from the amusing to the profound so quickly that the reference seems to be lost.

My impression exactly.

Lawrence D’Oliveiro • June 5, 2020 7:39 PM

Clive Robinson:

…they need their code to be able to roll input back up the program flow to a point where switching to alternative functionality can deal effectively with any errors but more importantly exceptions.

There is a technique to this, particularly in the lower-level languages (like C) that provide the libraries used by the higher-level, dynamic languages. It involves an old, seemingly unfashionable concept nowadays: “structured programming”.

I discuss it further, and give some concrete examples, in the specific context of an extension module for use with Python, here.

Clive Robinson • June 6, 2020 9:10 AM

@ Lawrence D’Oliveiro,

It involves an old, seemingly unfashionable concept nowadays: “structured programming”

Not just “structured programming” as is taught, there are a lot of subtleties that get missed Knuth’s point about the directions of actions on flow charts and why they should never cross being one.

Also the issue with left to right thinking where a function has a “data source” to it’s left and a “data sink” to it’s right, and the implication there of that data can only go from left to right. Thus if there is an error or exception returned from the data sink then the incorect implication that all you can do is “drop the data” and or “bug out” bringing the program to a halt, and with it dropping untold amounts of data.

A little bit of thought should make most people realise that this is at best a little idiotic behaviour, and in the real world unacceptable. That is if you are filling jars with dried beans when a jar is filled you don’t throw what’s left on the table on the floor or in the trash, you simply back the process up a little and switch to filling another jar.

Why should filling a floppy drive or tape drive with data be treated any other way?

It’s the “back the process up a little” that most programmers fear to tread. That is they only want to write “one way functions” that like “Data Diodes” issolate that before from any consequences of that which follows…

I won’t go into the details of what you do because there are several different ways. But the important point is to stop a simple fault, error, or exception becomming an endless loop of “Try and Try Again”.

What I will say is perhaps the simplist way for most programmers to start thinking about how to do it is as follows,

Firstly break all input into discreat records that are to be processed, and make them of as small a size as possible.

The record structure has two data buffers and two counters and an offset pointer.

The first buffer contains the raw input data, the second contains the input to the current function and the first counter contains the function number of the current function being used in the processing stream. The offset pointer identifies where an error was found in the second buffer. If it’s not an error but exception then this pointer contains a negative value error code. The second counter is an itteration or “Time To Live” counter.

If anything goes wrong this record contains everything you need to know to find out not just what but where anything went wrong in the processing stream.

You can thus write functional code to deal with the error or exception.

The downside is you add a lot more code to be not just written but tested, and you need to be aware of how to do this without increasing complexity in any given area of the code, thus keeping it all managable.

The downside of this method and the reason for the TTL counter is that rather than work the error or exception backwards up the function stream / stack you actually put it back in at the top of the stack…

Oh and the other thing programmers must stop doing is moving input error checking as far to the left as they can well well away from the business logic function where the error checking needs to be done. At the veey least this move error checking to the left stops effective code reuse as things gets lost in translation especially when people refactor without full knowledge.

This sort of thing was supposed not to happen with “design by contract” but for some reason people don’t appear to get that right either. Often by writing the wrong form of function contract…

Lawrence D’Oliveiro • June 6, 2020 6:38 PM

@Clive Robinson

…and why they should never cross being one.

A.k.a. “Nassi-Shneiderman diagrams”. That is a point specifically made in my example.

Bystander • June 7, 2020 1:03 AM

I just wonder why the ‘all input is evil’ meme does not get mentioned that often. Parsing the input for errors combined with error handling helps.

Had a professor who tried crash the programs written by the students before testing any functionality.
Did not like this in the beginning as sanitizing the input took more effort than the rest but it was worth it.

Schneier on Security

Wallpaper that Crashes Android Phones

Comments

Leave a comment Cancel reply