BlackBerry TIFF Vulnerability Could Allow Access To Enterprise Server 41
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."
Good news, we're all safe (Score:1, Funny)
Fortunately, no one uses Blackberry anymore.
Re:Good news, we're all safe (Score:5, Interesting)
I'm guessing you are still in US where Z10 is not yet launched, however out here in Canada, I am seeing a lot of Z10 with everyone.
Re: (Score:1, Informative)
Re: (Score:1)
Yummy spiff!
Re:Good news, we're all safe (Score:5, Informative)
Re: (Score:2)
Interestingly enough - and not mentioned in the summary - this doesn't impact BES 10. It's only BES for legacy devices that are affected.
Considering BES 10 doesn't support Legacy devices and this is corporates we're speaking about, 'only' probably is the wrong word to be using here.
Re: (Score:1)
Re: (Score:2)
Fire the SCSI!
Re: (Score:1)
You don't attack Enterprise with phasers, you use disruptors or plasma torpedos. Traitor.
TIFF with Malware? (Score:2)
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.
Re: (Score:3, Informative)
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.
Re: (Score:2)
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.
Re: (Score:2)
One of the early iDevice jailbreaks was also done with a malformed .TIFF; just load the website it was embedded in, and game over man...
Re: (Score:2)
The same guy developed both - the PSP one and the iOS 1.0 one.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Sure but then you can't have self-modifying code and where's the fun in that?
TIFF is always vulnerable (Score:1)
The TIFF format has had implementation vulnerabilities since basically the beginning of time. Perhaps it's just too complex!?
TFA and summary are incorrect (Score:5, Informative)
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.
Re: (Score:1)
Patch available. Non-issue.
it was an issue last month. and last year. and last decade.
Re: (Score:2)
Why would the server render images? That is a piece of client-side functionality.
Re: (Score:2)
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...
Re: (Score:2)
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
Re: (Score:2)
The server doesn't render them but it does parse them, likely (I'm not sure) to provide compression for the client.
Re: (Score:2)
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.
But yes, email would still be vulnerable.
Tiff???? (Score:2, Insightful)
Re: (Score:3)
Who on earth uses Tiff anymore?
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
Re: (Score:2)
Who on earth uses Tiff anymore?
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:
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.
True, and as long as libtiff exists it's not a big problem.
Re: (Score:2)
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
Re: (Score:2)
Who on earth uses Tiff anymore?
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.)