ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá














     áòèé÷ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] FW: [Full-disclosure] Firefox: serious cookie stealing / same-domainbypass vulnerability



> -----Original Message-----
> From: full-disclosure-bounces@xxxxxxxxxxxxxxxxx 
> [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf 
> Of Michal Zalewski
> Sent: Thursday, February 15, 2007 1:23 AM
> To: security@xxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx; 
> full-disclosure@xxxxxxxxxxxxxxxxx
> Subject: [Full-disclosure] Firefox: serious cookie stealing / 
> same-domainbypass vulnerability
> 
> There is a serious vulnerability in Mozilla Firefox, tested 
> with 2.0.0.1,
> but quite certainly affecting all recent versions.
> 
> The problem lies in how Firefox handles writes to the 
> 'location.hostname'
> DOM property. It is possible for a script to set it to values 
> that would
> not otherwise be accepted as a hostname when parsing a regular URL -
> including a string containing \x00.
> 
> Doing this prompts a peculiar behavior: internally, DOM 
> string variables
> are not NUL-terminated, and as such, most of checks will consider
> 'evil.com\x00foo.example.com' to be a part of *.example.com 
> domain. The
> DNS resolver, however, and much of the remaining browser 
> code, operates on
> ASCIZ strings native to C/C++ instead, treating the 
> aforementioned example
> as 'evil.com'.
> 
> This makes it possible for evil.com to modify location.hostname as
> described above, and have the resulting HTTP request still sent to
> evil.com. Once the new page is loaded, the attacker will be 
> able to set
> cookies for *.example.com; he'll be also able to alter document.domain
> accordingly, in order to bypass the same-origin policy for 
> XMLHttpRequest
> and cross-frame / cross-window data access.
> 
> A quick demonstration is available here:
> 
>   http://lcamtuf.dione.cc/ffhostname.html
> 
> If you want to confirm a successful exploitation, check Tools 
> -> Options
> -> Privacy -> Show Cookies... for coredump.cx after the test; 
> for the demo
> to succeed, the browser needs to have Javascript enabled, and 
> must accept
> session cookies.
> 
> The impact is quite severe: malicious sites can manipulate 
> authentication
> cookies for third-party webpages, and, by the virtue of bypassing
> same-origin policy, can possibly tamper with the way these sites are
> displayed or how they work.
> 
> Regards,
> /mz
> http://lcamtuf.coredump.cx/
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 



 




Copyright © Lexa Software, 1996-2009.