Message-ID: <20040716013950.GG15188@positivism.org>
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 12:10:33PM +1200, Nick FitzGerald wrote:
> Seth Alan Woolley to me:
> 
> > > 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.
> 
> And you don't see the problem with that?
> 
> Hint -- "and any other attribute like this".
> 
> Sounds like blacklisting or "default allow" to me.  Now, what does the 
> theory _AND_ history tell us about such (hint) stupiidities?
> 

I proposed first closing at the first whitespace (a type of blacklist). 
Then if that failed, I proposed a whitelist.

It's all in my bug report. ;)

> Do you know what they all are?  What about the ones that will be added 
> in the future -- no, they won't be a problem, surely the Mozilla (and 
> Opera and IE and ...) developers will simply add special handling for 
> them too when they arise and of course, everyone who uses Mozilla (or 
> whatever browser) updates to the latest, greatest version immediately 
> it is released so there will never be any exposure going forward...
> 

The standards are fairly well-defined.  I would have been happy with at
least a pref-able white-list (so you can change what's in the white-list
as far as tags and attributes).  I would have preferred the black-list
as you do, as I mentioned.  When you are lobbying for a fix from a
vendor you take what you can get.  If you can afford to be the peanut
gallery, that's great. ;) You can play bad cop.  I'll be the good cop.

> > 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.)
> 
> And that attitude is a large part of why we're in the security mess 
> we're in.  "It'll be right" might be good enough for government work, 
> but it certainly sucks when it comes to security awareness issues...
> 
> Broken input is broken input and apart from in incredibly simple 
> systems with highly constrained and limited possible valid input 
> options (and even then by far not always), thinking you can accept such 
> input and "tweak" it to "fix" it is one of the keys that opens the gate 
> to the fool's paradise.

SMGL's original design goal was to chug along until you couldn't
interpret anything out of it.  This has been corrected in XML.

In the mean-time, there's 1970s and 80s technology out there that we've
got to contend with, and the documents (specifications) are the holy
code.  After all, for interoperability, you've got to have some level of
agreement between all the parties involved.

> There are plenty of such key-holders at MS but shouldn't Mozilla 
> developers be above that?
> 
> I know it's a hard marketing battle to win when your competitor is the 
> 800lb gorilla _AND_ they do all the stupid dirty tricks as well, but if 
> you're going to compete on quality and/or standards compliance and/or 
> security issues, at least try to do a reasonable job of _those_ things 
> rather than lowering yourself to Microsoft's level.

Agreed.

-- 
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/c3291862/attachment.bin

Powered by blists - more mailing lists