-- more on -- virus files this am

[Dave Farber <dave () farber net>]

> Date: Fri, 22 Aug 2003 00:21:58 -0400
> From: Keith Moore <moore () cs utk edu>
> Subject: Re: [IP] virus files this am
> To: dave () farber net
> Cc: moore () cs utk edu
>
>
> [for IP, if you wish]
>
> > I got  1300 junk emails "delivered " this AM.
> >
> > find the person and put him/her in jail .
>
> The people who are most responsible might be easier to find than it initially
> appears.
>
> The first version of the MIME standard for email attachments was published in
> June 1992.  It repeatedly warned of the dangers of executing arbitrary
> content, and recommends that such content not be executed unless it can be
> verified to be safe.   It also specifically warns against allowing arbitrary
> programs to be specified in the content-type header field.  Those warnings and
> recommendations were repated in subsequent versions of the specification.
>
> Yet Microsoft mail readers have for many years ignored these warnings and
> implemented almost exactly the behavior that was recommended against by the
> MIME specification.  The first Microsoft mail readers to support MIME even
> ignored the content-type field, allowing essentially arbitrary applications
> (i.e. anything to which a filename suffix is assigned, which on a windows
> system is almost anything) to be invoked via the content-type  filename
> parameter.  Other MUA vendors were forced to mimic that behavior for the sake
> of compatibility with Microsoft mail clients that did not supply usable
> content-type labels on outgoing mail.
>
> Given that Microsoft ignored clear and repeated indications of vulnerability
> as well as recommendations for countermeasures, it's hard to imagine that they
> are not significantly culpable for creating the breeding pool for viruses that
> have cost billions of dollars in downtime (i.e. lost revenue) and service,
> and not just for people using their software.
>
> - Keith
>
>
> RFC 1341, section 4, last paragraph:
>
>             When a mail reader encounters mail with an unknown  Content-
>             type  value,  it  should generally treat it as equivalent to
>             "application/octet-stream",  as  described  later  in   this
>             document.
>
> section 7.4.1, last two paragraphs:
>
>             The recommended action for an implementation  that  receives
>             application/octet-stream  mail is to simply offer to put the
>             data in a file, with any  Content-Transfer-Encoding  undone,
>             or perhaps to use it as input to a user-specified process.
>
>             To reduce the danger of transmitting rogue programs  through
>             the  mail,  it  is strongly recommended that implementations
>             NOT implement a path-search mechanism whereby  an  arbitrary
>             program  named  in  the  Content-Type  parameter  (e.g.,  an
>             "interpreter=" parameter) is found and  executed  using  the
>             mail body as input.
>
> appendix G (under definition of application content-type)
>
>             Security considerations:  This  type  is  intended  for  the
>             transmission  of data to be interpreted by locally-installed
>             programs.  If used,  for  example,  to  transmit  executable
>             binary  programs  or programs in general-purpose interpreted
>             languages, such as LISP programs or  shell  scripts,  severe
>             security  problems  could  result.   In  general, authors of
>             mail-reading  agents  are  cautioned  against  giving  their
>             systems  the  power  to  execute mail-based application data
>             without carefully  considering  the  security  implications.
>             While  it  is  certainly possible to define safe application
>             formats and even safe interpreters for unsafe formats,  each
>             interpreter  should  be  evaluated  separately  for possible
>             security problems.
>
> and finally (after references)
>
>             Security Considerations
>
>             Security issues  are  discussed  in  Section  7.4.2  and  in
>             Appendix  G.   Implementors should pay special attention  to
>             the security implications of any mail content-types that can
>             cause the remote execution of any actions in the recipient's
>             environment.   In  such  cases,  the   discussion   of   the
>             applicaton/postscript   content-type  in  Section  7.4.2 may
>             serve as a model for considering  other  content-types  with
>             remote execution capabilities.

-------------------------------------
You are subscribed as interesting-people () lists elistx com
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/