The Adobe Version Cue Exploit

In a somewhat amusing turn of events, the day after I posted Yin & Yang a local remote root exploit centered around Adobe's Version Cue software hit the web. Judging by my email, this has been confusing to some, and hasn't really been passed around the Mac web very much.

I'm not sure why, it's fairly serious. If you have installed the Adobe Creative Suite, you're at risk. Or maybe it has been talked about all over and I just don't hang out in those places...

Bugtraq has one of the more interesting write-ups, including a proof-of-concept example and work-around, and there's a shorter CERT notification on it. Quoted from the CERT bulletin:

A vulnerability exists that could permit a local malicious user to obtain root privileges on the target system.
The scripts used to start and stop Adobe Version Cue are configured with set user id (setuid) root user privileges and do not validate the path names.

A local user can create specially crafted scripts and modify the current path to point to the directory containing those scripts. When Adobe Version Cue is started or stopped, the scripts will run with root user privileges.

No workaround or patch available at time of publishing.

An exploit script has been published.

Version Cue isn't an app you hear a lot about, but basically it's an app for versioning that a lot of people have but don't realize it... as it installs by default when you're installing the Creative Suite Deluxe from Adobe.

I've generally seen it used as an app running on a server so remote users, like designers and such, can collaborate on different projects... especially using GoLive. But again, it's installed by default with the Creative Suite Deluxe, so a lot of people have it and don't realize it.

More worrying is those that are most at risk will be the ones who do have it installed intentionally, and have lots of local users accessing the machine. The idea behind this is that a local user who is up to no good can, with a few terminal commands, use the scripts used to start and stop the Version Cue server to create a shell for themselves that has root privileges. Really, really not good at all.

In case it's new to you, a 'local root' exploit is one that requires the jerk to be acting locally in some way to work their crafty black magic. A 'remote root' exploit is one that someone can trigger, well, remotely.

A local root exploit might not seem to be that big of a deal, but there can be a lot of ways for someone to get that type of access, especially on a server which might have this around intentionally.

I know I've had designers ask me to setup other users on their machine so they could leave them files, etc. This is a privilege escalation attack, so the idea is to get your foot in the door one way (of which there are many, especially for a server with lots of accounts), and then boost your privileges through something like this.

I.E., someone gets someone's user/pass to an account, and while they'd normally be contained to that user's environment (along with whatever damage they did), this gives them a quick and easy way to go Lou Ferigno on everything else.

I wouldn't be freaking out if we're just talking about your machine, but if you have this on a server, yea, you have some real cause to worry.

What I've found the most interesting of all was the response posted to the exploit, stating that it's not so much Adobe's problem, but rather Apple's:

This is the result of an Apple-introduced problem in bash-2.05b. Bash, as distributed, gives up setuid privileges when invoked without the -p option, if the kernel allows setuid scripts to run. Apple changed bash to keep setuid if bash is invoked as `sh'.
You can solve this particular problem by removing the setuid bit from the scripts and tightening up path checking, but it's going to be a potential problem until Apple reconsiders their permitting setuid scripts.

Interesting... must learn more, but while the guy does seem to have a point, it just seems to come down to Adobe not being careful in their scripts to make them do some checks about where and how they're being run.