Posted
by
Soulskillon Tuesday February 19, 2013 @09:47PM
from the spock-missed-some-updates dept.

Trailrunner7 writes "A vulnerability exists in some components of BlackBerry mobile devices that could grant attackers access to instances of the company's Enterprise Server (BES), according to BlackBerry, which issued an alert and released a patch for the vulnerability last week via its Knowledge Base support site. BES, the software implicated by the vulnerability, helps companies deploy BlackBerry devices. The high severity advisory involves the way the phone views Tagged Image File Format (TIFF) files, specifically the way the phone's Mobile Data System Connection Service and Messaging Agent processes and renders the images. An attacker could rig a TIFF image with malware and get a user to either view the image via a specially crafted website or send it to the user via email or instant message. The last two exploit vectors could make it so the user wouldn't have to click the link or image, or view the email or instant message, for the attack to prove successful. Once executed, an attacker could access and execute code on Blackberry's Enterprise Server."

I love my Z10, if I wasn't already on the BlackBerry band wagon, I am now.
It's worth noting that issues like this are usually found after they have been exploited to do severe damage, while as far as I've seen this is a pre-emptive warning by BlackBerry that they found an issue and fixed it. Instead of hiding it away and hoping no one notices.

I guess I don't understand. Short of a buffer overflow type attack, how would this work? I wasn't aware that TIFFs contained anything executable. And display s/w does one thing with TIFF data: splat it up on a screen.

Code has to run to display the image - all you need to do is format the data in a way such that the code which deals with it will end up overwriting parts of itself and then you can run whatever you want. It's very specific to a particular decoder on a particular device.

I don't know the means by which this particular attack is delivered. However, I know that the "unhackable" versions of Sony's PSP systems were finally hacked by a payloaded.TIFF file. I'd imagine there are some similarities, so you might want to look up how that hack worked.

Yeah, it's probably a buffer overflow attack of some kind. They trusted the file to contain accurate data about itself. Advisory says "specially crafted TIFF image" which, you know, pretty much backs that up. It's a sophomoric mistake but they might not have made it alone, they might have pulled in a TIFF handling library from someone lame.

Splatting TIFF [wikipedia.org] images is a complicated matter. They're more than just mundane dumps of pixel data. In addition to just storing the image data itself, they can hold many kinds of metadata, be compressed in many ways, and all encoded in either big-endian or little-endian byte order. Any of those features might trigger vulnerable code in a parser, which might allow a buffer overflow or other vulnerability. This is similar to problems with every other complex format out there, (in)famously including JPEG and Tr

Every now and again I keep getting people asking me "it's only a 2MB TIFF image so why is it hanging up my computer with 4GB of memory when I open it?". Sometimes that 2MB image is a monochrome 300dpi scan of a 42 inch by 12 foot plot and the braindead viewing software they choose tries to allocate 32 bits per pixel and just runs out of memory.

TIFF is more of a meta format (think AVI - it can be uncompressed, or use a range of codecs).Its extreme flexibility makes it very easy to over look something in the code. It is always a buffer overflow that is created.

Unsurprisingly, the summary and TFA get it wrong. The vulnerability is not in devices. "Messaging Agent" and "MDS Connection Service" are server side components - the vulnerability is there, and not on the phone.

The phone can trigger them because web browsing on a BES-connected device goes through the MDS connection service, so a properly crafted web page can compromise the the MDS service on the server.

Similarly, sending an email will get routed through messaging agent - which is why a crafted email can trigger this without the email being opened on the client device.

Why would the server render images? That is a piece of client-side functionality.

At a guess, in order to compress them further so that the mobile device (which is always relatively short of bandwidth) doesn't run into problems if browsing a site with lots of large images. "Rendering" in this case doesn't have to mean displaying them on a screen, of course...

At a guess, in order to compress them further so that the mobile device (which is always relatively short of bandwidth) doesn't run into problems if browsing a site with lots of large images. "Rendering" in this case doesn't have to mean displaying them on a screen, of course...

Don't forget to also conserve memory, processor and storage space on the device. If you're going to view an image on a tiny QVGA or HVGA screen, do you really need to send down the entire 16MP image? Or just have the server downscale

Unsurprisingly, the summary and TFA get it wrong. The vulnerability is not in devices. "Messaging Agent" and "MDS Connection Service" are server side components - the vulnerability is there, and not on the phone.

The phone can trigger them because web browsing on a BES-connected device goes through the MDS connection service, so a properly crafted web page can compromise the the MDS service on the server.

Similarly, sending an email will get routed through messaging agent - which is why a crafted email can trigger this without the email being opened on the client device.

I'm going to assume that most BES admins only use MDS connections for access to internal websites. So MDS should not really be vulnerable unless the company routes all web traffic through BES.

Everyone from libraries and archives such as the Library of Congress (hi-resolution uncompressed TIFFs are the designated master file format for the National Digital Newspaper Program [loc.gov] and the FADGI Still Image Working Group [digitizati...elines.gov] guidelines for digitizing cultural heritage materials) to document management companies and banks (as bitonal TIFFs are quite tiny compared to bloated garbage like PDF, offer great resolution of everyday office docs and checks, and work with most every im

Everyone from libraries and archives such as the Library of Congress (hi-resolution uncompressed TIFFs are the designated master file format for the National Digital Newspaper Program and the FADGI Still Image Working Group guidelines for digitizing cultural heritage materials)

Nice paper, but it feels a bit strange to read about PNG:

Possible format for production master file - not currently widely implemented.

It seems to me they recommend (not require) TIFF because TIFF is what they've always used, and their proprietary tools have good support for it.

Just because *you* don't use a file format anymore doesn't mean it's useless to others.

For the National Digital Newspaper Program, I can assure you that *not* submitting TIFFs as part of NDNP-spec output will fail the Library of Congress DVV (Digital Viewer and Validator) checks.;-) And all big institutions expect you to give them uncompressed, high color depth TIFF masters on other types of digitization work -- that's just the way it is. So yeah, while it's written as a recommendation, in practice it's a requirement. And there is a strong argument to be made that currently, for high-qual

Lots of scientists do, especially where exact capture is required, capture equipment and workflows are long-established, and space isn't especially at a premium. (Astronomy doesn't though; they use much nastier formats [wikipedia.org] for their stored primary data sources.)