Slashdot Mirror

← Back to Stories (view on slashdot.org)

BlackBerry TIFF Vulnerability Could Allow Access To Enterprise Server

Posted by Soulskill on 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."

41 comments

  1. Good news, we're all safe by Anonymous Coward · · Score: 1, Funny

    Fortunately, no one uses Blackberry anymore.

    1. Re:Good news, we're all safe by Anonymous Coward · · Score: 0

      Except for this guy.

    2. Re:Good news, we're all safe by mrops · · Score: 4, 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.

    3. Re:Good news, we're all safe by PsychoSlashDot · · Score: 4, Informative

      Interestingly enough - and not mentioned in the summary - this doesn't impact BES 10. It's only BES for legacy devices that are affected.

      --
      "Oh no... he found the .sig setting."
    4. Re:Good news, we're all safe by Techman83 · · Score: 1

      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.

      --
      # cat /dev/mem | strings | grep -i cat
      Damn, my RAM is full of cats. MEOW!!
    5. Re:Good news, we're all safe by scream+at+the+sky · · Score: 1, Informative

      I was issued a Z10 from work the day before it launched (I work for Bell Canada, a lot of us were issued the device) and I'm absolutely in love with the device. It's been a huge success sales wise.

      --
      I wish I was a neutron bomb, for once I could go off...
    6. Re:Good news, we're all safe by davester666 · · Score: 1

      Yummy spiff!

      --
      Sleep your way to a whiter smile...date a dentist!
    7. Re:Good news, we're all safe by Unknown1337 · · Score: 1

      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.

  2. Enterprise server? by Anonymous Coward · · Score: 0

    Awesome! Fire phasers!

    1. Re:Enterprise server? by Divebus · · Score: 1

      Fire the SCSI!

      --

      Most of the stuff on /. won't survive first contact with facts.
    2. Re:Enterprise server? by Anonymous Coward · · Score: 1

      You don't attack Enterprise with phasers, you use disruptors or plasma torpedos. Traitor.

  3. TIFF with Malware? by PPH · · Score: 1

    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.

    --
    Have gnu, will travel.
    1. Re:TIFF with Malware? by Anonymous Coward · · 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.

    2. Re:TIFF with Malware? by ilovepi · · 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.

    3. Re:TIFF with Malware? by drinkypoo · · Score: 2

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:TIFF with Malware? by fuzzyfuzzyfungus · · Score: 1

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

    5. Re:TIFF with Malware? by Sarten-X · · Score: 2

      Splatting TIFF 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 TrueType, to name a few.

      From reading TFA, it looks like the server itself is vulnerable because it processes the TIFF fully before it's re-encoded to be sent to the mobile devices. There are two vulnerabilities, both of which are buffer overflows.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    6. Re:TIFF with Malware? by Anonymous Coward · · Score: 0

      go back a ways, the original tiff and gif spec allowed for embeddable macros and executable in the image format, not sure who thought that was a good idea. I used to embed mp3's in valid gif files, when loaded in certain players, they worked fine to play the music.

    7. Re:TIFF with Malware? by cheater512 · · Score: 1

      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.

    8. Re:TIFF with Malware? by TJamieson · · Score: 1

      The same guy developed both - the PSP one and the iOS 1.0 one.

      --
      For the last time, PIN Number and ATM Machine are redundancies!
    9. Re:TIFF with Malware? by dbIII · · Score: 1

      Funny really - we've got one story about patenting a 1970s implementation and another about an exploit using the 1970s problem of buffer overflow.

    10. Re:TIFF with Malware? by dbIII · · Score: 1

      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.

  4. Paging Herr von Neumann by Anonymous Coward · · Score: 0

    If you separate your code and data, this doesn't happen.

    1. Re:Paging Herr von Neumann by lxs · · Score: 1

      Sure but then you can't have self-modifying code and where's the fun in that?

  5. TIFF is always vulnerable by Anonymous Coward · · Score: 1

    The TIFF format has had implementation vulnerabilities since basically the beginning of time. Perhaps it's just too complex!?

    1. Re:TIFF is always vulnerable by Anonymous Coward · · Score: 0

      Many years ago GIF had the same sort of issue (not exactly the same) in Windows. I switched from Windows to Linux in part because I was fed up with the joke that was MS security. And then Linux had the same flaw. Oh well.

  6. TFA and summary are incorrect by thePowerOfGrayskull · · Score: 4, 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.

    1. Re:TFA and summary are incorrect by cstdenis · · Score: 1

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

      --
      1984 was not supposed to be an instruction manual.
    2. Re:TFA and summary are incorrect by dkf · · Score: 1

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

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    3. Re:TFA and summary are incorrect by thePowerOfGrayskull · · Score: 1

      The server doesn't render them but it does parse them, likely (I'm not sure) to provide compression for the client.

    4. Re:TFA and summary are incorrect by tlhIngan · · Score: 1

      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 the image so you're not stuck downloading megabytes of images over a potentially slow and high-latency link.

      The other thing is the software on the mobile side can be lighter weight - it only has to decode a few formats while the server converts many more down to the few supported.

    5. Re:TFA and summary are incorrect by acoustix · · Score: 1

      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.

      --
      "A plan fiendishly clever in its intricacies"- Homer Simpson
  7. For anyone wondering why this is a big deal... by Anonymous Coward · · Score: 0

    In enterprise deployments, the BES is where the encryption of stuff exchanged with the phone is done. So if you can hack the BES, you can theoretically read all of the "secure" mail, of all the users, while it is in an unencrypted state. Actually doing it might be pretty difficult, but not beyond the resources of a state actor/APT.

  8. And it's patched by Anonymous Coward · · Score: 0

    Patch available. Non-issue.

    1. Re:And it's patched by gl4ss · · Score: 0

      Patch available. Non-issue.

      it was an issue last month. and last year. and last decade.

      --
      world was created 5 seconds before this post as it is.
  9. Tiff???? by flyingfsck · · Score: 1, Insightful

    Who on earth uses Tiff anymore? Tiff was the most convoluted mess ever and should be executed by firing squad.

    --
    Excuse me, but please get off my Pennisetum Clandestinum, eh!
    1. Re:Tiff???? by PeeAitchPee · · 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) 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 imaging software written in the past 20 years). Just because *you* don't use a file format anymore doesn't mean it's useless to others.

    2. Re:Tiff???? by dkf · · Score: 1

      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 for their stored primary data sources.)

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    3. Re:Tiff???? by jgrahn · · Score: 1

      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:

      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.

      True, and as long as libtiff exists it's not a big problem.

    4. Re:Tiff???? by PeeAitchPee · · Score: 1

      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-quality raster image files, there's nothing better or more compatible.

      We do hear about JPEG2000 lossless being discussed as a replacement for uncompressed TIFF as a master file format, but the format isn't mature and keeps changing as different vendors keep introducing their own "superior" engine. So for now, outside of the NDNP world, everyone uses ImageMagick for JPEG2000 derivatives. I've never seen PNG used in the cultural heritage community -- in fact, I've only seen it used as one would expect -- a GIF replacement for web graphics due to its support for transparency (and previously, its patent-free status).