full-disclosure - Microsoft Faces Angry IE Users' Questions

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]

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