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>] [day] [month] [year] [list]
Message-ID: <40EEB1DD.6215.496D05FA@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: How big is the danger of IE?

"Larry Seltzer" <larry@...ryseltzer.com> wrote:

> >>...the security zone model itself (well, at least its
> >>implementation in IE, etc) _is the problem_ and can often be
> >>exploited independent of the scritping, and other active content
> >>processing, state of the zone in which some arbitrary piece of HTML
> >>is rendered. 
> 
> So you can do a cross-zone attack against the restricted zone, with
> all scripting and active content disabled? I'd like to see an example
> of this. 

It's precisely that kind of attitude that perpetuates two really 
insidious influences in the "security community".

First, it drives many vulnerability discoverers to feel they "must" 
publish PoC code (which is ever more quickly turned into active 
exploits against the vulnerability, increasing the harm wrought by each 
such publicly disclosed vulnerability).

Second, it leaves ignorant folk unduly smug in their belief that they 
are safe "because I have not seen it with my own eyes".

It is often said that "security is a process" but that process has to 
be driven by an understanding of the possible, which will always be at 
least partly a theoretical endeavour.  People have often said much the 
same as you just did about various reputedly "very difficult to exploit 
vulnerabilities" (well, it said so in the belated MS security bulletin, 
so it had to be true, right?), but all manner of HTML content is 
minimally "active' in the sense that the interpreter can be induced to 
fail in interesting ways or in that alternate or additional content is 
obtained through some form of redirection, and such things are often 
the basis of many previous, successful exploits of those "very 
difficult to exploit" IE (and many other) vulnerabilities.

So, will you be smug (and lazy) with Larry or safer moving to Mozilla?

I know where I put my money...

...

The "bigger picture" perspective...

Do you guys really think that folk like Guninski, Jelmer, http-equiv, 
Lie Diu (sp? -- sorry) etc rush their newest discoveries out as quickly 
as they find them?  OK, so sometimes they do, but often they have 
niggly "little" tricks that they feel aren't worth much alone, but 
which they store away until such a time that they are just the right 
new twist to beat the latest hackneyed and incomplete "fix" from MS or 
whoever.  We have seen evidence of this time and again -- within the 
last couple of weeks even.  How many of those undisclosed tricks that 
can become show-stoppers when the right environment for using them is 
eventually found do you suppose those guys know of?  Based on the 
general bugginess of software and the relative seriousness weightings 
of bugs in general I'd hazard its quite possibly in the range of two to 
three for every one they release...

So, are you really so sure that it is worth waiting for MS to ship the 
fix for this latest abject failure of the zone chooser?  How sure are 
you that someone won't release a new exploit that walks through, over 
or around that sparkly next patch, probably within minutes to hours of 
the patch's release?  And, even if you accept there is a modest 
probability of that happening, how long do you have to live like that 
before deciding that sidestepping most of these problems really is a 
better alternative?  A few months?  A few years?

Both those timeframes have expired...


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ