Mimail virus

[Ned]

Hi
I received Mimail yesterday by its classic method of delivery. Luckily a
colleague had warned me about it a few days earlier so I recognized it
immediately. Not that I ever open spam attachments normally but I was
interested in how far I could go before AVG would complain. I had a look at
the file with notepad. (Unfortunately it was only added to AVGs dat files on
the 1st August so mine didnt spot it (update was due 1 hour after I received
the email) )

I didnt know that a binary, hidden within a file with an html extension,
could be executed. That's what I'm assuming - am I right?

If Im right, then what about visits to web sites. Does that make it
potentially dangerous to open ANY web page?

Ive also noticed how many Microsoft security critical updates recently have
indicated that they were fixes against web sites/users gaining control of
your PC. These updates never indicate what the true cause is. Is it likely
any of them are something to do with binaries hidden in html files?

thanks

 

[null]

Hi
I received Mimail yesterday by its classic method of delivery. Luckily a
colleague had warned me about it a few days earlier so I recognized it
immediately. Not that I ever open spam attachments normally but I was
interested in how far I could go before AVG would complain. I had a look at
the file with notepad. (Unfortunately it was only added to AVGs dat files on
the 1st August so mine didnt spot it (update was due 1 hour after I received
the email) )

I didnt know that a binary, hidden within a file with an html extension,
could be executed. That's what I'm assuming - am I right?

Read this concerning Mimail, OE, IE and M$ patches:
http://www.cert.org/incident_notes/IN-2003-02.html

If Im right, then what about visits to web sites. Does that make it
potentially dangerous to open ANY web page?

It does if you don't pay attention to your browser security settings.

Ive also noticed how many Microsoft security critical updates recently have
indicated that they were fixes against web sites/users gaining control of
your PC. These updates never indicate what the true cause is. Is it likely
any of them are something to do with binaries hidden in html files?

Most malicious exploits are aimed at a variety of vulnerabilities in
OE and IE. The list of known vulnerabilities has usually grown faster
than M$ has released patches. Some people who use these apps keep up
with the latest versions, and patches. They set OE to work only with
text and not HTML. They never allow scripts or activex controls to run
in IE except perhaps in trusted sites. Others prefer to not use IE and
OE at all. We use third party apps which we either know to be or
believe to be much safer and far less vulnerable to exploits.

Art
http://www.epix.net/~artnpeg

 

[FromTheRafters]

Hi
I received Mimail yesterday by its classic method of delivery. Luckily a
colleague had warned me about it a few days earlier so I recognized it
immediately. Not that I ever open spam attachments normally but I was
interested in how far I could go before AVG would complain. I had a look at
the file with notepad. (Unfortunately it was only added to AVGs dat files on
the 1st August so mine didnt spot it (update was due 1 hour after I received
the email) )

I didnt know that a binary, hidden within a file with an html extension,
could be executed. That's what I'm assuming - am I right?

Evidently. You *did* know that it could be done with HTML
e-mail though didn't you? I think that this beast uses MHTML
protocol to make the HTML into what is essentially a MIME
encapsulated HTML e-mail, and all that that means as far as
autoexecuting malware is concerned.

If Im right, then what about visits to web sites. Does that make it
potentially dangerous to open ANY web page?

No, only the malicious ones. ;o)

Ive also noticed how many Microsoft security critical updates recently have
indicated that they were fixes against web sites/users gaining control of
your PC. These updates never indicate what the true cause is. Is it likely
any of them are something to do with binaries hidden in html files?

If you read the security advisories, and all of the details about
the patches (and follow links to CERT and others) you can
usually get further information about them.

 

[Ned]

I didnt know that a binary, hidden within a file with an html extension,

Evidently. You *did* know that it could be done with HTML
e-mail though didn't you? I think that this beast uses MHTML
protocol to make the HTML into what is essentially a MIME
encapsulated HTML e-mail, and all that that means as far as
autoexecuting malware is concerned.

With email, Im using oe (others Ive tried have always had quirks that send
me back) and I view in plain text.
The reason for that was to prevent my email address being confirmed remotely
during html script processing.
Ive believed that html is a scripting language (javascript, vbscript etc in
there too) but I was unaware that an executable could be hidden within it
(AM I right here?) which can be executed by opening the html document. From
the bit of scripting i did (once) I can remember there were certain
limitations to script languages that gave some security to the host system -
is there any OS security against these binaries?
Am I just being paranoid and misinterpreting what Ive seen?

No, only the malicious ones. ;o)

Oh goody, a fair excuse to turn on the porn/crackz/warez filter on the
firewall. bf wont be happy but Ill blame you ;o)

 

[FromTheRafters]

With email, Im using oe (others Ive tried have always had quirks that send
me back) and I view in plain text.
The reason for that was to prevent my email address being confirmed remotely
during html script processing.
Ive believed that html is a scripting language (javascript, vbscript etc in
there too) but I was unaware that an executable could be hidden within it
(AM I right here?)

My best guess at this time ~

I think that the issue with mimail is that an HTML e-mail (MIME encoded
executable embedded within) can be crafted and an exploit used to cause
that file to be saved in a known location on the target computer (as an error
404 text). Furthermore another exploit is used to pass that file to OE for
processing as a MIME encoded e-mail message (MHTML). A CODEBASE
exploit within that file (the HTML e-mail text file) is used to execute the
embedded attachment in the local (My Computer) security zone.

I'm not too sure about this as I have just started to try and
figure this thing out (it's kinda twisted).

which can be executed by opening the html document. From
the bit of scripting i did (once) I can remember there were certain
limitations to script languages that gave some security to the host system -

The security zone setup of Windows makes it so you can
easily control some aspects of all zones except the local
"My Computer" zone. This thing uses an exploit to "jump
the fence" so to speak into the local zone where things
are usually more lenient..

is there any OS security against these binaries?

The "My Computer" zone can be adjusted via the registry.
But I'm not sure yet what exactly needs doing.

Am I just being paranoid and misinterpreting what Ive seen?

Well...it's a jungle out there.

Oh goody, a fair excuse to turn on the porn/crackz/warez filter on the
firewall. bf wont be happy but Ill blame you ;o)

Actually, from a security standpoint, that's an excellent idea.
But telling him some idiot named FromTheRafters on usenet
told you so, probably won't help much. ;o)

 

[Nick FitzGerald]

My best guess at this time ~

I think that the issue with mimail is that an HTML e-mail (MIME encoded
executable embedded within) can be crafted and an exploit used to cause
that file to be saved in a known location on the target computer (as an error
404 text). ...

Close, but no cigar...

... Furthermore another exploit is used to pass that file to OE for
processing as a MIME encoded e-mail message (MHTML). A CODEBASE
exploit within that file (the HTML e-mail text file) is used to execute the
embedded attachment in the local (My Computer) security zone.

Yes, kinda. There are several ways to describe this and that is not really
incorrect, but I think it can be done more clearly...

The whole set of tricks works like this:

1. A "bad file" (in this case foo.exe which is an instance of the Mimail
mass-mailer executable) is encoded into a very crude MHTML form (arguably an
"imporoper" MHTML under thr RFCs covering construction of such files --
RFC 2389 and RFC 2557 in particular).

2. This MHTML file also contains some HTML and script code and has a .HTML
extension.

3. This .HTML file is put into a .ZIP archive which is mass-mailed to
initially spread the virus.

4. A recipient of such an Email message and with a suitably vulnerable web
browser (i.e. IE) associated with .HTML files receives and opens the message.
S/he reads the message and double-clicks the .ZIP attachment (.ZIP files are
basically "safe", right?) and sees the .HTML file within.

5. Recipient thinks (??? OK, so I'm being generous -- perhaps it is not your
"typical user") ".HTML files are basically safe right? I mean, that is what
the WWW is made up of..." so double-clicks the .HTML file (from 2.) in the
..ZIP file's contents listing.

6. Problem. No (?) typical zip programs know (or care!) about the niceties
of IE's security zones. None know (or care!) that the ZIP file thay have just
been asked to open has been delivered via the web browser or as an attachment
to an Email message. Result? Although the mail client may have extracted the
temporary copy of the .ZIP attachment to IE's TIF (OE should), the .ZIP file
handling program will (almost certainly in almost all cases) extract its
temporary copies of .ZIP file contents (such as the .HTML file double-clicked
in 5.) to the system temporary files directory (i.e. %temp%).

7. The .ZIP handler (WinZip, PowerZip, WinRAR, WZip, etc, etc, etc, etc, etc)
then calls the OS to "open" the .HTML it has just dropped into %temp%. On a
typical Windows machine IE will be called, and as the .HTML file it has been
asked to display is outside the TIF none of the usual security restrictions
will apply and code in the .HTML file will be able to do (almost) anything
unprompted. (In fact, such .HTML files have almost all the power of .HTA
"applications" apart from the .HTA-specific window controls that allow .HTAs
to hide their windows, change their window titles and a few other largely
cosmetic things.)

8. IE parses the odd .HTML file (there's a great deal of "useless junk" at
the top of the file) but eventually sees the script and HTML code from 2. near
the end of the file. This code refers back to the encoded foo.exe inside this
same HTML file (the "great deal of 'useless junk' at the top of the file") via
an MHTML: protocol reference inside an exploit of an old object codebase
vulnerability, which executes the extracted foo.exe file.

The codebase exploit mentioned in step 8. was actually fixed quite some time
back -- MS02-014:

http://www.microsoft.com/technet/security/bulletin/MS02-014.asp

_EXCEPT_ in the "My Computer" security zone. It has been known since at least
February this year that the "My Computer" zone was still vulnerable to this
exploit, as two PoC exploits -- showing how to use it in just the way MindJail
(aka Mijail) did a few weeks ago, the way several "manual" mass mailouts of
some RATs/IRC bots have in the last couple of weeks and, of course, the way
Mimail did -- were released that month. I've been told (but have not tested
it myself) that this "My Computer" codebase flaw was _silently_ fixed in the
latest IE cumulative patch (i.e. there is no reference to it in the official
Security Bulletin describing the cumulative patch):

http://www.microsoft.com/technet/security/bulletin/MS03-015.asp

Hopefully that all helps soemwhat...

I'm not too sure about this as I have just started to try and
figure this thing out (it's kinda twisted).

....it certainly is and you did a good job as far as it went (as I said, not
really wrong, but not quite oriented to cover all the angles and twists).

The security zone setup of Windows makes it so you can
easily control some aspects of all zones except the local
"My Computer" zone. This thing uses an exploit to "jump
the fence" so to speak into the local zone where things
are usually more lenient..

But that is incorrect.

There is _no_ exploit invloved in the fence jumping _in this case_. There
certainly have been some trivial hole punches to get through that fence in
the past, but this one simply depends on the fact that users can easily be
their own worst enemies. The security zone fencing flaw here is more that
unless _every_ piece of code honours security zone information and "real"
security zone ring-fencing around "possibly restricted" "data" is enforced
by the security zone system, then it can never be more than a toy (have I
ever told you that, from observing how their software is designed, it is
abundantly clear MS programmers do not understand security?).

The big flaw in the process outlined above happens at step 4. -- the user
chooses to introduce an application that is "outside" the security zone
"model". True, most users do not have the savvy to realize that using a
..ZIP handling program may be introducing a serious security threat, but we
all know users in general cannot be trusted to care particularly for
security. This type of ambiguity is one of the reasons why I so strongly
disagree with the MS approach of making "the desktop" and "the Internet"
seamless. To do so _vaguely safely_ requires a fundamentally different
security model from any in any MS code ever produced. Given MS's abundant
security failures to date, the likelihood of it getting even 10% of the
design of such a system right seems a distant hope...

The "My Computer" zone can be adjusted via the registry.
But I'm not sure yet what exactly needs doing.

Simply set another zone to the settings you want for "My Computer", export
that zone's key to a .REG, edit the .REG to change the key name from "1"
through "4" (depending on which zone you modified) to "0", then import the
..REG back into the registry (if doing this "very tidily" you would also
delete the Description, Display Name, Icon, MinLevel, RecomendedLevel and
maybe Flags values -- I'd have to look more closely at Flags to see what
causes it to change...).

Alternately -- and much nicer -- enable display of the "My Computer"
security zone on IE's Security tab, and thus enable standard point and
click editing of its settings. To do this, simply find the current value
in the registry:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0\Flags

and _subtract_ 32 decimal (20 hex) from that value. By default I think it
will normally be 33 decimal (21 hex) so you'd change it to 1. You may
prefer to change this for all (new) users of the machine by setting the
same value under the HKU\.Default and HKLM trees.

BUT, that wouldn't help much here. I think you'd have to make some very
restrictive settings to prevent the local exploit from inside the MHTML
file Mimail uses -- perhaps so restrictive as to make viewing of locally
saved HTML files all but useless (unless they only contained very simple
HTML). Again, the "proper" fix is to have already had the MS patch in
place (and better still, for MS to have fixed the flaw in all affected
security zones when it was first made aware of the flaw, even if its staff
could not see a likely means of exploitation -- after all, they are drawn
from the same bunch of rocket scientists as designed the broken model and
wrote the partial implementation of it in the first place...).

 

[FromTheRafters]

"FromTheRafters" <[email protected]> to "Ned":
[snip]

My best guess at this time ~

I know how much people hate the wild assed guesses, but
I thought it would create the perfect opportunity for someone
to correct me. My guess was based on reading about some of
the vulnerabilities used (not all of which actually pertained to
this case), and guess the rest. I was aware of your conversations
with "http-equiv" and hoped you would clarify.

Close, but no cigar...

Damn, and I was so hoping for a 'stogie'. :O(

Yes, kinda. There are several ways to describe this and that is not really
incorrect, but I think it can be done more clearly...

The whole set of tricks works like this:

1. A "bad file" (in this case foo.exe which is an instance of the Mimail
mass-mailer executable) is encoded into a very crude MHTML form (arguably an
"imporoper" MHTML under thr RFCs covering construction of such files --
RFC 2389 and RFC 2557 in particular).

2. This MHTML file also contains some HTML and script code and has a .HTML
extension.

3. This .HTML file is put into a .ZIP archive which is mass-mailed to
initially spread the virus.

I've seen mention of a "mimail.downloader" being mass-mailed as well.

4. A recipient of such an Email message and with a suitably vulnerable web
browser (i.e. IE) associated with .HTML files receives and opens the message.
S/he reads the message and double-clicks the .ZIP attachment (.ZIP files are
basically "safe", right?) and sees the .HTML file within.

So there is not an autoexecuting exploit in the e-mail, it is in the
MHTML file (with a .html extension) within a .zip attachment?

5. Recipient thinks (??? OK, so I'm being generous -- perhaps it is not your
"typical user")

Hahaha ~ understood!

".HTML files are basically safe right? I mean, that is what
the WWW is made up of..." so double-clicks the .HTML file (from 2.) in the
.ZIP file's contents listing.

....but the file is actually an MHTML with the wrong extension?
Is this an important consideration with regard to Ned's query?
Would a *real* (normal?) HTML file ever contain an exploit
to autoexecute an embedded MIME encoded executable, or
is this really *only* an MHTML feature?

6. Problem. No (?) typical zip programs know (or care!) about the niceties
of IE's security zones. None know (or care!) that the ZIP file thay have just
been asked to open has been delivered via the web browser or as an attachment
to an Email message. Result? Although the mail client may have extracted the
temporary copy of the .ZIP attachment to IE's TIF (OE should), the .ZIP file
handling program will (almost certainly in almost all cases) extract its
temporary copies of .ZIP file contents (such as the .HTML file double-clicked
in 5.) to the system temporary files directory (i.e. %temp%).

Aha! ~ *there* goes the security!

7. The .ZIP handler (WinZip, PowerZip, WinRAR, WZip, etc, etc, etc, etc, etc)
then calls the OS to "open" the .HTML it has just dropped into %temp%. On a
typical Windows machine IE will be called, and as the .HTML file it has been
asked to display is outside the TIF none of the usual security restrictions
will apply and code in the .HTML file will be able to do (almost) anything
unprompted. (In fact, such .HTML files have almost all the power of .HTA
"applications" apart from the .HTA-specific window controls that allow .HTAs
to hide their windows, change their window titles and a few other largely
cosmetic things.)

8. IE parses the odd .HTML file (there's a great deal of "useless junk" at
the top of the file) but eventually sees the script and HTML code from 2. near
the end of the file. This code refers back to the encoded foo.exe inside this
same HTML file (the "great deal of 'useless junk' at the top of the file") via
an MHTML: protocol reference inside an exploit of an old object codebase
vulnerability, which executes the extracted foo.exe file.

The codebase exploit mentioned in step 8. was actually fixed quite some time
back -- MS02-014:

http://www.microsoft.com/technet/security/bulletin/MS02-014.asp

_EXCEPT_ in the "My Computer" security zone. It has been known since at least
February this year that the "My Computer" zone was still vulnerable to this
exploit, as two PoC exploits -- showing how to use it in just the way MindJail
(aka Mijail) did a few weeks ago, the way several "manual" mass mailouts of
some RATs/IRC bots have in the last couple of weeks and, of course, the way
Mimail did -- were released that month. I've been told (but have not tested
it myself) that this "My Computer" codebase flaw was _silently_ fixed in the
latest IE cumulative patch (i.e. there is no reference to it in the official
Security Bulletin describing the cumulative patch):

http://www.microsoft.com/technet/security/bulletin/MS03-015.asp

Hopefully that all helps soemwhat...

Yes, but I'll probably have to read this post a few times before
the facts sink in.

...it certainly is and you did a good job as far as it went (as I said, not
really wrong, but not quite oriented to cover all the angles and twists).


But that is incorrect.

Another cigar not awarded. :O(

There is _no_ exploit invloved in the fence jumping _in this case_. There
certainly have been some trivial hole punches to get through that fence in
the past, but this one simply depends on the fact that users can easily be
their own worst enemies. The security zone fencing flaw here is more that
unless _every_ piece of code honours security zone information and "real"
security zone ring-fencing around "possibly restricted" "data" is enforced
by the security zone system, then it can never be more than a toy (have I
ever told you that, from observing how their software is designed, it is
abundantly clear MS programmers do not understand security?).

Hmmm...you might have mentioned it...a few times.

The big flaw in the process outlined above happens at step 4. -- the user
chooses to introduce an application that is "outside" the security zone
"model". True, most users do not have the savvy to realize that using a
.ZIP handling program may be introducing a serious security threat, but we
all know users in general cannot be trusted to care particularly for
security. This type of ambiguity is one of the reasons why I so strongly
disagree with the MS approach of making "the desktop" and "the Internet"
seamless. To do so _vaguely safely_ requires a fundamentally different
security model from any in any MS code ever produced. Given MS's abundant
security failures to date, the likelihood of it getting even 10% of the
design of such a system right seems a distant hope...


Simply set another zone to the settings you want for "My Computer", export
that zone's key to a .REG, edit the .REG to change the key name from "1"
through "4" (depending on which zone you modified) to "0", then import the
.REG back into the registry (if doing this "very tidily" you would also
delete the Description, Display Name, Icon, MinLevel, RecomendedLevel and
maybe Flags values -- I'd have to look more closely at Flags to see what
causes it to change...).

Alternately -- and much nicer -- enable display of the "My Computer"
security zone on IE's Security tab, and thus enable standard point and
click editing of its settings. To do this, simply find the current value
in the registry:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0\Flags

and _subtract_ 32 decimal (20 hex) from that value. By default I think it
will normally be 33 decimal (21 hex) so you'd change it to 1. You may
prefer to change this for all (new) users of the machine by setting the
same value under the HKU\.Default and HKLM trees.

BUT, that wouldn't help much here. I think you'd have to make some very
restrictive settings to prevent the local exploit from inside the MHTML
file Mimail uses -- perhaps so restrictive as to make viewing of locally
saved HTML files all but useless (unless they only contained very simple
HTML). Again, the "proper" fix is to have already had the MS patch in
place (and better still, for MS to have fixed the flaw in all affected
security zones when it was first made aware of the flaw, even if its staff
could not see a likely means of exploitation -- after all, they are drawn
from the same bunch of rocket scientists as designed the broken model and
wrote the partial implementation of it in the first place...).

Thanks for the detailed explanation.

 

[null]

I remember getting a Windows Critical Update which was described
something like this: "This update fixes a vulnerability in Interent
Explorer. Please note that the vulnerability exists even if you use a
different browser." I use XP Pro SP1. So thanks a lot, Microsoft, for
making my computer vulnerable to attack by embedding your garbage
internet software in my operating system even though I've always used
Netscape.

That's a question that has arisen here in the past. I used IEradicator
years ago on my Win 98 PC and abandoned IE/OE patches since I cleaned
OE off the PC as well. But I did install the critical OS patches and
updates. More recently, I've done the same with my present Win ME
machine. In the latter case M$ forced me to temporarily d/l and
install IE in order to d/l the patches (*>?#*).

I don't suppose you remember which IE patch it was? I'd like to
investigate this further. I have tried to test IE vulnerabilities
using Mozilla as the browser at the vulnerability demo sites. Of
course, the vulnerabilities I've been able to find demos of don't show
any vulnerabilities. But that's not to say that there might be one. I
seriously doubt that after using IEradicator there are any IE related
vulnerabilities but I can't be certain.

Art
http://www.epix.net/~artnpeg

 

[Nick FitzGerald]

I know how much people hate the wild assed guesses, but
I thought it would create the perfect opportunity for someone
to correct me. My guess was based on reading about some of
the vulnerabilities used (not all of which actually pertained to
this case), and guess the rest. I was aware of your conversations
with "http-equiv" and hoped you would clarify.

I didn't mean the comment as a criticism. It was a good guess and mainly not
inaccurate -- it's just I could fill in more details. That said thjough, your
best guess was better than a number of the inarticulate bumblings posted on
security and AV web site descriptions of the virus...

Damn, and I was so hoping for a 'stogie'. :O(

Well, they're not good for your lungs, so count yourself lucky!

I've seen mention of a "mimail.downloader" being mass-mailed as well.

Ditto -- I don't know if this is really a "Mimail downloader" (which would seem
kinda pointless unless perhaps it was some kind of trial -run, but even then,
I'd have thought the "single point of failure" flaw with such schemes is so well
understood by now that no-one would be dumb enough to bother trying such again!)
or a downloader that used the same encoding sequence as Mimail. (Many AV
researchers are so stupid as to not comprehend the utter irrelevance of such
"coincidences" when assigning names and happily confuse the tits off most of the
rest of the world by coining idiotic names based on such coincidences and
irrelevancies.)

So there is not an autoexecuting exploit in the e-mail, ...

Correct -- the user _must_ choose to open the ZIP file (or perhaps must have a
_very_ whacky Email client! ).

... it is in the
MHTML file (with a .html extension) within a .zip attachment?

Yes, sort of.

_But_, given the security zone has been broken "manually" (and MS would probably
argue -- and it is hard to debate against -- "deliberately"), HTML files can do
almost anything from inside the "My Computer" zone, so although the .EXE runs
"automatically" as the result of exploiting a flaw in IE, I do not really see
that calling this an "auto-execution exploit" helps a great deal (the HTML and
script could just as easily have used all manner of ActiveX controls that, when
run from the "My Computer" zone are perfectly in their rights to write to files,
mess with the registry, etc, etc). However, there is an "unexpected result" of
"reading" that HTML file and such is clearly undesirable, regardless of whether
you labael it an expolit of an auto-execution vulnerability, a security zone
permissions flaw or whatever...

...but the file is actually an MHTML with the wrong extension?

Kind of, _but_ also kind of not...

At one level there really is no difference between HTML and MHTML files, at least
as far as the parsers IE uses are concerned. The point is that the .HTML file
extension is what causes the shell to request IE to "open" the file that was
(temporarily) extracted from the .ZIP file (by whatever program the user has set
to handle .ZIP files) by the user double-clicking the .HTML within the .ZIP. IE
starts parsing the file, sees the first "meaningful HTML" near the end of the
file (in the script and object tags) and starts trying to parse and display that.
In turn, part of that code causes IE to refer back to the same file but explicitly
as MHTML format (by using the MHTML: (pseudo-)protocol) and that is what gets the
foo.exe file extracted to a referencable location outside the TIF allowing it to
be subsequently executed by another twist in the script and object tags.

Is this an important consideration with regard to Ned's query?
Would a *real* (normal?) HTML file ever contain an exploit
to autoexecute an embedded MIME encoded executable, or
is this really *only* an MHTML feature?

There are other ways to embed encoded .EXE files inside "real" HTML files (by
that I mean not HTML files that are also kinda valid (to IE) MHTML files) that
can then be dropped and executed (through other, non-MHTML means), so the answer
is yes, HTML files can be dangerous (especially if moved into the "My Computer"
security zone -- the general fix to this, of course, is use a better browser).

Aha! ~ *there* goes the security!

Yep -- if a burglar knocks at the door at 3:00am, dressed all in black, wearing
a balaclava and carrying a large bag of tools and you invite him in then go back
to bed, would you be surprised to find the safe cracked in the morning and the
family jewells all stolen? Of course, to the typical user, this is a far less
obvious case -- few would invite the "obvious burglar" to cross the doorstep and
enter the drawing room, but many will invite the "obviously dubious" (to folks
like us that is) .ZIP handler to step across that most critical of security zone
thresholds and enter a potentially dangerous file type into the "My Computer"
security zone _then execute it_ (it's partly that "open" vs. "run" thing -- file
types than can contain "code" that can be run during "normal" handling of those
files should not be allowed to be fererred to as "being opened" (apart from in
the case of a plain "viewer" type application such as a hex viewer) but, of
course, we have long since lost this most important linguistic battle).

Yes, but I'll probably have to read this post a few times before
the facts sink in.

I think I warned at the outset that it was not "easy" but involved a quite
convolted sequence of issues and tricks. Personally, as clever as the execute
through MHTML: protocol via codebase exploit in the local zone trick is, the
most important thing for Mimail is the user's sense of relative safety in
"opening" a .ZIP file ("after all, the latest security fixes in Outlook and OE
allow such files through so they must be safe") and then of "opening" a .HTML
file from within a .ZIP. While the latter is something they are unlikely to have
done before, they are again likely to believe that the .HTML type is "safe".
The relative success of MindJail (aka Mijail) several weeks back should have
warned us of how "successful" something akin to Mimail was likely to be as
MindJail used the same basic sequence of "exploits" (technical and SE) b ut only
spread through IRC spamming of URLs to copies of itself from its own "web server"
running on the previous victim's machine.

Thanks for the detailed explanation.

You're welcome.

 

[FromTheRafters]

I didn't mean the comment as a criticism.

It wasn't taken as such. )

It was a good guess and mainly not
inaccurate -- it's just I could fill in more details.

I had hoped that you would. Some of my guess was
based on the web based exploit of the MHTML
URL handler vulnerability, which, as it turns out, wasn't
even used in the worm.