Attachment Security, Part Deux
Here's Part One.
this isn't really a continuation of the history, but rather some more
rambling on some of what I discussed in part one. I just wanted an
excuse to say "Part Deux".
After the news reports about
the first big email-borne viruses like Melissa started showing up, stories would
pop up on Slashdot from time to time that ripped Outlook to shreds. As I
mentioned in the
footnotes of Part One, I'm all for assigning blame where blame is due when
there is a bug in the code or design flaw (like not displaying extensions by
default in the shell - oh boy) that results in a security hole, but a lot of the
people who ranted incessantly about Outlook's insecurity had obviously never
used it, and certainly had no idea how it worked.
I hope that these
days these misconceptions aren't still around (or as prevalent), but don't keep
tabs on this area enough to know for sure. Admittedly, most of these are
probably "duhs" for the core audience of this blog, but I do get a wide variety
of readers and plus, I think it's an interesting topic (probably because so much
of my life was once spent chasing these things down, it's hard to let go). Some
of these were also covered a while back
on slipstick, but hey, it's my blog, so I'll talk about it some
- Misconception #1:
Outlook opens attachments without user intervention.
- A lot of people (of
the slashdot variety, at least) thought that Outlook's design was to
automatically launch attachments when an email was received or opened. No. That
would just be silly.
- Plus, it's so easy
to get [enough] people to open a message with simple social engineering
techniques ("What? A bill for a pearl necklace? I ordered no such thing!" or
"What's this, oh the latest patch from Microsoft to keep me secure, I read how
insecure they were in the NYTimes, I better run this to stay safe!"), you
wouldn't even need this functionality to spread a virus. Or heck, as Peter
mentioned a while back, who even needs social engineering? It's all about
the end user, baby.
- A lot of people (of
- Misconception #2:
Just tell users not to open attachments from people they don't know and you
won't have a problem.
- First problem with
this statement: "Just tell users". I hope we all know by now that user education
can only go so far (during the height of the attacks, our corporate security
group put pamphlets around the entire campus, the most well-read of these were
probably the ones in the elevators and the inside of stalls in the bathrooms).
Although software manufacturers still need to do as much as they can to help
users make the right decisions and IT administrators need to guide their users
as much as possible, user education alone will never solve the entire problem.
As Raymond, Eric or
can tell you, users are curious creatures and most don't read dialogs
anyway. Think about it - do you? One of my favorite quotes from this
slashdot thread was this "Most users do NOT want their email to
be able to destroy their entire system, and thus would be perfectly happy if
said executables ran in a "jail" that couldn't affect the rest of the filesystem
without a prompt. "This program is attempting to delete c:\windows\SOMEFILE.EXE,
should I allow it to do that? (OK/CANCEL). " As I covered in my first
ramble on this topic, popping up dialogs does not a security system
- Second problem with
this statement: Only the earliest or the most simple of email-borne viruses
could be avoided by this problem. Explore.Zip was the first one I recall that
replicated by replying to messages in the users' inbox - ingenious at the
- First problem with
- Misconception #3:
Because unix clients have an executable bit and most mail clients don't set this
bit on attachments saved from an email by default, these viruses would never
have spread on unix machines.
- I dug up an
old slashdot article where some posters mentioned this. One person posted a
[perfectly valid and reasonable] comment that average end-users would open
any attachment regardless of file extension, and got many snarky
responses such as "Ever heard of something called the 'execute permission bit'?"
and "Since in order for this to work you need mail software which treats emails
as executable code. Something which is rather specific to Windows apps (and
Windows itself.)" I hope that the existence of Bagle and other such
viruses stops anyone from thinking that the lack of the executable bit being set
by default would prevent many end-users from opening an attachment. Bagle
included a password-protected .ZIP attachment, with the password in the message
body. If these same users were using linux clients and received an email telling
them to "Save greetingcard.exe locally and run chmod 755 greetingcard.exe",
they'd do it.
- Also, as the
expansion in virus type over the last few years has shown, it's not just
executable filetypes that are the problem. AnnaKournikova.html as an attachment,
when opened, has the potential to wreak havoc on a machine - whether that be
from an exploit in the HTML rendering engine that results in a buffer overrun
or browsing to a phisher's website that pretends to be a porn site that asks for
credit cards as validation or heck, who knows, MicrosoftSafetyInstructions.html
that tells users they might be infected with a virus if they have a file named
ntldr and how they need to delete it.
- I dug up an
- Misconception #4:
Just have a client-side anti-virus scanner installed and you'll be
this is an important part of the solution, but just a part. Many antivirus apps install filesystem
filters so that as files are written to the filesystem, the AV app gets
notification of their existence (if real-time monitoring is enabled) and can
scan the file before releasing it for the rest of the system to use. This is all
goodness, but any detection that relies on signatures (and automatic
updating of those signatures, and real-time scanning being enabled, and and
and...) is always going to lag behind the industry discovery and deconstruction
of the culprit, and the subsequent publishing and client updates of those new
- More recent
versions of the AV apps install network filters as well, another layer in the
- Misconception #5:
If I'm protected from bad attachments, I'm safe.
- The existence of
HTML viruses and the creation of the phishing
industry have knocked this one out of the park. As far as HTML viruses go, the
only ones I'm aware of were due to bugs in HTML rendering engines vs "working as
expected" behavior, however. But phishing - whoo boy. This is a new avenue entirely and a
the industry (including
us) are working on technology to help combat it. Plus there are less severe
security vulnerabilities like web bugs that let spammers know you read the
2003 & OWA
2003 help protect against this but ultimately it comes back down to the
- The slashdot
thread I've quoted a few times has a real doozy on this issue. In response
to one person's [perfectly valid and reasonable] comment about how any mailer
that renders HTML is at risk, someone said: "Don't be rediculous [sic]
here. How can you say that ANY MAILER that renders HTML is vulnerable to an
attack? Does that apply to my browser accessing my webmail account?
Though Outlook may have some problems here, it is entirely acceptable
to believe that a mailer can render HTML emails in a safe and protected way. And
has introduced have not been severe. The security problems here are not inherent
not confuse the problem."
- Actually, it's
quite easy to say that any mailer that renders HTML is vulnerable to an attack.
And yes, it applies to browsers accessing webmail accounts. And no, it's not
acceptable to believe that a mailer can ever be written to guarantee
that it renders HTML email in a safe and protected way. Code is code is code.
Mailers by definition display external content. Code has bugs. Bugs can have
serious consequences. External content increases the risk of a bug having
- The existence of
- I'm sure I'm
missing some. If they come to me, I'll write another post. Or feel free to add a
One of the most
disturbing comments I've ever seen on slashdot: "Why can't these virus writers
do something cool?". Oh boy. I
really hope the people who write those kind of comments are still kids
with a lot to learn versus engineers in the software industry.
This is an industry problem. We
need to solve it with better software, better documentation, better user
guidance, better IT pro guidance, legal ramifications and more. We've made huge
strides over the last few years but there's still a ways to go if
something like Bagel can still be so destructive, as Peter mentioned.
 These are a
great idea in theory, but boy did one of them drive me nuts trying to
troubleshoot a problem on my mother's laptop a few months ago. Outlook wasn't
able to send mail via SMTP, so I thought I'd "remove Outlook from the picture"
and just telnet to port 25 to figure out what was wrong. Every time I did an
EHLO I kept getting an SMTP error from Exchange. It didn't repro from any other
machine, and I pounded my head against the wall for two hours about this, until
I got a big floating lightbulb over my head and checked the AV app options and
yep, network scanning was enabled. Disabled it and boom, problem solved. Turned
out it was a bug in the AV app.