full-disclosure - Exploits in websites due to buggy input validation where mozilla is at fault as well as the website.

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] [thread-next>] [day] [month] [year] [list]

From: seth at tautology.org (Seth Alan Woolley)
Subject: Exploits in websites due to buggy input validation where mozilla is at fault as well as the website.

On Fri, Jul 16, 2004 at 03:03:54AM +1200, Nick FitzGerald wrote:
> Barry Fitzgerald wrote:
> 
> > I think that the best solution might be to display a dialogue box before 
> > it tries to fix the tags stating that the page contains potentially 
> > unsafe incomplete tags and asking whether the browser should repair them 
> > or not.
> 
> Nope -- _VERY_ bad idea.
> 
> Idiot users want to blow both their feet off.
> 
> Asking them "do you want a chance to blow your feet off?" only slows 
> the inevitable slightly, never prevents it.
> 
> The correct solution to all such problems is simply to reject the 
> content as malformed.  And guess what will happen when you do that?  
> Several really crappy web design products will disappear because the 
> folk using them will drop them because no-one can see their pages _and_ 
> the rest will suddenly become very inetrested in producing properly 
> compliant content, as they should have been from the outset.
> 
> Playing "guess what the moron really meant" is a recipe for being 
> screwed, so let's get over the previous "need" to "see it at all cost" 
> and get some sense back into what folk are doing...

It wouldn't affect too many products to fix this.  I would be
hard-pressed to find _any+.  I would think the fact that IE didn't
interpret the malformed script tag would lead all developers to fix any
and all occurrances of the problem in real production code.  Because of
this only XSS attempts are really going to be blocked by a fix.

It was behavior only seen in Mozilla.  None of the other browsers do it. 
And the last comment of mine to the bug explained why it's possible to
fix the tags without breaking anything unless it is highly suspect. 
When you're repairing a script tag, close the tag at the first
whitespace character, not before the next tag so that anybody can stick
whatever attributes into the entity they want.  Fixed.  Leave the other
tags to interpret liberally if you want.  I mostly care about the script
tag and the object and iframe tags, especially -- anything with src or
href attributes.  The general fix would be to close the tag before the
text 'src=' or 'href=' and any other attribute like this.

It's a simple fix and not fixed it makes XSS a lot easier on many common
web tools.  (Early versions of the popular blog tool MovableType, for
example, had this bug.)

Seth

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8  3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040715/d672e715/attachment.bin