Media player users beware: more vulns ahead
Targeting Windows Media Player and Winamp
Security researchers are warning that popular media players offered by Microsoft and AOL are vulnerable to attacks that can completely compromise a user's PC.
Attack code has already been released for the bug, which has been confirmed in a codec used by older versions of Windows Media Player, made by Microsoft, and in AOL's Winamp. A Symantec researcher has warned that users of other players may also be at risk because the vulnerability itself resides in a commonly used MP4 codec produced by a company called 3ivx Technologies.
"The exploit works by supplying victims with a maliciously formed MP4 file," Raymond Ball wrote for Symantec's DeepSight Threat Management System. "When a victim unknowingly clicks a link that appears safe, the MP4 content is delivered, causing the exploit to run."
A researcher who goes by the name SYS 49152 released exploit code here, here and here that targets Windows Media Player 6.4 and Windows Media Player Classic, which are made by Microsoft, and AOL's Winamp version 3.5. Each uses the 3ivx MP4 codec, which is vulnerable to a stack overflow.
Secunia describes the Windows Media Player vulnerabilities as "highly critical," the second-highest rating on Secunia's five-tier scale. The vulnerability reporting service didn't have a rating for the Winamp vulnerability.
No patch is available. Ball recommends users remove the codec or disable media players that use the MP4 codec until the hole is plugged. That strikes us as overkill. Taking care not to click on suspicious links in browsers and email programs should suffice.
The vulnerabilities are the latest reminders of the exposure that can come from using a media player. Two weeks ago, a security bug was discovered in the way Apple's QuickTime that leaves PC and Mac users alike at risk of remote hijacking. Apple has yet to acknowledge the vulnerability, which resides in the way QuickTime interacts with servers that stream audio and video. ®
Java strikes back
I admit writing codecs in ARM machine code was quite fun, particularly when it came to bit twiddling, but codecs these days don't need that much bit twiddling. With a modern JIT, Java isn't that different in performance to C++ - with similar bitwise operators too.
I'd be very intrigued by a Cobol media player - though it wouldn't be much use as my browser can't run Cobol! But it can run my Java media player, as can almost every browser on the planet. And without buffer overflows.
re: Back to Java then (again)
Lemme see: the issue is that there's some sort of unchecked input vulnerability in the 3ivx codec; since it leads to a stack-smashing attack it's almost certainly a buffer overflow. Care to explain again how writing the media player in [insert fashionable language du jour] here is going to make a blind bit of difference. Or are you positing that the world's codecs should all be re-written in Java - a language which, let's not forget, is oh so suited to bit-twiddling, coming second only to COBOL in that particular race.
Here's 5 pence; feel free to go buy yourself a clue then once you're done you can come back and join the conversation.
Back to Java then (again)
Once you get to full frame rate video with plenty of CPU power to spare, it doesn't matter much how much resources a media player takes.
A Ferrari on a motorway goes pretty much the same speed as a mini. What matters is that it arrives without breaking down - or perhaps a better analogy in the case of a virus is to arrive without the road ahead being destroyed. Reliability and security come with Java.