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] [thread-next>] [day] [month] [year] [list]
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: another product affected by recent MS IE '@'
 patch

martin f krafft <madduck@...duck.net> wrote:

> In Germany, and maybe in other parts of the world, some providers
> are attracting customers by announcing webpage packages where email
> address == web address. so, john@....de is the email, and
> john@....de is the website, while jane@....de may be the website of
> john's wife.

Well silly them.

What kind of technical support can you expect from a "technology 
company" that deliberately flouts the standards of the technology it 
employs and provides a service based on known incorect and non-
standards conforming behaviour in a generally available software 
product it has no control over?

> I hope this has not been reported yet, but in the light of the
> recently announced MS IE patch to guard against the URL obfuscation
> attacks (which is a typical MS fix ...

Actually, it is _far_ from a _typical_ MS fix.

First, it actually shows serious levels of clue on the part of whoever 
made and backed the decision to make this fix.  The clue it shows -- 
which is obviously lacking in those who have criticized it -- is that 
security and standards-conformance issues really do matter.  That must 
just about be a first for MS!

Second, it is very unlike MS to "fix" something when they know it will 
break some systems based on the "broken" behaviour.  Many will be 
tempted to disagree vehemently with this, but historically it has been 
the case that when MS has designed something badly (and usually 
outright stupidly when analysed by anyone with a modicum of clue) and 
some grievous problem is shown to be the fault of the general design of 
some feature, MS has generally refused to fix it either "properly" (by 
removing the horribly bad feature) or even at all and generally does so 
on the grounds that "some customers have systems dependent on this 
behaviour".  Of late that attitude has been showing signs of change, 
particularly if the issue is security related.  True, MS also has a 
reputation for producing badly designed and tested fixes that 
unintentionally break existing systems, but that is a different 
matter...

Third, although it does not play on this line at all in its 
justification of the change, it is very unlike MS to "fix" something by 
removing non-standards conforming behaviour, particularly if that 
behaviour has been used as a product differentiator.

> ... and absolutely ridiculous), ...

Ahhhh -- so you're another genius who believes it is "ridiculous" to 
implement standards-conforming behavior?  Or are you another genius who 
believes it is ridiculous for MS to implement improved security 
behaviour in its historically insecure web browser?

Or perhaps you believe _both_ changes are ridiculous?

> ... these
> providers may now renew their product portfolio. Not like M$
> cares...

Let's see -- they had a package that depended on the palpably incorrect 
behaviour of certain web browsers.  The most widely used of the faulty 
web browsers has now been fixed so their "service" has become a dis-
service and this is somehow the fault of the software developer for 
properly fixing their browser?

I don't know what you've been smoking/drinking/whatever, but get off it 
and go read the relevant RFCs -- 1945 & 2616.  Do _NOT_ be misled by 
RFC 2396 -- it is relevant, but largely for the parts of a URI's 
general form that are specifically negated in the other RFCs.


Regards,

Nick FitzGerald


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ