No mention or actual "root" access, just "shell" access under the user's account. While that's still bad, obviously, on its own it's certainly not "wormable", as the article suggests.
I contacted the author asking him to verify the claim of "root" access, since it makes a difference to those of who know what that is. He replied with an apology and updated the headline.
I don't agree that gaining control of the user account is that much smaller of a concern then root access. You can do a lot on a Mac with just the user account. And then, local exploits providing privilege escalation are relatively common.
How many Mac owners do you think run their admin account as the personal account. I bet more than a few don't bother with the distinction between user and admin.
That's like asking how many ubuntu users run their account as root. Almost None. The default in both cases is a normal user with sudo access (requesting a password). I'm not even sure where to start if I wanted to log in as root (not just in a terminal).
I just tried logging in as root on my Mac from the graphical login, works fine! If you don't know your root passwd you can also 'sudo passwd'.
There's no advantage really, though, since the gksu style authentication popup system when you need admin privileges is very painless. I too doubt if many people run their Macs as root.
Maybe when you typed 'sudo passwd', which created the root password. Just as in Ubuntu the root user exists, the account is merely locked (see 'man passwd', -l option)
Apple describes how the Right Way here http://support.apple.com/kb/ht1528 but I'm sure I've never seen Directory Utility before. However, in the Edit menu they reference, it said 'Disable Root User', not Enable, so it's been activated somehow. Perhaps doing sudo passwd did it, though I don't recall setting it up through an unofficial method such as that on my Mac. I'm not really comfortable hacking around on MacOS since it's a bit different than Linux, being a BSD, and the extent of integration between traditional text file style configuration and Apple's GUI stuff is unclear to me.
I previously enabled it via Directory Utility, but disabled it again and tried it for you:
$ sudo passwd
Changing password for root.
New password:
Retype new password:
passwd: Unable to change the password for record root. Credential verification failed because account is disabled.
$
So there you have it: you couldn't have done it this way.
I agree it's hugely light on technical details. But, if the exploit gains shell access to you own account, and the exploit can occur via simple message sending in Skype, and it is possible to script Skype from the command line (Applescript perhaps?) then I can't see why an appropriately crafted exploit couldn't message all your skype contacts once you get infected. This would spread rather fast :-)
“About a month ago I was chatting on skype to a colleague about a payload for one of our clients,” he wrote. “Completely by accident, my payload executed in my colleagues skype client.
That means this thing is either BS or it is an egregious bug by the Skype team. Remote code execution doesn't happen by chance.
"Exim is a mail transfer agent (MTA) used on Unix-like operating systems. Exim is free software distributed under the terms of the GNU General Public License, and it aims to be a general and flexible mailer with extensive facilities for checking incoming e-mail.
...
A large number of Exim installations exist, especially within Internet service providers[1] and universities in the UK. Exim is also widely used with the GNU Mailman mailing list manager, and cPanel."
Not if skype renders javascript somehow. Amazon had a similar vulnerability in the "preview this book" feature a few months ago. If you used it to preview certain books that had example XSS payloads, you would get owned.
What does XSS have to do with remote code execution? I mean, it's possible for a Javascript parser to have vulnerabilities that can lead to arbitrary code execution, but the Amazon example seems in no way relevant here.
Well, it's a Register article. I left open the possibility that they called "remote script execution" remote code execution. They already said it gains root access, but then later said it gives shell access, which is not the same thing (since skype does not run as root).
I have no idea what the bug is, all I meant was that it wasn't completely out of the realm of possibility to have something render a payload.
The original builds of Android for the G1 had a root terminal running in the background that used keyboard input even though it was invisible and not focused. This allowed you, eg, run telnetd and then connect from your PC to run commands as root, which included the ability to re-flash the bootloader and jailbreak the OS.
This is how you do a security alert. Notify the manufacturer of the software, notify the press so it is made public and thus people will install updates, and keep the details secret until it's fixed. Kudos to the discoverer.
Unfortunately, it's not so simple. Alerting the public before a fix is out is a double-edged sword: it also means malicious attackers have a chance to replicate the finding and abuse it.
Any word on whether this affects version 2 of Skype for Mac OS X (the old one), the current Skype 5.1, or both? Neither the article nor the linked blog post would say.
If the former, I don't imagine they'll update it, and this might finally force me to grab 5.1.
I'm been studiously avoiding the update since inadvertently installing it a while ago and backtracking furiously shortly afterwards. I hope we get some details on the versions affected and if the problem is present in v2 that we also get a patch for that. If Skype uses this as an excuse to force the v5 upgrade they will have a lot of very unhappy people on their hands.
No mention of root; only remote shell. I have a feeling this is just bad reporting on the part of The Register.
Having said that, I wouldn't give a random person off the street access to my local user account, even if they can't execute as root. Plenty of attackers would be content to rsync all your files to their server for further examination/exploitation.
Frankly, getting a shell as my regular user on my machine can be just about as devastating as getting root. Everything that's important to me is owned by my user.
On my Mac Skype runs under the uid of my normal account, so I'm not sure how this could be used to get root access unless there's a separate privilege escalation exploit involved.
Why is this tabloid journalism featured in HN? Nowhere in the article is there any indication how root access could be obtained. There should be at least some description how privilege escalation could occur. I don't want arbitrary code executing but that is a long way from root access. Even for shell access the attacker needs the user's name and password. Does the target just offer them?
You don't need a username and password for shell access if the application has a vulnerability that allows for arbitrary code execution. Your code just executes as the same user as the application. To elevate your privileges, you would need to use a separate vulnerability once you have shell access.
Sometimes companies release minor updates that are reflected for fresh downloads but don't have the auto-update mechanisms in existing clients to download the update --- usually to save on bandwidth costs.
However, for a security patch that seems 'unfortunate'.
Gmail in the browser is, in my experience, better than Skype. The voice and video chat worked flawlessly from San Francisco to the Philippines where under the exact same circumstances Skype stuttered and failed for video conferencing.
Also - Gmail in the browser is integrated with Google Voice and Google Chat, so you don't have to suffer through Skype's client just to chat. And in fact you can continue chatting over your phone through SMS (for free) because Google Voice is awesome.
My guess is that this is related to the Webkit component Skype 5 on Mac is using for the IM window. So Skype 2/Mac should be safe, as are all other OSes.
Also, it's obviously not "root" unless there's a separate privilege escalation bug in OS X.
I wonder which versions of Skype are affected? This might cause those trying to hang on to the previous version with multiple windows to have to update.
Given that there is a known issue with the current version of Skype (5.x) for Mac where if you have your language set to something odd, it'll render the Skype chat windows in raw HTML tags ... I'm thinking the exploit is unescaped HTML/Javascript, combined with the ability to launch local code.
If you read the original post from the hack team in question, they stated the ability to at least get a local shell running as a result, so either there's something resulting in launching local file content (like an interpreter, then passing commands to it) or something able to crash Skype in an interesting and controllable way.
Given that the original authors also stated that when he tested this on his GF, she was unable to use Skype for awhile - I have a feeling it's chat related, was stored in the client chat logs, and was re-launching / re-executing whenever Skype was being opened.
There's no indication that a file transfer is involved, only 'an instant message'.
You can set your Skype to disallow messages from accounts not in your contact list. I've had trouble with this not working in some way on Skype for Linux, though.
More hysterical reporting from The Register.