July 2009
Emailing Attachments versus Sending Links (23 July 2009)

Emailing Attachments versus Sending Links

23 July 2009

During a discussion of cybersecurity issues with some (non-cybersecurity) colleagues, I offered to provide a certain PDF document I’d seen on the web. One said "send the URL, not an attachment, because I won’t open attachments". Was he right? Is that really a safer course? That turns out to be an interesting, non-trivial question, and there’s no one answer.

There are two principles I used in my analysis. First: most security problems are due to buggy software. Thus, the less software that is used, the safter you are. Second, though any piece of software can be buggy, experience has shown that some are much worse than others.

There’s also one simplifying assumption: in a few places (which I’ve noted), I assume that if two pieces of software have the same "genetic material" — Firefox and Thunderbird, or Internet Explorer and Outlook — then they will use the same piece of code if there’s a common function. That is an assumption; for various reasons of their own, developers may decide to write their versions, even if the partner program already has suitable code.

So: suppose I email an attachment. What are the security-sensitive steps affecting the recipient?

The email must be received by the recipient’s mail server. Most likely, it will be scanned for viruses at this point, and then stored. Neither of these steps is common for web access, though many times web browsing is done via a proxy server or firewwall which may or may not do some scanning. Still, there’s a small security advantage here to the URL option, since there are fewer pieces involved.

Next, the email is downloaded to some mail user agent (MUA), via a protocol like POP or IMAP. This is a relatively simple operation, and corresponds pretty closely to a web download. In particular, attachments are packaged using MIME (Multipurpose Internet Mail Extensions). MIME is pretty complex in spots, but it turns out that web servers also use MIME to send web pages. At this level, then, the two options are equivalent, and (for software cousins) quite possibly use a lot of the same code.

Using encryption to retrieve email is considerably more common than using encryption to access web pages; possibly, there’s some incremental risk if the document of interest has a bad interaction with the encryption layer. I rate the differential risk on this as low, not because encryption software can’t have security bugs — it can — but because a flaw of this nature would affect all email retrieval or all web browsing. In other words, the question of an attachment or a link isn’t really the serious risk here.

The more interesting issues concern presentation. Mailers may offer a preview of an attachment; a web browser typically has no similar feature. There is thus software in the MUA that has no analog in the browser. This software is, I suspect, rather susceptible to flaws; certainly, there have been a fair number of flaws in image and multimedia software (i.e., JPGs, movies, etc.). Advantage: URL. If your mailer doesn’t offer such a feature, or if you have it disabled, you may be safer.

But: what happens when you click on an attachment? This is the crucial difference, and one that goes to the heart of the advice not to open attachments. Here, we’re dealing with some crucial behavioral details of the MUA, the operating system, and the user. The question is simple — how is a file "opened"? — but the answer isn’t simple. It turns on a more subtle question: how does the recipient’s system know what kind of file it is, which dictates how to open it.

The MIME encapsulation used to send files has two different fields that are used. The mechanism in the MIME standard is a special line Content-Type. It can specify things like image/jpeg, application/pdf, etc. This is the MIME field that MUAs and web browsers are supposed to use to figure out how to open a file. Sometimes, though, the sending system isn’t quite smart enough about the actual Content-Type, so it sends application/octet-stream instead. Now what?

The applicable part of the MIME standard prescribes little. It says

The recommended action for an implementation that receives an "application/octet-stream" entity is to simply offer to put the data in a file … or perhaps to use it as input to a user-specified process.
Most MUAs (and their operating systems) try to be smarter: they look at the filename. Thus, if a message is received with a MIME part identified as
	Content-Type: application/octet-stream; name="assignments.doc"
the usual response is to pass the content to Microsoft Word. BUT — whether and how this mapping is established is system-dependent. And therein lies the problem: what should a system do when it receives something labeled
	Content-Type: application/octet-stream; name="useful_stuff.exe"
The proper answer, of course, is to discard it without even showing the message to the user. (My mail system does precisely that, since I have no way to do anything even with legitimate Windows executables, and no one emails legitimate ones these days…) But for years, emailing executables was common practice. There were even email encryption programs that would bundle the sensitive message with an executable that the recipient could execute to decrypt the message! Imagine the scenario: you receive email from someone, with sufficient context that you believe the matter is sensitive, and that someone else cares enough about it that they might be listening in. You then run the program that they sent you and type your decryption key into it, when in reality you have no idea who sent it to you or what the program does, at a time when you know you have an enemy who is interested in the subject…

OS vendors, at least, have learned better. No major MUA will open an executable these days (though the list of executable file types is amazingly long). Indeed, a little-noticed change in Windows XP Service Pack 2 marked email attachments and web downloads as imports, precisely to help with such issues. But have users learned better? Often, they haven’t, and Windows makes it worse. What if the attachment contains

	Content-Type: application/octet-stream; name="useful_stuff.jpg.exe"
or the like? Often — though perhaps not in MUAs — Windows will suppress displaying the extension for known file types. If I saved that attachment and then looked at the containing folder, on a default Windows system it would be displayed as useful_stuff.jpg — and Windows would even look inside the file to see what icon to display. This was a very, very, bad design choice by Microsoft.

When a file is emailed, then, there can be a lot of confusion about what it is. This is one of the biggest sources of danger: you don’t necessarily know what kind of file it is you’re opening. The advantage, then, would seem to be squarely with URLs. Not so fast…

There are two big dangers with mailed URLs. First, the apparent

page), it’s trivial to create a misleading link. Quick — where does http://www.google.com take you if you click on it? You’d have to look at the status bar to know in advance, and most people don’t do that. To be sure, most mailers catch that these days, because of phishing attacks, but there’s a more subtle danger: what the web server actually sends you may bear no relationship whatsoever to what you asked for: URLs can be rewritten. Want an example? I assert that this:

http://www.cs.columbia.edu/~smb/SMBlog-in-PDF.pdf
is a way to see my blog in PDF. If you look at the HTML source to this web page, or look at the status bar, you’ll see that the URL that is visible matches the URL that is referenced. However, I’ve configured the web server to send you an HTML page instead. When you click on a URL, you don’t really know what you’re going to get back. Furthermore, web pages can have dangers of their own: cross-site scripting attacks, ActiveX controls, all the dangers of so-called drive-by downloads. An HTML email message could have Javascript embedded, but most MUAs won’t execute such scripts. Advantage: attachments.

The biggest risk, though, has nothing to do with the mode of transport; rather, it’s the actual data. Many common filetypes (or rather, the standard programs to open them) have a history of security problems. There’s a new advisory on a critical flaw that affects Adobe Acroread, for example. (It also affects Flash on Web pages; see above…) Word, Excel, Powerpoint, and more have their own history of security problems; here’s a recent example.

So what is the answer to the original question? The download code for handling MIME is similar. Presentation risks in email versus a URL are different, but the net risk is probably comparable. The big risk was and is the content, plus the potential for confusion in attachments. As I’ve shown, though, there can be confusion either way. I suspect that overall, a mailed URL is slightly safer, but the difference isn’t large unless the MUA is very stupid (and they’ve improved over the years). The real advantage to sending URLs is that it’s more polite to do so — the recipients don’t have to download a potentially-huge file until they’re ready — but that may be outweighed by the inability to access it on, say, an airplane.

Tags: security