Slashdot Mirror


Multiple FLAC Vulnerabilities Affect Every OS

Enon writes "eEye Digital Security has discovered 14 vulnerabilities in the FLAC file format that affect a huge range of media players on every supported operating system (Windows, Mac OS, Linux, Unix, BSD, Solaris, and even some hardware players are vulnerable). Heise points out a number of vulnerable apps that use the open source libavcodec audio codec library, which in turn relies on the flawed libFLAC library. These vulnerabilities could allow a person of ill will to trojanize FLAC files that could compromise your computer if they are played on a vulnerable media player. eEye worked with US-CERT to notify vulnerable vendors."

8 of 360 comments (clear)

  1. Sanity checks: by andreyvul · · Score: 5, Insightful

    Perform them.

    --
    proud caffeine whore
  2. Re:But I thought that this didn't happen with FOSS by Locklin · · Score: 5, Insightful

    Not that I like feeding trolls, but wake up, no one here think's FLOSS == perfect security, that's why both my Ubuntu and Fedora machine get software updates on a regular basis. The primary difference between FLOSS and proprietary security is transparency: do you know how many ten year old bugs are sitting in Windows or IE which Microsoft refuses to fix? Unless you work for them, you likely don't have a clue.

    --
    "Knowledge is the only instrument of production that is not subject to diminishing returns" -Journal of Political Econom
  3. Old McDonald Had a Farm by Lachryma · · Score: 5, Funny

    eEye worked with US-CERT to notify vulnerable vendors.
    If this happened over email, one could consider it eEye e-I/O.
  4. Phew by Frogbert · · Score: 5, Funny

    Good thing no one uses this esoteric "FLAC" format.

  5. guard pages, bit masks, and so on: better by r00t · · Score: 5, Informative

    Lots of people screw up the sanity checks. C has some interesting properties that people struggle with: signed+unsigned promotes to unsigned, and the compiler is allowed to generate code which assumes that signed wrap-around will never happen. Plus people just plain screw up. I'll bet the FLAC code even had sanity checks, just not correct ones.

    Sanity checks are also low-performance.

    Suppose you want a 1 MB buffer. Allocate that, plus 2 pages, plus another page if your allocator doesn't give you page alignment. (mmap does, malloc does not -- you should use mmap to be 100% legit here) Round up to a page if you used malloc. Make that page unreadable via the mprotect call. The next page will start your 1 MB buffer. After the end of that buffer is one more page that you also make unreadable. Now you're safe from regular overflows in that buffer.

    You still risk jumping out of the buffer when you add a potentially big offset. Here, you use the mask. Take an offset into the buffer, add/subtract the untrusted data, mask with 0xfffff for 1 MB, and now you have a fresh new offset that will be within the buffer.

    Regular overflows will hit the unreadable page. If you do nothing extra, the result is a safe crash. You might use the fork call to create a child process that you don't mind losing. Alternately, you can use sigsetjmp and siglongjmp to handle the situation. Set up a signal handler for signal 11 that will call siglongjmp. Call sigsetjmp prior to entering the code which handles untrusted data. If the code takes the exception path (signal and siglongjmp), then you know the untrusted data was bad. (for extra points, verify that the guard page was hit and call _exit if not -- see the sigaction documentation for how to get this info)

  6. Re:But I thought that this didn't happen with FOSS by BlueParrot · · Score: 5, Insightful

    So this is really ironic - Its my understating from reading hundreds and hundreds of /. posts that this isn't supposed to happen with FOSS. Only Micro$oft developers are supposed to have security bugs like this.


    You misunderstood. Where FLOSS differs from microsoft is:

    a)This bug was discovered by third parties because they had access to the source
    b)The bug is already fixed
    c)Even on still vulnerable systems it wouldn't give you root access
    d)It would have to rely on special plugins or user action
    e)The problem is clearly described and documented allowing users to take precautions

    Compare this to a vaguely described bug in your rendering engine for animated cursors enabling arbitrary webpages to compromise kernel space, and this not being fixed for days or even weeks despite documented exploits in the wild.

    Somehow I don't see the irony.

  7. Re:root listens to audio? by paulgrant · · Score: 5, Funny

    or play a video with flac as the audio algorithm.
    right.
    especially if it plays silence on a transparent pixel.
    MAN THIS SUCKS.

  8. Some things in life, money can't buy... by Mr2001 · · Score: 5, Funny

    Subscription to Stereophile magazine: $10.

    Additional hard drive to store your lossless music collection: $200.

    Portable audio player that supports FLAC: $300.

    High-end headphones and speakers necessary to hear the difference between MP3/AAC and FLAC: $1000.

    Gold shielded power, speaker, and headphone cables to avoid picking up noise that masks the differences between MP3/AAC and FLAC: $2000.

    Watching all that equipment turn into one big zombie spambot as soon as you press "play": priceless.

    --
    Visual IRC: Fast. Powerful. Free.