Keeping Skype safe
Last Friday (2006-05-19) we issued a Skype Security Bulletin that describes a bugfix in the way that certain Skype weblinks are handled. I wanted to give a bit of explanation about what this means and how to upgrade to the newest version.
]]>Skype lets people use web links to get Skype to do things for them, such as to start a chat, make a call or initiate a conference call. We have information about these links on our Share site. One of the features we have is to allow the sending of files from one user to another, using the “sendfile” directive.
How do you use sendfile?
Users can use a web page to send a file from one user to another with a web link such as skype:user1?sendfile, which sends a file to “user1″. But what you do not see here is the name of the file to send. When we designed the sendfile directive, we believed that the sender should be required to select the file to be sent, in order to prevent any abuse.
In the example above, if a Skype user clicked on the link, a file transfer dialogue box would appear, titled “Send file to user1″, and asking the user to select the file to send. The user can send a file only to someone he has “authorized” (exchanged contact details with) and can stop the transfer by clicking “Cancel”.
What is the bug?
It turns out that the arguments to the skype: link can be built incorrectly so that the file can be specified in the link, not selected using the file selection dialogue box. You can only make the incorrect construction work under specific conditions, but it can happen. That isn’t the behavior we specified in our design, so we fixed the bug immediately, published a vulnerability notice and sent a recommendation notice to Skype users that they upgrade their software in order to close the vulnerability.
The bug is not trivial to exploit, however. Skype allows files to be sent only to people who have “authorized” the sender, which complicates an attack somewhat. In addition, if a malicious user initiates a file transfer, the user can cancel the tranfer in the usual way by clicking “Cancel”. Clearly, of course, the best way to handle this is to upgrade your Skype for Windows client to the most recent edition (either 2.0 or 2.5), which is fixed.
What are we doing to prevent a repeat problem?
The architect of the Skype weblinks and the responsible development team have independently audited the implementation of the Skype URLs to ensure that there are no repeats of the argument handling problem that occurred in this case. (And the bug discovered in this case has no relationship to any previous bugs in Skype.)
I want to take a moment to say “thanks” to Brett Moore of Security-Assessment.com Ltd, who referred this issue to us for resolution. Brett clearly explained their discovery and made himself available to discuss the problem at length.
