bugtraq - Re: [ELEYTT] 3SIERPIEN2007

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.58.0708041959040.26677@dione>
Date: Sat, 4 Aug 2007 22:05:23 +0200 (CEST)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: Michal Bucko <michal.bucko@...ytt.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: [ELEYTT] 3SIERPIEN2007

On Sat, 4 Aug 2007, Michal Bucko wrote:

> The results made me think the example is pretty nice and effective.

Yes, sure, I can imagine - but so is "click this .exe to see a postcard
from your grandma" type spam.

To clarify, I have three issues with your report:

  1) Status bar text is inherently untrustworthy, not because of a
     particular design or coding flaw in Firefox, but because of the
     design of HTML, DOM, ECMAScript, and the like (event handlers,
     dynamic update of link properties, etc). Much of the modern
     Web relies on this design to deliver interactive UIs for web
     applications, and this is a well-known and documented behavior that
     is a part of accepted standards.

     Now, I do think it would be nice to have a reliable indication of
     the target URL, but it's an existential complaint along the lines of
     "gee, I wish SMTP had been designed to make spamming hard". One can
     get involved to come up with new standards to fix it in the timeframe
     of next 10-20 years, but it's counterproductive to bash Firefox.

  2) Unlike in the example in my followup, in the test case you provided,
     it cannot be said that the browser failed to provide an accurate
     preview of the target URL; pseudo-URL schemes such as data: and
     javascript: might be somewhat counterintuitive and can be used for
     obfuscation, but are otherwise displayed properly in the status bar.

     We might argue that there should be no confusing URL schemes, or that
     direct linking to them should be restricted, but that's again a
     wholly separate academic debate. As of now, it's what the Web needs
     to work.

  3) It's not a Firefox problem - plenty of other browsers are
     "vulnerable" to the same attack, with an exception of MSIE, simply
     because it lacks support for RFC 2397 data: URLs. A very similar
     javascript: approach can be devised for this browser, though:

     javascript:/* SSL: whatever ...(lotsa spaces)... */ void(location = 'foo');

/mz