STE WILLIAMS

Italian computer scientist Michele Spagnuolo recently wrote about what he considered a security issue in Dropbox’s popular iPhone and iPad email app Mailbox.

His report is extremely simple to describe: the Mailbox app runs any JavaScript that appears in the content of an HTML email.

And that’s the long and short of it.

Spagnuolo has street cred as a security researcher, including a recent Google reward of $3113.7 (he won the larger sum of $5000 the month before that, though it doesn’t sound so cool), but not everyone seems happy about his “vulnerability.”

Over on self-styled alpha geek technology website Ars Technica, Spagnuolo has had a bit of a hammering from some commenters.

They’re saying, “So what?”

Almost every web page, like almost every email, is in HTML, and web sites are packed with JavaScript – in fact, JavaScript was developed to jazz up HTML, and the modern web simply wouldn’t work without it.

We know there are risks, notably that JavaScript makes it easy for cybercrooks to hide malicious content in web pages so that it springs into play only at the last possible moment.

→ Malicious JavaScript is often heavily obfuscated (deeply and cunningly disguised) so that while it is in transit across the internet, it looks like shredded cabbage. When loaded into, and executed by, your browser, it unscrambles itself to produce or download more malevolent content. This often includes additional scripts, which may themselves be heavily obfuscated, and so on.

But no-one is reporting JavaScript as a vulnerability to the browser makers.

Sure, some of us like and use tools like NoScript that heavily regulate the execution of JavaScript while we browse, but we’re not seriously suggesting that JavaScript be banned outright from all web pages.

Imagine if you banned JavaScript. No Facebook! No Outlook.com! No interactive doodles on Google! No YouTube!

Therefore, the naysayers are confronting Spagnuolo with remarks along the lines of, “Sensationalist claptrap. This is not a vulnerability. This is Web 2.0. Nothing to see here. Move on.”

The fact is, however, that few, if any, modern email clients, execute JavaScript in email, at least not by default.

Even webmail sites, which rely utterly on JavaScript in their own web pages, suppress JavaScript inside the emails they display for you.

And, do you know what?

Spagnuolo is right, and so is that almost-unanimous majority of email software: JavaScript in email shoudn’t be executed, and that’s that.

So now the question is, “Why?”

Why should we consider JavaScript unexceptional in web pages, but dangerous in the body of an email?

I was interested to know what various experts and educators thought, so I set about looking and asking around.

Here’s colleague and fellow Naked Security writer Mark Stockley on the issue:

I think context is everything. Email is reading something on your computer whereas using the web is more like reading something on somebody else’s computer. They’re functionally no different but I think the underlying mental models are very different. The difference between the mental model and reality is a gap into which security problems can sprout.

Stephen Chapman, advisor and educator, writing on About.com:

With web pages it is the person browsing the web who decides which web pages that they visit… With emails it is the sender who has the most control over what emails are sent and the recipient has less control. Because emails that we don’t want can get through our spam filter we want the emails that we do see to be made as harmless as we can.

And an anonymous commenter on Quora.com, replying to someone who had asked that very same “Why?”:

I think it’s simply that people don’t want more interactive emails. Most person-to-person email is text-based: other than maybe some HTML formatting, people send email to each other via written paragraphs, maybe with a picture attachment or two… Since email is pushed onto the user, it makes sense that the content being pushed is as unintrusive as possible.

There are other important reasons, too.

Perhaps the most significant is what browsers call the same origin policy.

This basically says that scripts are limited to reading data from, and sending data to, the same source as the page they’re running in.

By this restriction, for example, scripts on your favourite social networking site can’t see or use the session cookies set by your webmail client; data uploaded via a page on a technical support site can’t inadvertently be sent somewhere else; and so forth.

But how would you decide the “same origin” for an email you’d received?

How would you usefully limit the behaviour of JavaScript inside an email body, short of limiting it completely by not executing it at all?

For webmail, the same origin policy is even trickier: if you allowed JavaScript in email, cybercriminals would be able to inherit the origin of your webmail domain in scripts they sent in from anywhere, which would be a security disaster.

Dropbox, to whom the Mailbox.app belongs, seems to agree, albeit with some reservations: this morning, the company announced that it would strip out JavaScript before delivering emails to mobile devices.

[T]oday we implemented a process that strips javascript from messages before delivering them to mobile devices.

That’s one security measure, of course, but it’s nowhere near as good as adapting your app so it refuses to execute JavaScript altogether, just in case some JavaScript does get through your scrubbing filters.

→ This reasoning, defence in depth, is why running an email spam filter to strip malicious attachments isn’t a substitute for endpoint anti-virus, but a complement to it. To be fair: Dropbox may be planning a two-pronged fix, but updating an app on the App Store is not an instantaneous process.

Sadly, when Spagnuolo went to validate Dropbox’s claims, he found that although JavaScript is supposed to be scrubbed, the filters could easily be bypassed.

And, since the Mailbox app still runs JavaScript if it doesn’t get filtered out, we’re back to Step One.

By the way, my opinion is that I don’t want JavaScript to run at all in my email client, so I agree with Mr Spagnuolo.

What do you think? Is this a vulnerability of sorts? Or a fuss about nothing?

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/4JsMH05tMKM/