Slashdot Mirror
Winamp Skin Exploit in the Wild
An anonymous reader writes "Secunia.com has announced an exploit (derived from xml escaping the Internet zone into IE's local zone) that exploits Winamp's habit of automatically installing skins. Currently all versions of Winamp are affected. Details on the Winamp forums - apparently an exploit is already in the wild, and spreading."
One of the winamp betas had the option to use the mozilla engine rather than the IE one. Shame they never spent more time on this feature then they could easily tell people they could fix this exploit by turning off the MS Engine.
Yet another way?
Seems like the same old crap to me...
You convince some sucker to download and load something that isn't what it says it is. We've reported aim exploits that hide themselves as screensavers recently.
It's a major security problem when a program blindly executes something. Period.
It's a major security problem when people download untrusted winamp skins on IRC.
What can you do?
Amen! I use it to play music, I dont look at the damn thing. I know some people love skins, for me I dont need it, just need to hear the music not see the colors!
ANY library that works like the Microsoft HTML control (this is what Microsoft calls all the non-trivial bits of Internet Explorer... the IE application is just a thin wrapper around this) is at risk for exploitation. The only way to be sure that nobody's going to break out of your sandbox is to make sure that the application that creates the sandbox is the application that controls access from the sandbox, and that any helper applications it calls unconditionally implement their own sandboxes.
If you use the *same* application, API, or application binding (eg, the file type bindings used by the desktop and the MS HTML control, or Apple's LaunchServices) for both sandboxed and trusted objects, then you open up the possibility that an untrusted object will look like a trusted object, or that an untrusted object will be passed to a handler that isn't inherently safe.
Apple blew this with launchServices, and they still haven't really fixed the underlying problem. But they've only been in denial a few months, whereas Microsoft has been in denial about this for seven years, so let's look at Microsoft...
Let's suppose the HTML control was split up, so it only did rendering. Whenever it wanted to open a file, open a URL, run a script, load a plug-in, it would ask the parent application "what do I do about a CHM file" or "what do I do about <script language=vbscript>". You'd have an "HTML-only control" and a "Web Access control" and IE would be a very slightly thicker wrapper around both.
So then you register "Word Viewer"[1] with Outlook and IE as the helper application for Word documents, and "Word" with Windows Explorer as the helper application for trusted Word documents. If this was done, then Outlook (which would be a sandboxing application in this model) would open "Word Viewer" for untrusted documents.
Viola, no more email-spread Word macro viruses.
Similarly, Outlook would decline to run VBscript, and IE would decline to run the Windows Update plugin... you'd have a Windows Update program that was a thin shell around the HTML-only control... one that only opened windows update.
Microsoft could have their cake and eat it too, and EVERYONE would have a more secure and less spammy environment.
Why are you geeks worried? Shouldn't you be using Foobar2000 anyway? It is about 2000 X better than winamp and packed with geek friendly features.
Revolutions are never about freedom or justice. They're about who's going to be top dog. -- Kilgore Trout