bugtraq - Re: OBJECT Bugs or Features

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] [day] [month] [year] [list]

Date: Thu, 10 Jun 2004 00:23:54 +1200
From: Nick FitzGerald <nick@...us-l.demon.co.uk>
To: bugtraq@...urityfocus.com
Subject: Re: OBJECT Bugs or Features

"http-equiv" to me:

>  <!-- 
> 
> The headers of your example Email message quite 
> clearly claim the message is multipart/alternative and the first 
> part (with the "incomplete" OBJECT tag) is text/html.  Thus, 
> although the body of that MIME component is not a properly 
> formed, complete HTML  document, the MIME Content-Type: headers 
> provide a fairly strong basis for the MUA treating that message 
> component as HTML and displaying it  accordingly.  
> 
> -->
> 
> and the Outlook Express unique ability to still do the 
> impossible unpatched after three years:
<<snip amusing example>>

Sure, and I know "http-equiv" understands the following, but lest 
anyone else missed it, I do not condoen the sloppy programming and 
design attitude behind projects that produce such results.

To digress slightly from the straight and narrow or the original topic, 
the RFCs in general (apologies in advance for the three that the 
following does not apply to) and most other "standards" that today's 
most widely used programs are designed to implement support for, are 
very badly written _if_ the intention is that they should define some 
kind of program specification.  There are many, many common 
shortcomings here, but in general, they pay _far too little_ (usually 
scantly more than "no") attention to failure modes and the issue of 
what "compliant" implementations should do when faced with non-
compliant input.

Especially in the case of RFC'ed protocols, because of the 
aforementioned "be lenient in what you accept" directive (which is 
generally _misconceived_ as applying to all RFCs when, in fact, it was 
apparently only originally intended for the very lowest-level protocols 
while they ironed out the wrinkles, rather than as general advice for 
implementing the later, higher-level "application" protocols), the 
historical standard has been "accept it and do your best", leasing to 
all manner of "compliant but utterly incompatible" shite being foisted 
on the world _AND_ boatloads of otherwise really easily avoided dire 
security vulnerabilities.

Quality of (Internet) software will only really start to improve if the 
designers and implementors start to question the ambiguous twists in 
the "standards" _AND_ refuse to implement any support for the "so badly 
worded as to be ambiguous or unclear" parts of such "standards".  If 
the "security initiative" at Microsoft is to achieve anything useful, 
that could well be one of the major lessons.  And, being the "800lb 
Gorilla", MS is rather uniquely placed to actually make a change for 
the better _across the whole industry_ if it tackles this (except, 
perhaps, in the quagmire of cr*ppily implemented protocols that is SMTP 
where several generations of sendmail madness holds a probably 
unassailable tyranny of now incorrectibly bad practice -- no worries 
though, as the only "solution" to spam (if we ever have such) will see 
the now long overdue death of this protocol).

Of course, I'm not holding my breath until any of this actually 
happens...

Regards,

Nick FitzGerald