You should really upgrade ASAP, as this problem can (theoretically) occur when GnuPG decrypts/checks encrypted email messages/signatures (for example).
If you're running Debian unstable:
apt-get install gnupg
The NVIDIA Binary Graphics Driver for Linux is vulnerable to a
buffer overflow that allows an attacker to run arbitrary code as
root. This bug can be exploited both locally or remotely (via
a remote X client or an X client which visits a malicious web page).
A working proof-of-concept root exploit is included with this
The only possible solution (as NVIDIA still hasn't fixed the issue, although they know about it since 2004):
Disable the binary blob driver and use the open-source "nv" driver that is included by default with X.
Yes, you won't have 3D acceleration any more if you do that. Yes, that sucks. Complain to NVIDIA that they don't provide documentation so that free drivers can be written.
Luckily I stopped using the NVIDIA binary-blob quite a while ago, and I don't intend to ever use it again. This exploit clearly shows me that that's a good decision. For now, I'll have to live with the fact that I must use software-rendering for 3D (which is slow). When I buy my next computer it won't have an NVIDIA card, that's for sure.
But maybe there's hope. Maybe, just maybe, NVIDIA releases proper documentation one day (but don't hold your breath).
Alternatively, I just learned about the nouveau project: a project which aims at producing Open Source 3D drivers for nVidia cards. I don't know what the current status is and whether it's usable already, but this is definately a project which is worth trying out and worth supporting!
Both exploits are possible because the input of the programs is not properly (or at all) sanitized. Basically, they call
$wget_cmd is shell (/bin/sh) code which shall download a file via wget. As the
$wget_cmd string contains contents from an untrusted source (HTML/XML on some random server), this results in an "arbitrary code execution" vulnerability, the worst-case scenario you could imagine.
If someone is naive enough to even run such a podcatcher as root, this means a remote root exploit!
Anyways, the RedTeam is definately correct in saying that more and more people start listening to podcasts, and more and more podcatchers are written. But few of them are written with security in mind, which leaves many listeners at risk... I wonder how popular closed-source podcatchers such as iTunes are affected here. Are there any published audits/audit-results (black-box auditing, obviously, as you don't have the source code) for iTunes?
As for Free Software implementations... consider this a call for reviews and audits! If you know/use one of the many podcatchers (or an RSS feed aggregator, which are affected by similar issues), and have some knowledge on secure programming, get the source and review the application. Make the software you use, and the world at large, a little safer.
I'll definately have a look at the programs I'm using soonish...
It seems Apple is having more and more severe problems lately, MacOS viruses and worms start popping up and spreading on a larger scale... Michael Lehn has now discovered that Apple Safari can be tricked into automatically downloading and executing arbitrary shell scripts.
No need to mention what harm this can cause, especially if you are stupid enough to browse the web as root (or whatever Apple calls their superuser).
The behaviour to automatically open downloaded "trusted" files in a respective application is the default in Safari, which is obviously not the brightest idea Apple ever had. This is not an Apple-only problem, though. I really wonder why so many people, be it developers or users, are willing to sacrifice security for some crappy "feature"...
Someone on the security mailinglist Full-Disclosure has posted an interesting warning regarding proof-of-concept exploit code. It seems that multiple published exploits have been replaced with more malicious versions by unknown attackers.
The attackers replaced the shellcode in the demo exploits (which usually opens a root-shell) with more malicious versions like '
rm -rf /*'. As such shellcode usually consists of hex-encoded assembler instructions, most people don't have the slightest chance to understand it, and hence cannot verify what it really does. People who want to "just try out whether I'm vulnerable", might end up with a wiped hard drive (or worse).
The lesson (one of them, that is) we should learn here is to never execute any code we don't trust and/or fully understand.