Slashdot Mirror
Security Holes In Google's Android SDK
Redon Buckeye writes "Google's Android software development kit is using several outdated and vulnerable open-source image processing libraries, some of which can be exploited to take complete control of mobile devices running the Android platform. From the article: 'Several vulnerabilities have been found in Android's core libraries for processing graphic content in some of the most used image formats (PNG, GIF, and BMP). While some of these vulnerabilities stem from the use of outdated and vulnerable open source image-processing libraries, other were introduced by native Android code that uses them or that implements new functionality.'"
Security holes in beta software you say? Wow.
How we know is more important than what we know.
If this had been in the final version that was released, is it an easy fix for google or is it a pain in the ass for end consumers to get a fix/upgrade from google?
who cares? there are exactly zero phones running android in public (meaning outside of pros testing)...so how does this affect anyone? must be a slow news night
It would probably be a bit painful. Many cell phones require you to hook up a transfer cable to install a new set of firmware. Of course, this is a fancy new smartphone OS, so it's possible that Google has devised a software update procedure. However, if they have designed an update procedure, what's to stop attackers from attacking the update procedure? (Methinks that an unauthorized GSM base station is all that's needed for a man-in-the-middle attack...)
Javascript + Nintendo DSi = DSiCade
Re-implement it and you'll likely have the exact same problems as this.. or worse.
How we know is more important than what we know.
Having had the ignominious privilege of writing a BMP image parser some years ago, I can state without fear of meaningful contradiction that it's one of the worst image file formats ever devised by creatures claiming to be Man, and that it needs to die die die!
PNG does everything BMP does, and does it better. Just throw away the BMP library and save yourself the maintenance headache. No one will miss it.
Schwab
Editor, A1-AAA AmeriCaptions
I've heard it said, as an example, that only 20% of the code in Gecko is to implement a reliable, standards-compliant rendering engine, and the other 80% is to implement workarounds for (sometimes horribly) broken HTML, and recover from what should rightfully be critical errors. I'm not sure if this statistic is accurate (or, if it was when I heard it, if it still is now); however, at a previous position, our (large-scale) software product, developed over the course of the last decade, large, complex, and convoluted, had a similar statistic. Over 80% of the code that we had in our core product was there to deal with bugs in previous code, bugs in other people's products, bugs in how different vendors implemented the standards (i.e. poorly), bugs with corrupted images, and so on.
Think about that for a second; anyone can re-implement a PNG library by reading the specifications and learning how to do the math on the algorithms; there are probably people at Google who could write a complete PNG library in C inside of a week (they DO have some pretty brilliant people working for them). What they CAN'T do is go out and feed into that library all of the broken, corrupted, or just-a-little-bit-off PNG images that are out there on the web that require little tweaks and adjustments (or horrific workarounds) to process, and find all the fixes to all the glitches that end-users might see.
The extensive experience that the libpng developers have had over the lifetime of the project cannot be simply re-implemented from a textbook. THAT is why simply re-writing it is impractical, and THAT is why code re-use is a good thing. Expand that from PNG images out to every other shared library in the project, and 'not invented here' syndrome turns simple and straightforward bllet-point requirements for Android into a large-scale programming project, and makes the whole thing impractical.
Unless you reimplement it in Java. Which Android happens to run. (For the most part, anyway.)
While it's neither here nor there in relation to this story (and wouldn't perform very well, anyway), I just thought it was an interesting observation. Perhaps one day developers will stop looking at Java as a nice sandbox environment for tiny applications and start realizing that there are real benefits to deploying a high-performance JVM. Especially when HotSpot has already been ported to mobile devices...
Javascript + Nintendo DSi = DSiCade
And someday people will stop thinking of Java as a panacea for security issues.
How we know is more important than what we know.
For this type of problem? You bet your horse it is. Buffer overflow problems are so 1970's. Can we please move on?
Javascript + Nintendo DSi = DSiCade
Look how the iPhone handles firmware updates - plug in, download, click install. I think it's safe to assume that a Google-supported device is going to be rather heavily standards-based (I can't say I know much about Android), and as such will have a mini-USB port. Why overcomplicate things? As much as I like the idea of having my Google-centric data accessible everywhere over the air, they really need better interoperability in terms of desktop data syncing (Gmail is pretty good that way, but Gcal requires third-party tools, docs - understandably so - is limited to exporting rather than just mounting your Google account as a network drive, and contact management is pretty much worthless as it exists online, let alone syncing to Outlook or Address Book). As such, it's safe to assume that people are going to want to be able to pull that non-syncable data from their computer to their phone which means plugging in or at least WiFi proximity. Handle firmware updates that way. I'd say it's almost easier to infect a computer with a bad HOSTS file pointing androidupdates.google.com to some bad addressed with an apparently-legitimate SSL cert than to carry around a portable cell broadcasting station, but neither constitutes that much of a threat.
How are sites slashdotted when nobody reads TFAs?
This is already fixed in m5-rc15 which was released yesterday...
"I told you a million times not to exaggerate!"
That's just dumb. Introducing vulnerabilities in newly developed software is unfortunate, but it happens. Using software with known vulnerabilities when these vulnerabilities have been patched is just dumb. Any clues as to why they did this?
Please correct me if I got my facts wrong.
But it was fun, to show that even the all-mighty google can make mistakes. :" (She read slashdot daily, my girlfriend is that cool)
Btw, i dedicate this bug to my Girlfriend that forgive me the long nights that tookme to find and exploit this bug.
I love you glow!
Needs more jiggawats.
-Aegis Runestone-
My new smartphone is vulnerable to malicious haxx0rz! Oh wait, it runs Windows Mobile! I'm *so* relieved!!
No sig for you!!
That's why people make software open source.
I think the only thing that bothers me about Android is that the full source code has not been released yet, although Google claims they will be making that available.
... we can now build a program to hack it and build are own programs! yeah!
I'm going to call it "Gaolbreak"
Do you work for Microsoft?
If taxation is legalized theft, then Capitalism is a prolonged rape followed by a slow death.
That's why it would be good if many people would re-implement these libs directly from the specs. That would weed out incompatible files. That's one of the points of open architectures that content specifications not be tied to implementation.
Sometimes you just don't want your data to be compressed; you want to be able to tell the OS to load the data from storage and have it right there, ready for you to use. Sometimes you just can't afford the overhead of decompression. But PNG, reasonably enough (I suppose) for network graphics, requires all images to be compressed; you can't say "no compression".(*) BMP, on the other hand, is uncompressed by default; aside from the line order problems (which are easily solved by pre-flipping the image), that makes it perfect for cases like these. So that's what PNG doesn't do that BMP does.
(*) You can play games by attaching fake compression headers, sort of like what was done to work around the GIF compression patents. In fact, I did. But at that point, you might as well just use something like BMP which is uncompressed in the first place.
No, that would greatly increase the number of incompatible files as all those new implementations created fresh bugs and variations on ambiguous parts of the spec.
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
You just keep fighting the tide there. Lemme know how it works out. And see if you can roll back to rotary phones too since they clearly have the least sophisticated electronics and therefore are hardest to hack.
The three phones i've had over the past 10 years have all been reflashed wireless through the cell phone networks. You dial a number, select the upgrade firmware option, wait, the phone turns off, turns back on with new firmware installed. Why would you need to plug it? It is a wireless device, thats why its useful.
Several of the vulnerabilities in libPNG are exploitable integer overflow vulnerabilities. Java does absolutely nothing to stop those vulnerabilities. And even if it does, much of the java runtime is written in C, and is just as vulnerable to buffer overflows.
.Net, VB6, etc) are solutions to security problems. All they do is to raise the bar.
The grandparent was right: People should stop thinking that somehow interpreted languages (Java,
Yeah.
The JVM is a design that is logically proven to be 100% absolutely secure. If Java code can reach down and manipulate memory at the level of the JVM, then there is a serious flaw in the JVM's implementation. A flaw that means that it does NOT meet the Java spec. Thankfully, Sun has a Test Kit that checks for compliance before a VM can be called "Java". It does a pretty decent job of ensuring the correctness of a VM.Raising the bar is exactly what I'm talking about. Java is impervious to buffer overflows because it does NOT allow for memory management. Memory management is the responsibility of the JVM.
Oh, and Java is not interpreted. Strike 3, you're out.
Javascript + Nintendo DSi = DSiCade
The Web Developer plugin will give you information on every error encountered when rendering the page. I don't know if it has an option to do so loudly, but it certainly wouldn't be hard to modify.
Breaking Into the Industry - A development log about starting a game studio.
We had a vxWorks sales dog and pony show from WindRiver the other day, and they bragged about their Google Android contract (apparently, Google uses vxWorks Linux - which can be modified to their own needs). I had my laptop open and opened this story just as when they talked about it!
I know this is kinda off subject, but I could really use some help. A friends cell phone is showing text messages from my cell phone that I have never sent. I have even got a copy of the cell phone bill showing outgoing text messages and phone calls from my phone. I suspect my friend of 'phreaking' or hacking my cell phone to make this happen. Is this possible? Does anyone know how this could happen?"