[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    Re: Skype callto:// BoF technical details
From:       "Berend-Jan Wever" <skylined () edup ! tudelft ! nl>
Date:       2004-11-16 20:35:44
Message-ID: 004c01c4cc1b$db730cb0$0100a8c0 () grotedoos
[Download RAW message or body]

It is the same bug as far as I know.

Cheers,
SkyLined

----- Original Message ----- 
From: "Fabian Becker" <neonomicus@gmx.de>
To: "Berend-Jan Wever" <skylined@edup.tudelft.nl>
Cc: <bugtraq@securityfocus.com>; <full-disclosure@lists.netsys.com>
Sent: Tuesday, November 16, 2004 20:50
Subject: Re: Skype callto:// BoF technical details


> Berend-Jan Wever wrote:
> 
> > Skype reported they've found a remotely exploitable BoF in the callto:// URI \
> > handler. New version has been released. \
> > http://www.skype.com/products/skype/windows/changelog.html \
> > http://secunia.com/advisories/13191/ 
> > Technical details:
> > 
> > The bufferoverflow happens when a skype user clicks on a "callto://username" link \
> > with a username longer then 4096 characters that does not exist: An error message \
> > is created and put into a buffer without correct size checks. The errormessage \
> > and buffer are unicode but unicode characters are filtered out and replaced with \
> > '?'. Only printable ascii characters seem to get through. A return address can be \
> > overwritten as well as the SEH. Exploitation is complicated by the fact that \
> > return addresses have to be in range 0x00??00??. 
> > Webbrowsers like MSIE do not support URI's long enough to trigger the BoF. To \
> > exploit it, one could send a skype user a callto:// link in a private message and \
> > trick him/her into clicking it. 
> > If one would want to, one could write a skype worm with this. User interaction \
> > would be required: they'd have to click the link. 
> > Cheers,
> > SkyLined
> > 
> > 
> > 
> > 
> > 
> They fixed it without knowing of the callto:// thing I suppose cause I 
> wrote them an email saying that the quick-call field is exploitable, 
> too. This was fixed within the new version. Maybe your flaw is fixed, 
> too, if not, I think it soon will be :)
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic