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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40F147E5.5680.542C8D1@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Microsoft Faces Angry IE Users' Questions

Florian Weimer <fw@...eb.enyo.de> wrote:

> Haha.  Apparently, Internet Explorer on Windows XP Service Pack 2 will
> break one of our internal web applications (which uses MIME content
> type, not extensions, to provide application information.
> Fortunately, we don't use Internet Explorer, but it's still quite a
> paradigm shift.  I wonder if they break down and release a "fix" in a
> week's time.

Historical precednet suggests that (perhaps largely undocumented) 
regsitry settings will be available to (re-)enable the former, but now 
deemed "broken", functionality.  You need look no further back than the 
kerfuffle a couple of months ago over the removal of IE's patently 
incorrect support for "user:pwd@" userid data in http URIs for an 
example, but there are many other, earlier examples.

Of course, what such cop-out "revert to insecure functionality" options 
tend to invite are unscrupulous third-party developers (if not also 
Microsoft's own application developers) to add a "check for registry 
setting X and tweak it appropriately" function to their installation 
scripts.  That is a very cheap option for the developers and therefore 
much more desirable to them than fixing what is more often than not 
some inherently shoddy architectural issue (aka design flaw) in their 
product or servcie that would require major re-working to fix.

Most users rather blindly trust their application developers' code and 
don't check what security (or other) changes those developer's 
installation routines make to their machines.  If such opt-out settings 
are generally available for XP SP2 "fixes", once SP2 is rolled out 
many, many users will silently and unknowingly have their overall 
security lowered, and many vulnerabilities re-introduced to their 
systems, by installing the "patches" offerred by their vendors "to fix 
XP SP2 incompatibilities".


Regards,

Nick FitzGerald


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ