"Mailbox" app on iPads and iPhones runs JavaScript from emails - vulnerability or feature?

Filed Under: Featured, Malware, Phishing, Security threats

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?

, , , , ,

You might like

7 Responses to "Mailbox" app on iPads and iPhones runs JavaScript from emails - vulnerability or feature?

  1. Tim · 357 days ago

    Running JavaScript in email is unnecessary at best and dangerous (or at least risky) at worst. Transfer the risk to the end user by providing an option in the client settings to enable or disable JavaScript globally. Leave it disabled, by default, of course. Then provide an option to selectively create exceptions to allow it, if needed, in emails from specific senders or domains.

  2. Nigel · 357 days ago

    I absolutely do NOT want JavaScript to run in my email application. Email messages should be passive, incoming-only packages that run no scripts and execute no code. Otherwise the very act of opening a message could unleash all sorts of havoc.

  3. Braden · 357 days ago

    It depends on the domain. On iOS, if you don't specify the domain from which you're loading active content (e.g. using loadHTMLString:baseURL: with a nil baseURL), the content will be loaded from a domain that has access to local files. In short, such javascript could steal arbitrary files from your device and exfiltrate them to remote websites.

    Practically, the data that could be stolen would be limited by the iOS sandbox, but lets face it, when it comes to file-read operations, the iOS sandbox is pretty weak. Plus, this is a mail app, so you can probably exfiltrate the contents of all their mail.

    • Paul Ducklin · 357 days ago

      ...or, presumably, access their email address list and send messages out, which would be more than handy for spammers.

      OTOH, if you do try to specify a domain, which one do you choose?

      The sender's claimed domain? Could be anything and probably is.T

      he domain of one of the sending servers? And if so, which one - first in the list, belonging to a crook, or last in the list, belonging to your company or ISP, or somewhere in between?

  4. zengator · 356 days ago

    As noted by Chapman, the key is that I get to choose which sites I visit, and then--via NoScript--the source of scripts allowed to run. In fact, I sometimes approach it as a game, seeing just how few scripts are needed to access the content I want. (Added bonus: googleadservices, bazaarvoice, and lots of other irritants are thus avoided.)

    Do the geniuses that enabled JavaScript in a mail client not remember [internal Greybeard voice: perhaps they weren't yet born.] when links were sent via email with the visible text being benign while the underlying anchor/link was malicious?

    What's the primary vector for initial intrusions today? That's right: spear-phishing emails.

    Why, oh why, would you want that tool to be more effective?

  5. MikeP_UK · 356 days ago

    Musing over the plan to 'strip' JavaScript from emails being sent to mobile devices made me stop and ponder about messages sent to non-mobile devices that might be just as vulnerable to the problem described.
    For example, Windows 8 and 8.1 are meant to look like the screen of a mobile displaying 'apps' so are they potentially vulnerable to the JavaScript exploit?
    The concern is triggered by the limitation of their action to just 'mobile devices' as the connected world is blurring the distinction between a mobile, a hand-held, a desk based system or anything portable. So what happens if an 'infected' message with a dangerous JavaScript payload gets through to one of these other device types? And what if it is then forwarded to the mobile devices?
    JavaScript appears to have some uses but also some risks, so I don't use Facebook, Twitter, etc largely because they are perceived as being 'dodgy' risks.
    I don't directly use Outlook.com, but use Office Outlook with Connector (there has to be some JavaScript in there somewhere I guess?)

  6. Nothingtoseehere · 356 days ago

    What comes to mind is JavaScript forwarding to a jailbreak enabled download to do something nasty... Think a malicious version of jailbreakme.com on a new jailbreak vuln.

    Not something I would ever like to have happen.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog