18 ms·
Android Phones Can Be Hacked Remotely by Viewing Malicious PNG Image
- craftoman 8y agoIs 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 8y agoIt’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 8y ago> 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.
- deleted 8y ago[deleted]
- jchw 8y ago>A decent programmer would never trust the remote end to actually just send [number of bytes to come] bytes. Well, I applaud your optimism, anyways, but programmers of almost any skill level make egregious security mistakes, especially when working on a deadline. Maybe not everyone would make this mistake, but managing trust while writing optimal code is very tricky. LZO is a fantastic example of a library that had an "obvious" security flaw for many years, with a fairly trivial integer overflow bug, due to how the decoder dealt with the variable length int encoding.
- ajross 8y ago> A decent programmer would never [...] And that kind of attitude is why we still have security bugs.
- nineteen999 8y ago> And that kind of attitude is why we still have security bugs. Absolutely poppycock. We could all program in completely memory safe languages tomorrow with only one signed integer type and crap programmers would still find a way to write security holes into their programs. I'm in no way condoning the use of C/C++ forever, the writing is on the wall for those languages, as much as I love them. But programmers have to learn first and foremost to take responsibility; if you're writing code that runs with elevated privileges then BE CAREFUL. If you're writing code that is reading data from an untrusted source (disk, network or otherwise) then BE CAREFUL. Hell, being careful even if you think the data source can be trusted is a good starting point - defensive programming 101. We cannot blame our tools forever, but we can improve them.
- jononor 8y ago"Be careful" is not very actionable. Here are some things you can actually do: - Perform periodic external security reviews - Use fuzzing for all uncontrolled/user-inputs - Use static analysis tools - Maintain a security bounty program - Send your employees to security training - Use a memory safe programming language
- nineteen999 8y agoThat is a nice list and all, and I would add that if you can't use a memory safe programming language then you should look closely at the compiler flags in use as well. But if you need all that to spot the obvious issue in the OP's original specification ... then wow.
- pas 8y agoI'd add the "adopt an information theoretic approach" to security analysis. (Which is basically what taint analyzers perform.) Think through how systems/components/libraries/functions can and do interface with each other, and try to secure these points. (Make them type safe, make them strict, report meaningful errors ["expected this but got this" is a million times better than invalid input], so they will be easy to maintain and make even more secure.) Try to extract out these parameters as much as possible so you can avoid possible impedance mismatches across the interfaces. Also, checklists. Checklists are good. And an inventory of used components, and their versions. (This makes it easy to do a CVE review from time to time, and then to automate the review eventually, so only the list maintenance will remain manual.) Defense in depth, but not through obscurity. (There usually are low hanging fruits. Enforce use of password managers, invest in centralized credential storage, don't overdo password expiration and 2FA. Security training is also a good idea, but the real goal is to nurture a security aware office/team culture.) Social engineering [or just plain old laziness] is still a serious threat. Timeboxing. Set aside 1-2 days every month to work on meaningful security-conscious goals. So try to upgrade to lay the fundamentals for that library upgrade that is overdue for years, try to make systems reproducible (also good for DR), try to add a few simple validations here and there against local file inclusion (or whatever comes up during the month, or during the checklist review). Also, accepting that maintaining network facing systems have an inherent ongoing cost. (Unless you want your iToaster to eventually end up as part of a botnet.) Sometimes we have to let things go, accept that some business models (or hobbyist projects) are not worth it to do sanely and securely.
- Godel_unicode 8y ago> 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.
- nineteen999 8y agoYou and I evidently have different definitions of "decent programmer" then. It sounds like your standards are much lower.
- lagadu 8y agoUnless by "decent programmer" you mean a non-human programmer, he's right. This might be shocking to a flawless supercomputer AI such as yourself but humans make mistakes.
- nineteen999 8y agoLook back at how the original problem is specified. > 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? If your client came to you and said that was the specification, you'd be negligent to fail to point out the obvious flaw with the logic, wouldn't you?
- Gaelan 8y agoIIRC Heartbleed was basically exactly that.
- nineteen999 8y agoHeartbleed triggered a major audit and a fork (LibreSSL) of the OpenSSL codebase, wherein much of the code was found to be of less than stellar quality: "Unfortunately, the OpenSSL basket was being watched somewhat less than very carefully. Yeah, it has bugs, but surely somebody else will fix them. And worst case scenario, since everybody uses the same library, everybody will be affected by the bugs. Nobody wants to be alone". https://www.openbsd.org/papers/eurobsdcon2014-libressl.html https://www.openbsd.org/papers/eurobsdcon2014-libressl.html So I'm pretty sure the one example you have picked here reinforces my point.
- tokyodude 8y agoNo, decent programmers know that no one is perfect and so they design systems so that even when the most experienced programmers ever make a mistake that mistake is less likely to cause an exploit. This is the entire premise of Chrome's architecture. Check the CVEs and you'll see there's the same number of bugs as every other browser but around 10x less code exploits because it's designed under the premise that bugs happen.
- nineteen999 8y agoA decent programmer or team of programmers can select a good architecture, and also not pretend that it is okay to treat a 4096-byte buffer as if it were 4097 bytes long.
- pas 8y agoChrome did the as fast as they could sandboxing because they has no better alternative, because we lack better libraries for parsing. Decent programmers also try to err on the side of safety, use the right tool for the job, and so on. And writing parsers should not be done directly, instead the parser code should be generated by a battle tested library/framework. (Or via using parser combinators, etc.)
- fulafel 8y agoWell, it's hard only if you do it in hard mode (in hand-written C/C++), just like bulletproof anything is hard there. We (as a field) have for decades known how to do it safely, people just elect to do it unsafely because of the usual reasons.
- closeparen 8y agoThere is a decent argument that line of business apps in unmanaged languages are taking silly risks, but this is the operating system. If the platform has already spent the processing power, application developers are going to be pretty constrained.
- madeofpalk 8y agoIIRC, one of the first iPhone jailbreaks used malformed images as an attack vector to get root.
- fmj 8y agoThere was an image based exploit for the PSP as well.
- birdiesanders 8y agoPNG as well, iirc
- davis 8y agoYup, it was TIFF in the iPhone case
- aboutruby 8y agoThere has been remote control by viewing a web page (classic), a pdf, a word document, receiving a text message, just being connected to the internet, etc. And that's just the beginning, then comes all the indirect attacks like stealing your domain, phone number, identity for loans, etc etc
- cjbprime 8y agoYeah, I'd say this is paranoid -- it turns out that file format decoders have been extremely insecure forever, and Google's been doing more than anyone to advance the fuzzing of public libraries to fix it. If they wanted to put a backdoor somewhere, they would not put it somewhere where their own automated tools that would detect and publish it.
- microcolonel 8y agoSeems the vulnerability was in Skia, thankfully, rather than libpng.
- TwoNineA 8y ago>> We encourage all users to update to the latest version of Android where possible. Good luck with that.
- Despegar 8y agoIt's fine, Google updates everything through Google Play Services now.
- graeme 8y agoIs this sarcasm or serious? If serious, how does this work in practice on older phones that don't get oa updates but do get play store updates? I see this mentioned a lot on reddit, but unless there are no security updates happening through android itself it seems ill informed.
- voltagex_ 8y agoI deleted a couple of responses to this but the short version is that no, Skia (the affected component) is not being updated through the Play Store Framework. Flippant responses to security issues are not useful.
- graeme 8y agoThanks! I was 99% sure the common reddit response was wrongheaded. I'll make this point explicitly when I see it, that phones may get some updates, but that old phones don't get the security patches at an os level. Am not on android so I didn't want to be mistaken in how it worked.
- voltagex_ 8y agoI don't have the info on Project Treble (Android 8 and up) - this changes things as the "Android Framework" is separated out from the rest of the phone firmware. It's not clear if this would include kernel and driver updates (I don't think so), but it's very likely things like Skia and codecs would be able to be updated faster. Very happy to be corrected. It also looks like not all devices running 8.0 were required to be Treble compliant. Hi, Samsung.
- fulafel 8y agoIf 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 8y agoAnd 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.
- zozbot123 8y agoThe long-term solution is to move away from binary blobs. The PostmarketOS project is trying to achieve this for at least a few hardware models, including most notably the LG Nexus 5.
- Aissen 8y agoApart 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 8y agoActually 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/
- xiphias2 8y agoShouldn'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 8y agoWell... 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.
- erk__ 8y agoWell the problem with go I believe as soon as you have to make high performance code you disable the garbage collector, which removes a lot of the safety features.
- xiphias2 8y agoActually 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 8y agoWhy isn't Go capable of system level programming memory safety?
- Macha 8y agoIt has a runtime with a GC. It's capable of safety, but not the low level performance/predictability of the Rust approach, and is also harder to embed than a Rust approach. This is not a disqualifer for most use cases, but is for some.
- 8y ago
- debt 8y agoI 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.
- mschuster91 8y agoSemi-OT: is there already a shellcode for this? The Chromecast should be vulnerable to this too, given it's Android based?
- atrilumen 8y agoChromecast was Chrome OS, which is not Android. (And I doubt that's changed.)
- ComputerGuru 8y ago...which probably uses Skia as well.
- atrilumen 8y agoFor sure. This post freaked me out because my main machine now is a Pixelbook.
- mschuster91 8y agoBut it ran adb? https://forum.xda-developers.com/showthread.php?t=2407250 https://forum.xda-developers.com/showthread.php?t=2407250
- trulyrandom 8y agoIt'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.
- deleted 8y ago[deleted]
- outlog 8y agoAbsolutely 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..
- OpenBSD-supreme 8y agoNo, that's not strong enough. It should be indefinitely (or owner has right to damages) UNLESS the entire spec and interface of a device is completely, comprehensively, and publically documented from the silicon up, and the device must either lack software integrity checking or it must be fully under the owner's control (eg purge OEM public key, replace with his own). This should apply to all products containing microprocessors and software to execute, and should apply to burned in ROMs too (since that software in ROM should be user writable/replaceable, this should discourage use of burn in ROMs). This should apply to the end product, so the whole car, TV, washing machine, vacuum cleaner, cellphone, game console, Intel CPUs and chipsets, etc, must have its microcontroller interfaces and specs fully and publically documented or damages could be awarded later once exploits appear. This should tamp down on IoT for fridges and can openers too as what OEM wants to either document IP xor expose themselves to potentially unlimited civil liabilities.
- qubex 8y agoDo you really want legislators defining what is and what is not a ‘security’ issue?
- koolba 8y ago
- billpg 8y agoIs this going to be used as an opportunity to get us all to buy new phones much earlier than we normally would?
- glenrivard 8y agoWhy you get a Pixel. Got updated so does not have vulnerability.
- joeblau 8y agoIf 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
- jrochkind1 8y agoI 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 8y agoIf 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 8y agoThanks, 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 8y agoHow 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.
- billpg 8y agoIs there a test to see if my device is vulnerable?
- throwaway2016a 8y agoI 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)