Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Security IT

Multiple FLAC Vulnerabilities Affect Every OS 360

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."
This discussion has been archived. No new comments can be posted.

Multiple FLAC Vulnerabilities Affect Every OS

Comments Filter:
  • Sanity checks: (Score:5, Insightful)

    by andreyvul ( 1176115 ) <andrey.vul@[ ]il.com ['gma' in gap]> on Monday November 19, 2007 @10:07PM (#21415581)
    Perform them.
    • by r00t ( 33219 ) on Monday November 19, 2007 @10:42PM (#21415869) Journal
      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)
      • Re: (Score:2, Flamebait)

        by pclminion ( 145572 )

        None of what you just described counts as a "sanity check." It's more like putting an immensely complicated band-aid on the problem so that when things do explode they explode in a predictable way. This can be a good thing in certain fields. If failure of your software might cause somebody's death, then yes, you want complete assurance that things cannot silently go wrong. But failing that, this is nothing but a poor substitute for good coding practice.

        If you have so much doubt in your own code, why do yo

        • by r00t ( 33219 ) on Monday November 19, 2007 @11:50PM (#21416411) Journal
          It's well-known that people tend to botch sanity checking. Thus, we should seek alternatives.

          My solution is far less complicated in total. Yeah, setting up a guard page isn't taught in Programming for Dummies. It's not a lot of code though, it's easy to test, and it's damn reliable.

          People who write secure code try to avoid having to trust themselves to get everything right. People who write insecure code think that somehow, despite decades of failure, they'll get it all right. Look ma, no bugs! Sure...
        • Re: (Score:3, Insightful)

          by sowth ( 748135 )

          Aren't we prideful. Do you work for Microsoft or something? Everyone makes mistakes. In the real world, you should program in as many sanity checks as you can. Over compensating for potential problems will usually lead to more secure and stable programs, or at the very least make it fail in a less catastrophic way.

          Expecting sanity checks to be done elsewhere and not covering your ass leads to absurdly buggy programs and security compromises, which is happening all too often in so called "professonal" soft

  • How often does root listen to audio, esp. considering the new and improved root-like access Ubuntu and Fedora have set up?

    Oh, you mean that a USER could compromise THEIR PERSONAL FILES... well, that does suck, but you have backups, right?

    • by springbox ( 853816 ) on Monday November 19, 2007 @10:13PM (#21415639)

      root listens to audio?

      Yes. Windows.

      • by gnuman99 ( 746007 ) on Monday November 19, 2007 @10:33PM (#21415815)

        root listens to audio?
        Yes. Windows.

        No. Vista.

        And no you will not get one of them "You want to proceed with blah?" windows because an exploit will not have a manifest. It is difficult to get Vista hosed by malware compared to XP.
        • Re: (Score:2, Funny)

          by definate ( 876684 )
          It seems you're writing a pro Vista comment...

          We don' like yo' type 'roun' 'ere, yew best keep moving.

          Man, I hope I got my punctuation of the accent correct, or I am going to get reamed by Grammar Nazi's.
        • No. Vista.

          Yes. Windows.

          root listens to audio?

          Vista has some security improvements if Vista is used correctly, but MS still missed the boat in a big way.

          The fundamental problem is people running under an admin account. Vista does not solve this basic problem.

          When you install Vista (or run for the first time), it guides you through creating an account. If you actually read the dialog (hint: most people won't), it tells you that this first account is an admin account. The problem is that for most folks

          • Why even have an admin account? On the Mac Mini we have at work, root was disabled by default. With many Linux boxes, you create a root password, but never login as root, and if you try, you will get dire warnings about how bad of an idea it is. Most Linux boxes rely on sudo to get most of the administrative actions done, with some being left to su root. There's no reason to even have an admin account that the user can log in to through the GUI. Take away the ability for users to log in as root, and yo
            • More importantly, most Linux install programs guide the user through making both a root and regular user account as part of the install process.

              That's where MS really dropped the ball. Their install wizard doesn't make sure that important step is taken care of.

              When they are starting their computer for the first time, typical users just want to start using the system, so if you don't force them to create a regular user account, it's not going to happen.

              The release of Vista provided MS with a golden oppo

      • by paulgrant ( 592593 ) on Monday November 19, 2007 @10:52PM (#21415941)
        or play a video with flac as the audio algorithm.
        especially if it plays silence on a transparent pixel.
    • by QuantumG ( 50515 ) <qg@biodome.org> on Monday November 19, 2007 @10:22PM (#21415705) Homepage Journal
      This is an example of the term "failure of imagination."

      Someone malicious can craft a .flac file which can execute arbitrary code when it is run on an affected player.

      That someone can give that .flac file to someone else who doesn't know it is maliciously crafted and when they play the file, they have given arbitrary code execution privileges to the malicious crafty person.

      I thought everyone got that from the description, but there will always be some ignorant fool who can't help but speak up and, here's the great part, there will always be someone who is even more stupid who mods them up.

      That's the magic of Slashdot.

      • Re: (Score:3, Funny)

        by Gothmolly ( 148874 )
        What you just described is a virus, and in fact, has existed nearly as long as computers have. If you don't trust your flac-giving buddy, why take anything he gives you at all? The point is that "flac" cannot compromise your system, only your data. Unless you play the file as root.
      • How does the code get access to anything but the *executing user's* files? It gets the same privileges as the program has been granted by the user/admin, but unless something is really wonky in the system, it does not have an avenue of getting more rights.

        Please, instead of assuming that you have parsed other people's thoughts correctly and hastily call them ignorant fools, try to see it from their side. It adds nothing positive to a debate.
        • by QuantumG ( 50515 )
          no-one said it did.

          Someone getting the ability to run arbitrary code on your machine is a security issue..

    • Re: (Score:3, Funny)

      by Goaway ( 82658 )
      So what exactly is that that you think malware wants to do that it can do as root but not as a user?
      • by Erpo ( 237853 )
        • nmap -sS
        • insmod rootkit.ko
        • rm -rf /home/roommate
        ...just off the top of my head.
        • echo "export LD_PRELOAD=/home/you/rootkit.so" >> /home/you/.bashrc
          echo "export LD_PRELOAD=/home/you/rootkit.so" >> /home/you/.bash_profile

          From there, all your processes contain rootkit.so as a library. It can replace functions in the C library. Your editor won't open /home/you/.bashrc when you ask it to; it will instead open a different file.

          You're so pwn3d.

          You'd be safe if you had Bitfrost, like the OLPC XO does. There, apps don't get to mess with your files except

    • of my private keys, finance data, NDA-protected stuff, etc.

      No problem?

      Heck, the attacker will be making extra backups! For free!
    • Oh, you mean that a USER could compromise THEIR PERSONAL FILES... well, that does suck, but you have backups, right?

      "That hacker stole all my steamy emails between me and my mistress and threatened to tell my wife unless I pay him $10,000! Thank God at least I have backups!"

    • Because, of course, privilege escalation bugs have never EVER cropped up.

      But that's merely a technical argument in an area where psychology reigns supreme. And the moment you assume the attitude of "It's not worth giving a damn because careful users won't have issues", you already lost that game.

  • Jailbreak!! (Score:3, Interesting)

    by evw ( 172810 ) on Monday November 19, 2007 @10:11PM (#21415621)
    Possibly another way to jailbreak your iPhone or install Linux on your iPod.

    • Re: (Score:3, Informative)

      by Winckle ( 870180 )
      Apple doesn't support FLAC, they want people to use the Apple lossless codec. Which annoys me tbh, there's no technical reason why they can't play both.
      • by empaler ( 130732 )
        I installed this but never really use iTunes for anything except syncing my Audio books to my iPod, but here:
        Xiph.Org QuickTime Components [xiph.org]. Should do the trick.
        HTH :)
  • by Anonymous Coward
    Is that they're still lossless.
  • Maybe I don't fully understand compression theory and this may very well be off topic, but this doesn't sound possible:

    "losslessly compressed" audio file format.

    Can someone explain how this compares to the original recording?
    And am I confusing the analog to digital information loss with the compression (loss) part?
    • Re: (Score:3, Informative)

      by Locklin ( 1074657 )
      http://en.wikipedia.org/wiki/Flac [wikipedia.org]

      Free Lossless Audio Codec (FLAC) is a file format for audio data compression. Being a lossless compression format, FLAC does not remove information from the audio stream, as lossy compression formats such as MP3, AAC, and Vorbis do. Like other methods of compression, FLAC's main advantage is the reduction of bandwidth or storage requirements, but without sacrificing the integrity of the audio source. For example, a digital recording (such as a CD) encoded to FLAC can be decompressed into an identical copy of the audio data. Audio sources encoded to FLAC are typically reduced in size 40 to 50 percent. (53% according to their own comparison)

      It's like a zip/bzip/gzip file, once uncompressed, it's binary equal.

    • by CastrTroy ( 595695 ) on Monday November 19, 2007 @10:19PM (#21415685) Homepage
      It's kind of like running winzip on your wav files. All the data is there, but it fits in a smaller space. Of course, they don't use winzip's compression algorithms because that's really bad at compressing audio. They have special algorithms that are much better at recognizing patterns in wav files. I'm not completely sure how it works, but that's my understanding of it, and the easiest I can explain it.
    • Re: (Score:2, Informative)

      Just think about "ziping" a text file. It is smaller than the original file ("compressed") yet when you "unzip" it ALL of the information is still there ("lossless").

      FLAC and SHN (shorten) are basically fancy ways of "ziping" a file of audio. So, they are effectively the same thing as the original WAV (what is on the CD).

      This of course leaves out any discussion on digital v. analog audio quality, but that is beside the point.

      Yes, I over-over-simplified. But it gets the point across.
    • by tuffy ( 10202 )
      Lossless audio compression means that any PCM data fed to it can be restored later, without loss of any kind. The amount of compression varies depending on the PCM data itself. Any loss incurred before getting that PCM stream (such as sampling the original analog audio) can't be helped. It's not magic, after all.
    • by recoiledsnake ( 879048 ) on Monday November 19, 2007 @10:22PM (#21415707)
      If you rip a Audio CD to MP3,AAC,WMA or OGG that is lossy compression. There is no way of getting the original data back. If you compress it with FLAC, you can get the exact bits present on the original Audio CD. Note that we are talking about only digital conversions. How the CD was mastered from the analog source is a complete different matter and has nothing to do with FLAC.
    • look up lossless compression on Wikipedia, it explians it quite nicely.
      http://en.wikipedia.org/wiki/Lossless_data_compression [wikipedia.org]
    • A simple way to get an intuitive understanding of why lossless audio compression is possible is to display an audio waveform at a resolution high enough that you can see individual samples. You will notice that adjacent samples are close to each other - the signal doesn't change very rapidly. That's due to the physical nature of music and speech and it is a way in which such signals differ from arbitrary signals. If you display white noise, for example, it won't have this property - samples not very far ap

    • To use an analogy, if all your images consist of a doussin lines, then storing them as an XML encoded list of lines will occupy a lot less space than using a 1280x1024 bitmap. However, if you try to use the same XML format to store images of grainy materials, like sand, concrete etc... then you will end up storing a complicated list of lines for every single point, leading to a much larger files than if you had just used a bitmap.

      Lossless compression works by identifying common features of a particular type
  • Fixed in Ubuntu (Score:3, Informative)

    by coolhelperguy ( 698466 ) on Monday November 19, 2007 @10:30PM (#21415789)
    If you're using Ubuntu, the latest security updates should have fixed this already (for a few days, I believe). The Ubuntu security team has USN-540-1 [ubuntu.com] as a notification. It looks like it's an issue in Ubuntu 6.06 LTS, Ubuntu 6.10, Ubuntu 7.04, and Ubuntu 7.10 (at least), and their respective Kubuntu/Edubuntu/Xubuntu releases.

    All you really need to update looks to be libflac7 or libflac8, whichever exists on your system (8 is only for Gutsy, aka 7.10), though it's probably a good idea to update all the security updates anyway.
  • Phew (Score:5, Funny)

    by Frogbert ( 589961 ) <{frogbert} {at} {gmail.com}> on Monday November 19, 2007 @10:32PM (#21415807)
    Good thing no one uses this esoteric "FLAC" format.
  • by syousef ( 465911 ) on Monday November 19, 2007 @10:50PM (#21415917) Journal
    I thought they were just being rude. Now I know why.

  • by unixmaster ( 573907 ) on Monday November 19, 2007 @11:03PM (#21416017) Journal
    libavcodec never ever used libFLAC, it has its own FLAC encoding & decoding code, hence not affected. Lousy journalism on Heise part.
  • by Mr2001 ( 90979 ) on Monday November 19, 2007 @11:05PM (#21416033) Homepage Journal
    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.
    • Re: (Score:3, Insightful)

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

      More like $100.

      Portable audio player that supports FLAC: $300.

      I don't mess with these. There are no portable players in production that meet my needs. The only one close are the iRivers with SPDIF, and the models I would be interested in are not in production any more.

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

      I was able to hear a big difference on a pair of $69 headphones and $20 sound
      • 5th generation iPods can be flashed with Rockbox or iPodLinux, both of which have FLAC support. Also USB sound cards are $40 and usually don't sound better than the cards bundled with most laptops, while also being slower than onboard chips. Finally, $200 will get you 750GB, which is adequate for music, assuming, of course, that you are storing lossless. Please "do a bit of research before spouting off."
        • Re: (Score:3, Informative)

          5th generation iPods can be flashed with Rockbox or iPodLinux, both of which have FLAC support.

          5th gen (or any other) iPods have crappy DACs and poor amps. FLAC support is irrelevant for them.

          Also USB sound cards are $40 and usually don't sound better than the cards bundled with most laptops, while also being slower than onboard chips.

          USB sound cards that cost $40 don't sound better than the laptop sound cards because they have the same crappy amps and DACs as the laptop sound card. Get a $250 USB sound car
    • Re: (Score:3, Interesting)

      by AikonMGB ( 1013995 )

      I am not myself an audiophile (though I do exhibit some audiophile tendencies); I thought the idea behind using gold-plated connectors was not that they sounded better, but because they stayed sounding the same for longer due to not corroding?


  • by awfar ( 211405 ) on Monday November 19, 2007 @11:24PM (#21416175)
    A sincere Thank You for your efforts, identifying the issue and alerting the Devs, and correcting the problem.

    This is the way things were meant to work, as so eloquently put elsewhere.
  • In Files? (Score:2, Interesting)

    by pete-classic ( 75983 )
    The summary inherited the lousy description in the title of the article.

    I see nothing to indicate that these vulnerabilities are in FLAC files. They seem to be in the reference implementation of the decoder. An exploit would be in FLAC files.

    Come on, guys! You're running a Geek website here!


In English, every word can be verbed. Would that it were so in our programming languages.