Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Security Holes In Google's Android SDK

Zonk posted more than 6 years ago | from the patchy-the-leaky-robot dept.

Google 77

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

cancel ×

77 comments

Sorry! There are no comments related to the filter you selected.

yawn (4, Insightful)

QuantumG (50515) | more than 6 years ago | (#22646430)

Security holes in beta software you say? Wow.

Re:yawn (0)

Fleet Admiral (1020072) | more than 6 years ago | (#22646446)

Outdated software != beta software Please RTFSummary before posting

Re:yawn (2, Informative)

AKAImBatman (238306) | more than 6 years ago | (#22646458)

He was referring to Android, not the libraries. :-/

Re:yawn (1)

nawcom (941663) | more than 6 years ago | (#22646474)

"In all, Core Security lists eight different vulnerabilities identified in the Android SDK, which is currently in beta."

Outdated software != beta software Please RTFSummary before posting

Tell yourself that.

This SDK hasn't been completed. Nothing to read here.

Re:yawn (0)

Anonymous Coward | more than 6 years ago | (#22647014)

Nah, this was bound to happen with all the dead weight Google has hired.

They're the next Microsoft. They have exactly the same cowboy we're-the-best attitude that Microsoft had on the upswing.

Don't kid yourself, if you're at Google and you weren't hired as one of their rock stars, you're going to be the equivalent of a level 61 SDE at Microsoft for a very long time. It's a fucking sweatshop for people straight out of university, the junk they're shitting out recently proves it.

Re:yawn (1)

Jeremiah Cornelius (137) | more than 6 years ago | (#22650018)

True.

Also probably planned.

Google is practically a subcontractor for the NSA. Expect a Google phone to be a hotline to the datamine.

Re:yawn (5, Insightful)

Anonymous Coward | more than 6 years ago | (#22646498)

Security holes in beta software you say? Wow.

That would be a valid retort if it weren't for Google's perpetual beta mentality.

Re:yawn (2, Insightful)

AmaDaden (794446) | more than 6 years ago | (#22646610)

This is why they have a perpetual beta mentality. They know better then to call newly written software done. Public usage with a warning label is a good thing.

Re:yawn (4, Insightful)

Nullav (1053766) | more than 6 years ago | (#22647034)

They know better then to call newly written software done.
So three and a half years is early in the development process? I guess that means Hurd's only 'slightly behind schedule'.
Really, in the hands of Google, the 'beta' tag is only a way to keep things sounding 'hip and new' and to avoid liability when something screws up.

Re:yawn (4, Insightful)

AmaDaden (794446) | more than 6 years ago | (#22648218)

Did you hear what the plans are for android? It's an OS that is designed to fit nearly any phone hardware, to be configurable to anyones liking, AND can run home brewed Java apps. Four years is not a bad time, It is a MASSIVE undertaking. Personally I think that ALL software is severely under tested. It tends to be pushed out the door not because it's ready but because the higher ups want to start making money on it. How many times did you use software that is 'done' but swamped with bugs? That is beta software, even if they don't admit it.

Re:yawn (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22658978)

Android is useless. Regardless of hardware, it is Apple who has created the smartphone market, like they did with the iPod in the MP3 player arena.

Android is doomed to failure. The iPhone's OS is already proven bug free and 100 percent secure, so Google will be forever behind, similar to how Linux always lags behind MacOS in features.

Re:yawn (0)

Anonymous Coward | more than 6 years ago | (#22651894)

and to avoid liability when something screws up.
lol, when is the last time you've heard microsoft held liable for their commercial and enterprise products failing?

Re:yawn (1)

ceeam (39911) | more than 6 years ago | (#22648064)

I don't think that, unlike, for example, WebMail service, you can release a phone model with "Beta" label attached.

Re:yawn (1)

hey! (33014) | more than 6 years ago | (#22648384)

Except this isn't even beta.

I disagree with the assumption that security holes in beta software aren't serious. Beta -- in software at least -- means that real live users are using it.

However, at this point the software is not available to users; if the problem is that the system uses obsolete implementations for some of its APIs, the open source process has worked the way its supposed to. If the problem is inherent in some important APIs, that's a different kettle of fish.

Still, I expect Android to be a very important mobile platform, so it's news, but it's nothing to crow about/wring your hands over.

Re:yawn (2, Funny)

nacule (1249808) | more than 6 years ago | (#22646532)

| Security holes in beta software you say? Wow. Maybe this is why they kept gmail in beta till now. Perfect excuse for security holes

Re:yawn (1)

microbee (682094) | more than 6 years ago | (#22646840)

Except that Google's software is always in beta.

Re:yawn (1)

Mark3eb (1251132) | more than 6 years ago | (#22647138)

Isn't Google's software usually in Beta?

Re:yawn (1)

hal9035 (827327) | more than 6 years ago | (#22649204)

But we LOVE Google....... cut them slack......

Re:yawn (1)

somersault (912633) | more than 6 years ago | (#22650480)

And google mail has been 'beta' for how long? I'm sure nobody will mind a few security holes there, since it's a beta and all. This article isn't a problem as long as they sort it out quickly, but if they do a Microsoft and leave it in for the next few versions, that's when there's a problem.

Re:yawn (1)

devilspgd (652955) | more than 6 years ago | (#22655242)

It looks like they're trying to compete directly with the iPhone, image library buffer overruns and all! Sweet.

I'm not exactly sure how phone software works... (3, Interesting)

ZanySpyDude (1215564) | more than 6 years ago | (#22646440)

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?

Re:I'm not exactly sure how phone software works.. (2, Insightful)

AKAImBatman (238306) | more than 6 years ago | (#22646476)

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

Re:I'm not exactly sure how phone software works.. (2, Interesting)

Firehed (942385) | more than 6 years ago | (#22646686)

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.

Re:I'm not exactly sure how phone software works.. (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22646742)

Wow, is this supposed to be FUD?

Since when was it painful to flash firmware? And yeah, most motherboards and other devices support flashing from the OS, as long as that OS is Windows. I assume such a mechanism isn't as insane as you make it out to be.

But if you want to get ultra-technical, your typical general purpose piece of equipment is so full of security holes it's hilarious. I actually think it's a pretty big joke on the white hats that they aren't spilling out vulnerabilities all the time. Probably because they're disheartened by all the threats of lawsuits instead of actual action when they discreetly disclose them.

Security is a joke in the world we live in. If any smart person wants to spend a little time hacking something it will be hacked. Every video game console, Tivo, Windows, Windows Media Player, FairPlay, iPhone, Mac OS X, DVD, Bluray, HD-DVD, Intel CPUs (P4 and Core 2 bugs). All haxed. A sufficiently motivated person/organization/institution could pwn your laptop from wifi/bluetooth/wimax/cellular, turn on your webcam or mic remotely, flash your firmware, install keyloggers, load a root kit that hides it all. Yes, even yours, firewall + antivirus guy. Do you really think a rinky-dink cell phone manufacturer that makes a new model every 6 months is really going to magically protect you from that? You're not protected by good engineering you're protected by hacker disinterest.

But you know what? People make phone calls and use bluetooth. People play video games online. People listen to music. And we're all reading and typing this on Windows/Linux/Mac OS X/etc from our IE/Firefox/Safari/etc web browsers and the world continues to rotate.

(In short to answer your question: yes, they can attack via an update mechanism. Or just about a bazillion other vectors. And to answer the implied statement here, no, nobody seems to care. Not even the hackers.)

Re:I'm not exactly sure how phone software works.. (0)

Anonymous Coward | more than 6 years ago | (#22649530)

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.

Re:I'm not exactly sure how phone software works.. (1)

BadBadThing (1249998) | more than 6 years ago | (#22669278)

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

the point being? (1)

markybob (802458) | more than 6 years ago | (#22646454)

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

Re:the point being? (1)

LowlyWorm (966676) | more than 6 years ago | (#22646628)

It is true that the issue would not currently matter but smart phone technology will soon be big. Very big. It remains to be seen if Google can successfully make the transition into this area with so much competition from names like Apple, Research In Motion, Nokia, Palm and who knows who else by the time Android goes public.

IMHO Google has done a fairly good job in its software development (which is to say, I have personally had few issues). Being open source at least lets people know there is a problem. They will surly address the issue but there will likely be lots of such problems along the way.

Re:the point being? (1)

snl2587 (1177409) | more than 6 years ago | (#22646704)

I can't wait until telemarketers start using exploits to take over mobile phones to make mass calls. I can see the phone bills now...

Re:the point being? (1)

Peter Nikolic (1093513) | more than 6 years ago | (#22647538)

and that is exactly why so called smart phones should NOT EXIST and these viral telemarketers should all face a mandatory DEATH sentence whats that i hear well i aint gonna pull the lever no problem i will i dunnae give a fuck YMMV mine does NOT ! Pete

Yeah, sure. (0)

Anonymous Coward | more than 6 years ago | (#22647888)

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.

Re:the point being? (1)

LowlyWorm (966676) | more than 6 years ago | (#22648454)

Although they are generally tight lipped about it, carriers have traditionally handled responsibility for such exploits. As it becomes easier to "reach out and touch someone" anywhere in the world it will be interesting to see where the axe falls next.

Re:the point being? (1)

AndGodSed (968378) | more than 6 years ago | (#22646948)

And being open source these problems will be sorted out sooner and more effectively.

The exciting thing to me is that this Google project will introduce not only open source software, but open source thinking and open source culture to the masses.

And knowing Google, it will be successful, and being successful it will clear up many of the uninformed stigmas that cling to open source software - hopefully beginning with the kind of FUD that MS spouts.

Re:the point being? (0, Flamebait)

ajs318 (655362) | more than 6 years ago | (#22647334)

Except that isn't how Google work. Google only like software being Open Source when it has been written by other people.

Google wouldn't release so much as a single byte of Source Code, if it wasn't for the GPL making them do so. (Where's the Source Code for Picasa? Or Google Earth? Or any of the other "free" [as in, "this dog is free from lice"] software they give away?) In fact, I'm even surprised they're basing Android on Linux and not one of the BSDs. I guess it could just be an image thing, because Linux is much better known.

If Google ever sponsor a GPL project from the ground up, it is only because they want to be able to claim copyright on the code and therefore release it as Caged Software.

Re-using, Re-using, Not re-inventing the wheel, bl (-1, Troll)

El Cabri (13930) | more than 6 years ago | (#22646508)

I don't understand this obsession in software development, of always considering that if a piece of code exists somewhere that does what you want to do, and somehow you have the right to use it, then you must use it. Bitmap image libraries do not represent any expertise or rocket science that you won't find in a freshman textbook and that anybody with a bit of time on their hands cannot re-implement. Yes it's a pain in the ass and in many cases some people like hobbyist programmers who are trying to put together the ultimate "linux desktop" and such are happy to find them ready-to-use as free software. But Google ? Come on, they're supposed to have all these brilliant minds around. Everybody knows that PNG and JPEG libraries are major vulnerabilities. Pulling one off the shelf just to hack something together and show it in trade shows ? That is so lame. Come on Google and everybody else : invest a little bit and do "re-invent the wheel", just for the chance to do it alittle bit better this time.

Re:Re-using, Re-using, Not re-inventing the wheel, (3, Insightful)

QuantumG (50515) | more than 6 years ago | (#22646522)

Re-implement it and you'll likely have the exact same problems as this.. or worse.

Re:Re-using, Re-using, Not re-inventing the wheel, (5, Insightful)

Sentry21 (8183) | more than 6 years ago | (#22646594)

Re-implement it and you'll likely have the exact same problems as this.. or worse.
Specifically, the 'worse' problem you'll have is compatibility with broken implementations and corrupted data.

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.

Re:Re-using, Re-using, Not re-inventing the wheel, (1)

El Cabri (13930) | more than 6 years ago | (#22647686)

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.

Re:Re-using, Re-using, Not re-inventing the wheel, (1)

AaronLawrence (600990) | more than 6 years ago | (#22647824)

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.

Re:Re-using, Re-using, Not re-inventing the wheel, (0)

Anonymous Coward | more than 6 years ago | (#22647836)

I'd like to have a firefox version that breaks at every single misstep. Seems very useful for web development. Is there any project similar to this?

Re:Re-using, Re-using, Not re-inventing the wheel, (1)

ZorbaTHut (126196) | more than 6 years ago | (#22650538)

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.

Re:Re-using, Re-using, Not re-inventing the wheel, (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22651660)

> 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

Except that they actually DO have all of the images out there on the web, in a
nice local, searchable, database, and a supercomputer to acess them with.
It's nice to be Google (well, sometimes).

Re:Re-using, Re-using, Not re-inventing the wheel, (2, Interesting)

AKAImBatman (238306) | more than 6 years ago | (#22646602)

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 [sun.com] has already been ported to mobile devices...

Re:Re-using, Re-using, Not re-inventing the wheel, (1)

QuantumG (50515) | more than 6 years ago | (#22646618)

And someday people will stop thinking of Java as a panacea for security issues.

Re:Re-using, Re-using, Not re-inventing the wheel, (3, Informative)

AKAImBatman (238306) | more than 6 years ago | (#22646636)

For this type of problem? You bet your horse it is. Buffer overflow problems are so 1970's. Can we please move on?

Re:Re-using, Re-using, Not re-inventing the wheel, (1)

LO0G (606364) | more than 6 years ago | (#22649784)

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.

The grandparent was right: People should stop thinking that somehow interpreted languages (Java, .Net, VB6, etc) are solutions to security problems. All they do is to raise the bar.

Re:Re-using, Re-using, Not re-inventing the wheel, (2, Interesting)

AKAImBatman (238306) | more than 6 years ago | (#22650120)

Several of the vulnerabilities in libPNG are exploitable integer overflow vulnerabilities. Java does absolutely nothing to stop those vulnerabilities.
Bull. Java will overflow the integer, but how exactly will it result in an underflow or an overflow of a memory buffer if Java does not have pointers? All you have is a negative value. At best you'll cause an IndexArrayOutOfBoundsException when you attempt to access an invalid array location. At worst, the code will detect it as an invalid value and move on.

And even if it does, much of the java runtime is written in C, and is just as vulnerable to buffer overflows.
Oh noes! Not C! That must make it, like, automagically vunlnerables!

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.

People should stop thinking that somehow interpreted languages (Java, .Net, VB6, etc) are solutions to security problems. All they do is to raise the bar.
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.

Re:Re-using, Re-using, Not re-inventing the wheel, (0)

Anonymous Coward | more than 6 years ago | (#22652082)

I agree with you that the JVM is 100% immune to buffer overflows itself. However when the JVM is using crappy, C-written, third party libs, then these libs are subject to buffer overflows and hence remote control can be obtained by carefully crafting bad data (it's not Java at fault, it's the third-party C-written lib). If, say, I'm a local user your Java app and there's an buffer overflow vulnerability in the PNG C-written lib allowing priviledge escalation (it's just hypothetic), I can make your Java app parse my carefully crafted image using that insecure lib and exploit whatever security flaw that lib has (it's the 3rd party lib I'm directly attacking, not the Java code, that is immune to such 30-years exploits).

Now of course that is not Java's fault...

I personally think that way too much third-party, non-Java, libs are used and that it would be better to rewrite them in Java.

Re:Re-using, Re-using, Not re-inventing the wheel, (0)

Anonymous Coward | more than 6 years ago | (#22659842)

Bull. Java will overflow the integer, but how exactly will it result in an underflow or an overflow of a memory buffer if Java does not have pointers? All you have is a negative value. At best you'll cause an IndexArrayOutOfBoundsException when you attempt to access an invalid array location. At worst, the code will detect it as an invalid value and move on.
Most of the underlying implementations for things like image formats actually use C libraries due to their speed.

Oh noes! Not C! That must make it, like, automagically vunlnerables! 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.
Bzzt. The same sorts of vulnerabilities are possible each time you take an input that is handled by 'unmanaged' code, like a library written in C and exported via Java classes to your app.

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.
This is extremely implementation dependent.

Re:Re-using, Re-using, Not re-inventing the wheel, (0)

Anonymous Coward | more than 6 years ago | (#22660134)

Most of the underlying implementations for things like image formats actually use C libraries due to their speed.
That's why they're discussing Hotspot, moron. Hotspot >= Native Code

Bzzt. The same sorts of vulnerabilities are possible each time you take an input that is handled by 'unmanaged' code, like a library written in C and exported via Java classes to your app.
Thus the reason why the entire thread is about writing the fucking libraries in Java. Learn to fucking read, will you?

Re:Re-using, Re-using, Not re-inventing the wheel, (1)

Evil_Ether (1200695) | more than 6 years ago | (#22647644)

Do you work for Microsoft?

Who The Hell Is Still Using BMP? (5, Funny)

ewhac (5844) | more than 6 years ago | (#22646586)

Several vulnerabilities have been found in Android's core libraries for processing graphic content in some of the most used image formats (PNG, GIF an BMP)

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

Re:Who The Hell Is Still Using BMP? (3, Funny)

totally bogus dude (1040246) | more than 6 years ago | (#22647204)

But then we couldn't have fun watching images load from the bottom up! It looks so cool and is totally worth a few extra (mega)bytes!

People who need uncompressed images. (1)

achurch (201270) | more than 6 years ago | (#22647776)

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 [achurch.org] . But at that point, you might as well just use something like BMP which is uncompressed in the first place.

Re:People who need uncompressed images. (0)

Anonymous Coward | more than 6 years ago | (#22647948)

But at that point, you might as well just use something like BMP which is uncompressed in the first place.

Tiff would be fine in that case

Re:People who need uncompressed images. (1)

repka (1102731) | more than 6 years ago | (#22648826)

Unlike TIFF, BMP is one of the easiest formats to read, on par with formats like PCX and TGA.
Which begs the question: how would you end up with a vulnerability in processing of such format, when validating of your inputs does not require much effort?

Re:People who need uncompressed images. (1)

LWATCDR (28044) | more than 6 years ago | (#22739714)

Not being able to afford the overhead of compression is a pretty rare case. Often you can get around it by pre loading the image. Not saying that an uncompressed format would never be useful but it without a doubt a rare case and not one I can imagine comming up on Android.
But heck if you must use an uncompress format then just us IFF and be done with it :)

Re:Who The Hell Is Still Using BMP? (2, Funny)

JNighthawk (769575) | more than 6 years ago | (#22648816)

It's a fantastic way to learn how to parse and render an image. You get all the basics, plus you get to try and find out why your texture is rendering upside down :-)

Re:Who The Hell Is Still Using BMP? (0)

Anonymous Coward | more than 6 years ago | (#22660924)

Actually, sometimes I convert an image to bmp and compress it with bzip2. The result can be surprisingly smaller then png. Maybe these images can be served that way (or with gzip) if the browser says so in its Accept-encoding and Accept-type headers, but I haven't tried that yet.

Re:Who The Hell Is Still Using BMP? (1)

Bearhouse (1034238) | more than 6 years ago | (#22714442)

Why was this modded funny? Give him some 'insightful' points as well guys.

It's fixed, so stop whining!!!!!!! (0)

Anonymous Coward | more than 6 years ago | (#22646670)

Vulnerable packages # Android SDK m3-rc37a and earlier are vulnerable several bugs in components that process GIF, PNG and BMP images (bugs #1, #2 and #3 of this advisory). # Android SDK m5-rc14 is vulnerable to a security bug in the component that process BMP images (bug #3). Non-vulnerable packages # Android SDK m5-rc15

Already fixed (5, Informative)

Zach978 (98911) | more than 6 years ago | (#22646694)

This is already fixed [blogspot.com] in m5-rc15 which was released yesterday...

Re:Already fixed (1, Informative)

microbee (682094) | more than 6 years ago | (#22646844)

Now we know how slow Slashdot editors are.

Re:Already fixed (1)

initialE (758110) | more than 6 years ago | (#22646890)

It's more likely that the hole was reported to the project maintainers before being publicly released, giving them a chance to fix it

Re:Already fixed (1)

definate (876684) | more than 6 years ago | (#22647046)

And so we see the benefits in open source software, a bug was found before it was even out in the wild, and fixed.

Hoorah for google and open source software.

Re:Already fixed (2, Insightful)

Zach978 (98911) | more than 6 years ago | (#22647064)

well, unfortunately the source for Android isn't out yet...so Hoorah for them when they release the source!!

Re:Already fixed (1)

bandersnatch (176074) | more than 6 years ago | (#22647150)

As Marvin the Paranoid Android might say -- Don't Panic

Dumb (0)

RAMMS+EIN (578166) | more than 6 years ago | (#22646720)

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?

Re:Dumb (2, Informative)

initdeep (1073290) | more than 6 years ago | (#22652084)

anybody who read the bugtraq submission of the flaws would no that google themselves responded with a comment that they knew they were using old version of the libraries adn that they were planning on updating them in the next release.

They also pointed out that this iss not BETA code, but merely a release of propsed code to allow potential devlopers to add their insights to the project on which direction the code should go on various portions.

The libraries have now been replaced (evidently) with the newer ones, which probably doens't mean a damn thing as there are no currently available public platforms running the software and won't be for a while.

calling this dumb is a bit overkill.

This was a though one (1)

cachimaster (127194) | more than 6 years ago | (#22646732)

But it was fun, to show that even the all-mighty google can make mistakes.
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! :" (She read slashdot daily, my girlfriend is that cool)

This... (1)

Aegis Runestone (1248876) | more than 6 years ago | (#22646766)

Needs more jiggawats.

Oh noes! (1, Funny)

aztektum (170569) | more than 6 years ago | (#22646772)

My new smartphone is vulnerable to malicious haxx0rz! Oh wait, it runs Windows Mobile! I'm *so* relieved!!

that's why it's open source (4, Interesting)

nguy (1207026) | more than 6 years ago | (#22646970)

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.

Re:that's why it's open source (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22724686)

how old is the iphone and google is already righgt with apple because apple only recently released sdk for the smudgy iphone. people wants apps and android is starting with that before they even have a set phone for it really.

GOOGLE WINS and apple fails (yes I am biased against apple)

you know what this means... (1)

mahju (160244) | more than 6 years ago | (#22647176)

... we can now build a program to hack it and build are own programs! yeah!
I'm going to call it "Gaolbreak"

vxWorks (0)

Anonymous Coward | more than 6 years ago | (#22653578)

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!
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>