Re: Handling application/octet-stream

1997-08-27 22:29:08
to follow up on what Earl Hood said:

The following is a message from the comp.mail.mime newsgroup.
I think it is appropriate with the current discussion about
setting the right MIME types in mail messages and potential
problems using heuristics to getting around mis-typed data.

[Allegations from Keith Moore that guessing the proper Ap for
a file from its file extent is a security risk.]

I don't get it at all.  The file that you got in the mail is a
equally a threat whether you determine what Ap owns it from its
file extent or from its MIME headers.  Having the MIME
application/whatever subtype set right in the headers doesn't
provide any added measure of security, so far as I can tell.

I suppose that there is some chance of random mayhem if you
launch the right file in the wrong Ap.  But how much chance?

If the file is an attack, the attack will be against the Ap that
goes with its file extent, which will be the Ap that goes with
its MIME subtype if that is set precisely.

application/octet-stream is application/no-further-info.

That is to say _the MIME header_ gives you no further information
about what kind of application this file belongs to.  This cannot
plausibly be interpreted as "don't believe anything that the file
name suggests."

The fact that the header hasn't told you doesn't mean that the
file name speaks falsely.  The header gives you no further
information on the applicability of Aps and it give you no
further information on the significance or trustworthiness of the
filename.  It simply doesn't say.  There are risks in guessing
Aps from file names.  But the risk doesn't go up by dint of
having an application/octet-stream indication in the MIME
headers.  And it hardly goes down if a precise subtype is set in
the MIME header, because the file type table of the sender is as
likely to be messed up as the file type table locally is to be
different from the sender's.  At least there are lots of HTTP
servers out there that don't know the types of their files.  It
would be interesting to have statistics on what was right when
the file extension and MIME-subtype indication disagree.

Either the file extent or the MIME header can be set with malice
or with benevolence.

But getting the right Ap to apply to the file is not security.
It is necessary for anything -- good or bad -- to happen.  The
bad stuff happens after that.


Sorry about that digression, but it vaguely relates to the
question I have about the actual thread:

I don't really understand why MHonArc _needs to know_ that this
particular application/octet-stream file belongs to FrameMaker.
What is MHonArc going to do?  Store and link to a binary file.
If the plain text of the message identifies to a human reader
that the file is for FrameMaker, then they can recover it as a
binary file and proceed.  MHonArc never needed to know.

This is the safe thing to do: force a manual application of 
Frame against the foreign file.  Don't let it be automatically

The application/octet-stream is the safer way to go.

But the security feature is the manual confirmation before
anything is done with the file.  It has very little to do with
whether you are guessing that the file extent has told you the
right Ap or the MIME header has told you the right Ap.  Manual
execution of the Ap that you guess from the filename is safer
than automatic execution of the Ap selected by noting the MIME

Confused (Al Gilman)

<Prev in Thread] Current Thread [Next in Thread>