Comments: Cubicle adds to Security Research on Skype

Improving security isn't always good. It would be if users could accurately evaluate security risks, but...


Suppose you have a black metal box that does something very useful, but which occasionally explodes. You keep it in a concrete bunker in your backyard, and clean up after the explosions. So now you get the value out of the box. That's good!

Now I give you (or sell you) a new one, and I tell you "This one doesn't explode.". So you move it into your house where it is more convenient. What I *should* have said was "This one doesn't explode nearly so often.". It turns out that the new one still explodes every year or so. That's bad!

Users have an understandably difficult time evaluating security risks (as well as evaluating risks in general), so if you give them a phone and tell them "This one is secure." (which Skype does indeed tell them -- see their web pages on the subject), then you may be putting them at greater risk.

Posted by Zooko at April 8, 2005 09:32 AM

Hi Zooko,

Indeed, this is an issue. I'd like to disassemble it if I may.

Firstly, your example hangs on the claim that the 2nd box won't explode when in fact it will. This is a simple lie, and therefore is a bad in information terms; the user is being told something that is wrong. Of course, in this circumstance, the user is bound to do the wrong thing, or at least make a poor judgement, because he is working on information that is not the truth.

But, the problem presented by the example is not that security improved, but that the marketing people lied. So your first claim "that improving security isn't always good" is unaddressed.

Now, if we look at Skype, we see something similar. Skype are lying (so it is suggested) on their site about how it is secure. But so are the Internet security analysts. Basically the thought process is something like "Skype says it is secure, I can't see the source, therefore it can't be secure, therefore it isn't." Some of the security analysis that is going on against Skype is reaching conclusions as vacuous as Skype's original claim.

There is one fundamental error in all this, one that allows all the above poor analysis to carry on. That is this: nobody has defined "secure". Not Skype, not the analysts. Until they do, they can't be wrong, but they also can't be right. The analysis is as poorly founded as Skype's marketing - basically meaningless.

So what's a poor phone user to do in all this? Well, construct a risks based analysis and decide whether it likely benefits the user. In this case, it falls overwhelmingly in Skype's favour. I haven't read it all yet, but I've yet to see anything fall as a demerit point in an individual risk analysis. And, overwhelmingly, users agree. By their actions, they are saying it is secure according to their own informal risk analysis.

Posted by Iang at April 8, 2005 10:07 AM

I'll agree that the current risk of Skype being used as an exploit vector seems to be either low or very low. The big issue at this time is that there a significant unknowns which could change that assessment in the blink of an eye.

As a possible example, does Skype use the same image renderers which Microsoft recently patched for buffer overflows? If so, this would mean its Instant Messenger or file transfer mechanisms are probably vulnerable to the same worms that already exist for MSN Messenger. At its current rate-of-adoption, it's only a matter of time before someone explores this venue.

Unfortunately, due to the Skype team's efforts to prevent me researching this (i.e. by refusing to run on a machine with SoftICE installed), it's now easier to just "Fail Shut" from a corporate policy perspective than perform a quick analysis of the application's sytem calls to see whether or not it inherents the .jpg overflow vulnerability.

Thus, I've got a couple of different risks that I've got to consider with regards to Skype and most of them have to do with unknowns. Unfortunately, if I give it a clean bill of health, I'm effectively assuming risk on behalf of my enterprise's entire network, something that I'm not able to do as less than a Corporate VP.

The big issue from my corporate perspective has to do with control and unintended consequences. In our case, when the application starts it sends a spray of UDP traffic which then sets off the IDS sensors. If every time a Skype client starts, it generates a false positive which the SOC has to investigate, it doesn't take too many Skype users before there is a significant increase in the false positive count down in the SOC.

Since that's not free, it's extremely hard to justify allowing an application which we're really deciding if we want to tolerate it, rather than an application which has a demonstrated value against which this cost can be measured.

Then, since it's still an Unofficial Application, it will be nearly impossible to ensure patching or revoke access later if an actual vulnerability is identified and an exploit released (I completely agree with your points from the Jedi Knights Of The Crypto Rebellion post, btw).

Is Skype better than the alternatives? As of today, I would say, "Yes," for individuals. It certainly provides better protection than the Public Switched Telephone Network (which provides NO security and, at least in the US, is architected to support CALEA (wiretaps)).

Could it do a better job with its Confidentiality/Crypto? Of course it could--in addition to the closed implementation, its keys cannot be managed externally, which would provide a venue for effectively mitigating many of the concerns that have been raised about potential MitM attacks. But something is still better than nothing.

Is it going to become a corporate solution? Probably not any time soon. Of course, I just saw some Google hits which indicate that there are some small companies offering customer support Skype contacts, so leave it to Reality to go and prove me wrong...

Posted by Chandler Howell, aka Cubicle at April 8, 2005 01:46 PM
Post a comment









Remember personal info?






Hit Preview to see your comment.
MT::App::Comments=HASH(0x55655600bd78) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.