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: <009701c258e1$2220dc60$858370d4@thor2k>
From: thor at pivx.com (Thor Larholm)
Subject: IE6 SP1 Notes

Some initial notes on Internet Explorer 6 Service Pack 1.

Test versions:
The IE6 SP1 which was released to Microsoft's download servers in early
August was build 6.0.2800.1082, which formed the preliminary basis of these
notes. The final build of IE6 SP1 is 6.0.2800.1106, and these notes still
apply.

Several unpatched vulnerabilities are fixed:
Several of the vulnerabilities listed on http://pivx.com/larholm/unpatched/
are fixed in this Service Pack. This includes, but is probably not limited
to, cssText and DynSrc. When these are also patched in IE5 and 5.5, it will
bring down the number a bit (currently 20 publicly known unpatched
vulnerabilities).

Cross-protocol linking crippled for res:// and file:// links:
Links in the Internet Zone (any HTTP:// page) that point to a res:// or
file:// no longer work, even when clicked manually. Trying to
programmatically open a res:// or file:// link from the Internet Zone yields
a very clear "Access is denied" error.

Good job on this one, Microsoft! Finally a display of good intent, "security
over functionality", this even break your very own autosearch functionality
in the browser (
http://auto.search.msn.com/response.asp?MT=www.unresolvingdomain.com&srch=5&
prov=&utf8 no longer works ) and will definitely cripple a lot of
functionality in many places.

..Ironically, though, the fix itself opens up a way to circumvent this
security measure. You can still open any file:// or res:// file
automatically with

<object type="text/html" data="redirect.asp"></object>

where redirect.asp makes a HTTP redirect using this HTTP header:

Location: file://c:/test.txt

Whenever a child window object experiences a DNS error (such as the one
caused in SP1 by trying to link to a res:// or file:// page), the location
of that window object is transferred from the child window object to the top
window object so that the user is aware of what is happening. Microsoft
forgot to check this crucial step of their otherwise well meant approach to
foreign protocol checks. When the DNS error propagates to the top window
object, the location is exchanged to that specified by the HTTP redirect.

A demonstration is available at
http://jscript.dk/2002/9/sec/ie6sp1resfile.html

Another issue with this security measure is that it is only applied for the
Internet Zone. If you are a malicious intranet user (and thus in the
Intranet Zone), then you can still link to res:// and file:// pages without
hassle whatsoever (hint provided by the folks at GreyMagic).

To top it off, automating a workaround for this is so easy that you will not
have to change any of your existing res:// or file:// links. All you have to
do is include a corrective script, such as
http://jscript.dk/2002/9/sec/ie6sp1resfile.html, after which any of your
cross-protocol links will work again.

codeBase local path:
Lately there have been a lot of "arbitrary command execution"
vulnerabilities, all of which use the "codebase local path" trick together
with cross-protocol scripting.
The developer notes in IE6's README file says.

OBJECT HTML tag
-------------------------------------------------
The codeBase attribute of an OBJECT tag can no longer specify a
local path.

This is incorrect, try http://jscript.dk/2002/8/sec/ie6sp1codebase.html if
you have installed SP1. The codebase attribute can, and will, still be
abused to execute arbitrary programs. Not being able to pass parameters is
irrelevant when there are so many ways to get arbitrary files on the users
local file system in a known location (look at WMP Stench for an example).

The about: protocol:
The about: protocol, sometimes used by programmers as an intermediate
document creation storage, no longer works - at all. This has the effect of
stopping a number of vulnerability components from working, since many of
these vulnerabilities rely on the fact that about: was accessible from any
protocol.
This is likely to break some functionality, but is irrelevant since about:
shouldn't be used as a proxy in production code anyhow.

Window placement restrictions do not work after all:
The developer notes in IE6's README file says:

Window placement
-------------------------------------------------
Windows can no longer be moved off the screen using the move, resize,
and open methods of the window object.

This is simply incorrect, you can still position a window outside the
screen, with both the move and open methods.

Window size restrictions do not work after all:
The developer notes in IE6's README file says:

Window.open can no longer open in full-screen mode
---------------------------------------------------
In Internet and Restricted Sites zones, window.open can no longer open
in full-screen "kiosk" mode.

This is also incorrect, you can still open full-screen windows in the
Internet Zone.

Uninstalling Service Pack 1:
If you upgraded from IE5.5 to IE6 prior to applying IE6 SP1, you are in
trouble. Uninstalling IE6 SP1 will then uninstall the entire IE6, instead of
only the Service Pack.

Some may call this a feature ;)

Regards
Thor Larholm, Security Researcher
PivX Solutions, LLC

Are You Secure?
http://www.PivX.com


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ