full-disclosure - Re: Cross Site Hacking Browser Injection Attack Vulnerability Paradigms

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: <23720.1192938480@turing-police.cc.vt.edu>
Date: Sat, 20 Oct 2007 23:48:00 -0400
From: Valdis.Kletnieks@...edu
To: full-disclosure@....hush.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Cross Site Hacking Browser Injection Attack
	Vulnerability Paradigms

On Sat, 20 Oct 2007 15:46:36 EDT, full-disclosure@....hush.com said:

> 1) What browser was first vulnerable to these attacks,
> 2) Who was the responsible developer,

I don't know for sure, but I *do* know that whichever developer it
was didn't read the copious notices regarding active content in
RFC1341, including this in Security Considerations:

            Security issues  are  discussed  in  Section  7.4.2  and  in
            Appendix  G.   Implementors should pay special attention  to
            the security implications of any mail content-types that can
            cause the remote execution of any actions in the recipient's
            environment.   In  such  cases,  the   discussion   of   the
            applicaton/postscript   content-type  in  Section  7.4.2 may
            serve as a model for considering  other  content-types  with
            remote execution capabilities.

So when the WWW guys were choosing MIME as an encapsulation method,
the security issues were *well* understood.  It was *known* that if you
were going to have active content, it *had* to be sandboxed in order to
avoid security problems (and in fact, Java showed up with just that sort
of a sandbox available, because the Java crew *did* think about the issues).

But the ability of Javascript to provide dancing hamsters won out, and we've
been dealing with its half-assed security model for the last decade and
a half.

> 3) How was this vulnerable mechanism replicated across all modern
> browsers,

Once one browser had dancing hamsters, the others needed to do so as well,
for feature parity.  And once Javascript's busticated security model was
accepted, it got propagated into all the other add-ins and ActiveX and
all the other gee-wiz-bang features.

> 4) Instead of patching individual XSS problems in random web-based
> piano tuning software, why aren't the serious security
> researchers[1] of this list working to develop better technologies
> to block the entire vulnerability class, like the PaX/w^x team has
> done[2], to raise the ante for computer security list posters
> around the world?

Find 5 non-expert computer users in your family, and try the following:
Turn off Javascript, Flash, and other active-content plugins in their
browser.  See how long they can surf the web before all 5 are fighting
to be the one to personally remove your gonads with a very blunt knife.

OK?  That's what we're up against.  And that's why it's so difficult.
For the general user, dancing hamsters trump security every time.

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/