Subject: RE: FW: Virus alert

From: "Christian Huitema" <[email-masked]>
Date: Fri, 29 Aug 2003 20:43:10 -0700

>> Can't we just hack the mailman configs to dump mails with X-sender
value
>> of outlook or outlook express?  That would solve the problem, no;)
> 
> Well, the only problem with that idea is that we explicitly do *NOT*
have > a "Your clue must be ->THIS<- tall to ride the IETF list"
policy... ;)

The Sobig worm includes its own SMTP code, and places arbitrary values
in the header fields. The source address is forged, and so are various
other fields, including X-Mailer. The worm finds target source and
destination addresses by reading files on the user's disk, not by using
a specific Outlook or OE API. It propagates by "social engineering",
when users open some executable attachments. User can do click on
attachments with many mailers, not just Outlook and OE. In fact, the
latest versions of Outlook automatically strip such attachments.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Sat, 30 Aug 2003 00:09:42 -0400

> User can do click on
> attachments with many mailers, not just Outlook and OE.

Note that any mailer that does this violates the MIME specifications,
which specifically warn against the presentation of content-types not
known to be safe, against a mail reader implementing the ability to present
arbitrary content via a content-type parameter (e.g. "filename"),
and recommends that the most that should be done with unknown content-types
is to offer to save the content to a file.

The working group that produced MIME went to a lot of effort to research the
hazards associated with transmission of arbitrary content by email, and to
craft a series of recommendations that would minimize the harm done.  One
vendor in particular deliberately ignored those recommendations.  It also 
produced mail readers that didn't properly label content on outgoing mail and
ignored the content-type parameter on incoming mail, instead looking at the
suffix of a nonstandard "filename" parameter (which was only intended for use
with application/octet-stream).  When I was on IESG, a program manager with
that company (in charge of an email product) assured me that this decision was
deliberate, as it was thought that it would maximize their company's
penetration in the market.  Obviously, it did serve that end, and other
vendors of mail readers for that platform were forced to emulate (to some
degree) the nonstandard and dangerous behavior of the market leader's
products.

This decision has cost the network billions of dollars, including significant
costs to people who do not use that company's software products (and who
therefore aren't bound by its EULAs).

Words that come to mind to describe this include: Willful, Criminal, and
Negligence.  Another word that comes to mind:  Prison.  As in "some people need
to spend a lot of time there".

---

From: shogunx <[email-masked]>
Date: Fri, 29 Aug 2003 01:45:43 -0400 (EDT)

On Fri, 29 Aug 2003, Christian Huitema wrote:

> in the header fields.

You mean to say that there is a full MTA tucked away in there?

> The source address is forged, and so are various
> other fields, including X-Mailer.

Perhaps you misunderstood my intentions.  My intentions accociated with
this post had nothing to do with the worm.

> The worm finds target source and
> when users open some executable attachments.

Since when is social engineering a desktop activity.  The last time I
checked, social engineering was along the lines of thank you for the shiny
new job, now i'm going to hide a rouge server on your network.

> latest versions of Outlook automatically strip such attachments.

I'm glad I don't have to click on my mail.

> -- Christian Huitema

sleekfreak pirate broadcast
world tour 2002-3
live from the pirate hideout
http://sleekfreak.ath.cx:81/

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 30 Aug 2003 15:26:38 +0859 ()

Keith;

MIME developers are.

MIME is too much e-mail centric.

Whether one use content-type or file name is irrelevant to mail
security, just as whether one use uuencode or base64 is
irrelevant, on both of which MIME developers wasted a lot of time.

> It also 
> with application/octet-stream).

On most OSes, including but not limited to UNIX, that's the way to
designate content types of files.

MIME should have followed the practice and IANA could be the central
authority to register filename extensions with their possible security
holes.

Instead, MIME developers arrogantly claimed that OSes should be
modified to support MIME content-type (and even that text files
on OSes should use MIME format to support other tags such as
charset).

Rest of us righteously ignored it.

> Negligence.

Exactly. But, see above.

							Masataka Ohta

---

From: [email-masked]
Date: Sat, 30 Aug 2003 12:57:19 -0400

> MIME is too much e-mail centric.

For an E-mail centric protocol, it's worked pretty well on port 80....

> designate content types of files.

But it's not *universally* true, so you have to come up with some sideband
way of conveying information.  And in fact, even if two systems both
support extensions as a *mandatory* flagging, you can still run into
trouble - what if the two systems don't use the *same* extension for
a filetype that should be portable?  Should a postscript file end in .PS,
.ps, .PST?  Should a VisualBasic script be .VB or .VBS?  Is a image/jpeg
file a .JPG or .JPEG?

And if extensions are non-mandatory, it's just a mess.  Think about the
security implications of "Here's an executable called foo.JPG" (Microsoft
didn't - that's the basic cause of MS03-032).

> on OSes should use MIME format to support other tags such as

No.

This claim is right up there with "SMTP developers arrogantly claimed
that OSs should be modified to support network-standard EOL".

And of course they didn't.  They merely insisted that the user agent at
either end convert to/from the local format.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 31 Aug 2003 08:41:15 +0859 ()

Valdis;

> For an E-mail centric protocol, it's worked pretty well on port 80....

MIME worked on port 80 only as well as pre-MIME 822.

MIME worked pretty badly with the rest of the OS.

All that was necessary is to document file name extensions such as
"tar", "uu" and "822" and email could have worked better with OS.
MIME complexities such as multipart and base64 is just a reinvention
of wheel.

> trouble

No.

> - what if the two systems don't use the *same* extension for
> a filetype that should be portable?

It's just an issue of escaping.

Add, say, "X", if some extension is reserved on some OS.

> Should a postscript file end in .PS,

Should a MIME content type of postscript file be "PS", "ps", "PST",
"postscript" or "PostScript"? Should a VisualBasic script be "VB", "VBS"
or "visual-basic"?  Is a image/jpeg file a "JPG" or "JPEG"?

It's just an issue of registration and registration authority.

> that OSs should be modified to support network-standard EOL".

Wrong. It is not a line format issue but an issue of OS internal features.

MIME developers arrogantly assumes OSes should support file type
using MIME content type.

And poor OS developers, such as Microsoft, actually did so.

> either end convert to/from the local format.

The local format does support ASCII file names but have no room
to store content type.

							Masataka Ohta