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

Comments

guard pages, bit masks, and so on: better

[r00t]

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)