| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAJB2Jzs5mTyVASB5a1nP_sPC9F0k7meBXhqO1U3pxA21AE=pWg@mail.gmail.com> Date: Sat, 23 Jul 2011 02:53:21 +0200 From: Mario Vilas <mvilas@...il.com> To: full-disclosure@...ts.grok.org.uk Subject: Re: URL Spoofing vulnerability in different browsers Don't worry, we all know MustLive is lying, as usual. On Fri, Jul 22, 2011 at 10:08 PM, Chris Evans <scarybeasts@...il.com> wrote: > On Fri, Jul 22, 2011 at 8:36 AM, MustLive <mustlive@...security.com.ua> wrote: >> Hello list! >> >> I want to warn you about URL Spoofing vulnerability in Mozilla Firefox, >> Internet Explorer, Google Chrome, Opera and other browsers. I found it long >> time ago, at 6th of February 2008, just after finding of built-in CSRF >> vulnerability in Mozilla and Firefox (it's funky CSRF attack via prefetching >> functionality), which I described at my site in March. >> >> ------------------------- >> Affected products: >> ------------------------- >> >> Vulnerable are all browsers which support Basic/Digest Authentication. It's >> all modern browsers and many from old browsers. In particular affected are >> Mozilla Firefox 3.0.19, 3.5.11, 3.6.8, Firefox 4.0b2 (and Mozilla and all >> other Gecko-based browsers), Internet Explorer 6, 7, 8, Google Chrome >> 1.0.154.48 and Opera 10.62 and previous and next versions of these browsers. >> And other browsers which support Basic/Digest Authentication. >> >> In March, after my informing, Mozilla opened Bug 647010 in Bugzilla >> (https://bugzilla.mozilla.org/show_bug.cgi?id=647010). >> >> Among four browsers developers informed by me only Mozilla said, that they >> are planning to fix this vulnerability (without specifying the time). Google >> even didn't answer me, but in June they informed in their blog >> (http://blog.chromium.org/2011/06/new-chromium-security-features-june.html), >> that they fixed this vulnerability in browsers Chrome 13 (it's now beta >> version) and higher. >> >> ---------- >> Details: >> ---------- >> >> This is better to call attack, then vulnerability, because it's using >> built-in browsers functionality (and its intended behavior) to attack users >> of web sites. This attack allows to conduct phishing attacks on users of web >> sites - in this case phishing is doing not at other (phishing) sites, not >> with using of holes of target sites (like reflected XSS or persistent XSS), >> but with using of browsers functionality (and allowed functionality of >> target sites to place external content). >> >> I called this attack as Onsite phishing (or Inline phishing). It can be used >> (including by phishers) for stealing of logins and passwords of users of web >> sites. >> >> As I've tested, a lot of different methods (with using of tags and CSS), >> which allow to make cross-site requests, can be used to conduct this attack. >> Except prefetching (in all Gecko-based browsers which support prefetching >> functionality), which doesn't show Authentication window at receiving of 401 >> response from web server. The next methods can be used: >> >> Tags img, script, iframe, frame, embed, link (css) - Mozilla, Firefox, IE, >> Google Chrome and Opera. >> Tag object - Internet Explorer, Google Chrome and Opera. >> CSS (inline, in html files, in external css files): such >> as -moz-binding:url - Mozilla and Firefox < 3.0, such as >> background-image:url - in all browsers. >> >> Here are screenshots of the attack in different browsers (in Firefox 3.0.19, >> 3.5.x, 3.6.x. 4.0b2 the dialog window looks almost equally): >> >> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20Mozilla.png >> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20Firefox.png >> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20IE6.png >> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20IE7.png >> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20IE8.png >> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20Chrome.png >> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20Opera.png >> >> The attack can be made as reflected at target site, as persistent (with >> using of allowed functionality at target site, which allows to put some >> tags, like img tag). The persistent attack is more dangerous (and such type >> of attack is showed on screenshots). And there are millions of web sites >> which allow such user generated content (like img tags) which can lead to >> such persistent attacks. >> >> ------------ >> Timeline: >> ------------ >> >> 2011.03.26 - announced at my site. >> 2011.03.31 - informed Mozilla, Microsoft, Google and Opera. >> 2011.04.01 - Mozilla answered and opened entry in Bugzilla >> (https://bugzilla.mozilla.org/show_bug.cgi?id=647010). >> 2011.04.01 - Microsoft answered and asked for more details. >> 2011.04.03 - gave additional details for Microsoft. But they ignored to fix, >> like Google and Opera did. >> 2011.06.14 - Google hiddenly and lamerly fixed this hole in Chrome 12 beta >> (and future versions), without answering and thanking me for informing. >> Which is lame behavior and I don't respect companies with such behavior. But >> this Google's step should force other browsers developers to fix this >> vulnerability in their products. > > FWIW -- no, Chrome Security Team does not operate that way, and you > should be well aware of that! > > In case you weren't, please check out the Hall of Fame: > http://dev.chromium.org/Home/chromium-security/hall-of-fame > As can be seen, we have a long record of working with a variety of > excellent researchers, including paying rewards and issuing credit in > multiple places. > > I don't even know what bug you're talking about because you mention a > Chrome 13 security features blog post and then (directly above) you're > saying we fixed something in Chrome 12. > > If you provide the Chromium bug URL that you reported this to, I'd be > happy to investigate what happened and whether you should be added to > any credit page. > > > Cheers > Chris > >> 2011.07.21 - disclosed at my site. >> >> I mentioned about this vulnerability at my site >> (http://websecurity.com.ua/5038/). >> >> Best wishes & regards, >> MustLive >> Administrator of Websecurity web site >> http://websecurity.com.ua >> >> >> _______________________________________________ >> Full-Disclosure - We believe in it. >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - http://secunia.com/ >> > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists