[20035] in bugtraq
EML Content Spoofing and Informed Consent (was: Re: MS patch
daemon@ATHENA.MIT.EDU (Dan Kaminsky)
Thu Apr 5 20:29:44 2001
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <003401c0bd59$ee7f40f0$606545ab@na.cisco.com>
Date: Wed, 4 Apr 2001 15:52:31 -0700
Reply-To: Dan Kaminsky <dankamin@CISCO.COM>
From: Dan Kaminsky <dankamin@CISCO.COM>
X-To: "JC (Kriptopolis)" <cuartango@KRIPTOPOLIS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
> A tricked EML file can confuse the user displaying him a fake downlodaded
> file name. Executable files can be disguised as other supposedly inocent
> files (text, sound or images).
> Demo is available in :
> http://www.kriptopolis.com/cua/20010404.html
> The issue was reported to MS on 22 february and they argue : this is not a
> vulnerability as far as It involves a use decision.
[The short version of this: If I try to open a MP3 file remotely, and I
actually execute a Word Macro Document or even a full fledged install of
BackOrifice, I'm the victim of a security hole: My ruleset for choosing
what to download was tricked; the trust I applied to one format(MP3) was
used upon another(EXE, DOC). The rest of this is essentially a quick
refresher in security theory for whoever at MS argued that "querying the
user, even with a spoofed query, means no security hole.", along with a
surprising connection to bioethics.]
Good example of why full disclosure is useful--I went ahead and checked out
the demo myself, and immediately found that Microsoft's argument holds
little water. Essentially, there's a simple rule of browser security that
states that explicitly asking the user to authorize a transaction with an
informed set of validated security parameters is more secure than simply
having a default list of parameters that must be satisfied and automatically
accepting if that list is accepted.
Simple web page accesses use the latter system--if all the SSL requirements
are met, the crypto link is immediately established. Authenticode, the
signed-binary implementation that Microsoft has championed for ActiveX (and
more), however, requires explicit user acceptance even *when* the
certificates are appropriately signed. This is to reflect the increased
risk that a user experiences when being asked to execute raw code vs. simply
being provided HTML, Javascript, and JPEGs. I thank Microsoft dearly for
thinking to include this step--I don't know how many sites have assumed it'd
be OK to ask me to install Flash 5, Comet Cursor, even IE5 itself. Just
because I want to see your website doesn't mean I trust you to write on my
hard drive; Microsoft is doing the right thing by not automatically
accepting any package with a trusted signature. They're even doing the
right thing by forcing a package to cryptographically identify what it
claims to be, thus preventing situations where the user is tricked into
installing the wrong content by invalid and unauthenticated HTML/JPG.
That's actually where the strongest evidence that the EML rename hack comes.
Even though the file itself isn't authenticated, the file *type* is.
*.html, *.txt and *.jpg file types don't (inherently) have major security
issues via system access; thus they're placed in a much different security
class than *.exe or *.ocx files are. If the crypto subsystem itself makes
this value judgement, surely we can presume that it's safe for far less
skilled users to make the same judgement call. And furthermore, if we
accept that it'd be an utter disaster for arbitrary executables to be
spoofed as *.jpg's and implicitly accepted for automatic execution, so too
must we accept that its a major concern that arbitrary executables can be
spoofed, using the EML hack, into any file type the user might happen to
trust.
The specific implementation of the demo uses an audio file spoofed as a text
file. A much more damaging and representative use of this attack would use
an executable or Word document spoofed as a MP3 file.
There is an interesting and unexpected (to me, anyway) parallel between
computer security and bioethics that shows up here. What we're essentially
seeking from the user is Informed Consent to risk opening the file.
Informed Consent is a term from medicine and bioethics, and effectively
refers to making sure the user/patient at risk understands what is being
done for and to them. An *excellent* summary can be found at:
http://eduserv.hscer.washington.edu/bioethics/topics/consent.html
A quick quote:
====
It is generally accepted that complete informed consent includes a
discussion of the following elements:
* the nature of the decision/procedure
* reasonable alternatives to the proposed intervention
* the relevant risks, benefits, and uncertainties related to each
alternative
* assessment of patient understanding
* the acceptance of the intervention by the patient
====
The rest of the document rings eerily familiar as well.
Yours Truly,
Dan Kaminsky, CISSP
http://www.doxpara.com
