Code-execution vulnerability could open users to a series of serious attacks.

An e-mail app recently acquired by Dropbox contains a security bug that opens iPhone and iPad users to a series of potentially serious attacks, a security researcher warned.

In a blog post published Wednesday, Michele Spagnuolo of Italy said that Mailbox for iOS will execute any JavaScript code embedded in the body of an HTML-formatted e-mail. A video shows how the bug can be exploited to open iOS apps without user prompting, simply by viewing a booby-trapped message. His post said the damage could be much more severe.

"This is bad for security and privacy, because it allows advanced spam techniques, tracking of user actions, hijacking the user by just opening an e-mail, and, using an [exploitation] framework, potentially much worse things," Spagnuolo wrote. In the past, the researcher has been credited with finding security vulnerabilities in Google, eBay and Nokia products or services.

About 90 minutes after this post was published, Mailboxapp.com representatives, acknowledged the bug but downplayed the severity of attacks that might exploit it. A spokeswoman said a patch would most likely be available before the end of Wednesday.

"As others have noted, the risks here are extremely limited thanks to the inter-app security built into iOS," representatives wrote in a statement. "That being said, we're working on an improvement to mail formatting that will mitigate the issue entirely and aim to ship it soon."

Neither the representatives nor Spagnuolo said which versions of the app are affected. Apple's App Store doesn't indicate how many times users have downloaded the app, which has been reviewed by more than 40,000 people. Out of an abundance of caution, Mailbox users should switch to another e-mail app until a patch is released.

Promoted Comments

Did I miss something? What attack vector does this app present that every third party web browser and any app that makes use of a webview doesn't posess?

Dan, can we get some clarification here? Seems negligent to omit these details as a security reporter.

Javascript in email isn't typically allowed to run. Otherwise, an email you read in Gmail could "own" the webpage it is embedded in (Gmail itself). The same is true (though not as damning) on desktop clients such as Outlook, as well as mobile apps. Maybe you couldn't use Javascript to take over Outlook, but javascript is still disabled. Not so with Mailbox. Maybe it's not a serious threat, but email is still not supposed to have javascript.

First of all I would like to thank Dan for the article, and the Ars community for such a great reaction. I really like this kind of informed and civilized discussions, and am considering to join the community for the near future.

In my original report, now updated, I didn't mean to sound "sensational" at all, and I personally do not think this article is "sensational" either.

I just highlighted that Mailbox.app blindly executes Javascript in HTML email bodies, and that this is bad, especially for jailbroken devices. I am perfectly aware of the fact vanilla iOS sandboxes applications, and that this limits the impact, but this should not excuse the design choice, which is poor from both a privacy and security point of view.

Mailbox.app has gained a considerable user base, and it was not acceptable that it used to load external images without asking the user for permission and, worse, execute Javascript code, which allows even more information leakage.

For unjailbroken devices, the sandboxing model, as everything where it comes to security, is not perfect. There is a history of sandbox bypass exploits. It is very likely that a vulnerability that allows malicious attackers to inject actual code using a Javascript vector inside an app to start the attack exists in current iOS versions and will be published in the future. After all, this has happened in the past. I am thinking of Pwn2Own 2010, where Vincenzo Iozzo and Weinmann exploited a vulnerability in MobileSafari to silently transmit the SMS database to a remote server, or the JailbreakMe "Saffron" exploit, that exploited a FreeType parsing vulnerability in the browser to read/write memory past buffer, bypass all restrictions in place in iOS and ultimately jailbreak the phone. In general, Javascript is used as a convenient tool for heap spraying attacks targeting the browser - I am not an iOS expert (my field is web application security), but I can't see why it should be allowed in a such untrusted channel as email.

Some commenters say that this is not different from a normal webview or Safari itself.In my opinion, it is different because while users expect to execute Javascript on a webpage, they do not expect Javascript to be executed by simply opening emails, and emails can be spoofed. I'm also not aware of any other major mail app that runs sender-supplied JavaScript included in the body of emails.

Mailbox.app now claims to filter JS server-side before delivering mails to the client.While I verified that they now strip some Javascript and no longer load external images, I quickly found a way to bypass it, and Javascript is currently still executed without any user interaction. I will not publicly disclose details - I privately reported details to Mailbox.app and am currently waiting for a reply.

This is where your blog post crosses the line (in my view) from legitimate concern into sensationalism. Any such flaw is a security issue with iOS, not Mailbox. There is nothing special about Mailbox that makes it any more susceptible to such a bug than any other app which runs arbitrary JavaScript. However, I accept that, being an e-mail client, it allows for more targeted exploits.

Quote:

Running any untrusted code that may be supplied by the attacker opens yourself up to the potential for such an outcome. Web pages are a similarly untrusted channel, as are text messages, bluetooth comms, etc. I don't believe that one particular vector should be locked down more than any other based on the view that a zero-day bug may exist.

I see what you mean, and it makes sense.In my opinion, email is a particularly untrustworthy channel and should be particularly untrusted when it comes to security design.

I think it boils down to a matter of personal opinion, that's mine (and, as John Lennon used to say, I'm not the only one...).

EDIT: Let's say I prefer to think this way - why should Javascript be allowed in emails? and not why it should be stripped out?.

Quote:

Of course, I agree that it is sensible to disable javascript in e-mails.

The sub-header is a paraphrase of what the original source (a respected and acknowledged security researcher) said

…yet you spelled his name wrong initially =P

It certainly is not necessary for mail apps to run javascript and a bit of an oversight by the Mailbox devs to allow it. The push model of email does allow for targeted JS execution, which may enhance a vector for social engineering attacks, but I'm not sure I would consider it a serious security vulnerability in itself.

Examples of other apps that execute untrusted JavaScript? Any app that includes a webview and allows users to browse links with a domain not controlled by the app developer. Facebook, Twitter, Google Chrome, they all do this.

Other than the fact that it's JS running in a place where the user might not expect it, I don't see how this bug is any more dangerous than browsing the web.

P.S. Just noticed that other sites ran similar bylines, so I'll revoke my use of "sensational" as well . It would have been nice to have seen the original posting of the article more rapidly establish the innocuous nature of this, which could have been inferred based on the attack vector.

I downloaded the app. Out of an abundance of caution I will delete the app, cancel my google accounts, cut ties with all humanity, and depart for places and parts as-yet undecided where there will be no internet access of any kind.

Or... I guess, just not use the app. Which I actually never have, as the whole "you're on a waiting list of 7 billion people, and you're in last place" irritated me as it seemed hype-driven and pushed artificial scarcity on a commodity I'm indifferent to. Seemed kind of demeaning to people in general and like a patronizing insult to those that like that sort of thing.

Which I actually never have, as the whole "you're on a waiting list of 7 billion people, and you're in last place" irritated me as it seemed hype-driven and pushed artificial scarcity on a commodity I'm indifferent to. Seemed kind of demeaning to people in general and like a patronizing insult to those that like that sort of thing.

You'd rather they just give you a box to put in your email address and then you wait indefinitely for an invite? At least they tried to make it so you had an idea when you'd get in. It's not artificial scarcity when they were trying to scale their service reliably instead of all-at-once.

I downloaded the app. Out of an abundance of caution I will delete the app, cancel my google accounts, cut ties with all humanity, and depart for places and parts as-yet undecided where there will be no internet access of any kind.

Or... I guess, just not use the app. Which I actually never have, as the whole "you're on a waiting list of 7 billion people, and you're in last place" irritated me as it seemed hype-driven and pushed artificial scarcity on a commodity I'm indifferent to. Seemed kind of demeaning to people in general and like a patronizing insult to those that like that sort of thing.

The waiting list when it first launched made it a staggered roll out, so make sure they had the necessary infrastructure in place, and offered them the ability to ramp up gracefully. Was there hype around the launch? Sure. Was there a practical reason for it? Absolutely.

I feel like I'm missing the key vulnerability that this 'bug' exploits.

An iOS app runs some javascript. With the limited-privilege javascript engine that all 3rd-party apps have to use. In a sandbox. All the javascript is doing is using app-specific URI schemes to launch other apps via supported means. None of the launched apps actually do anything without user confirmation.

Is there anything more to this 'serious bug'?

What exactly could the javascript do that is more malicious than stuff which is supported by iOS and is also doable by any other javascript-running app? Is it the automatic running of potentially-hidden javascript that is the problem? How does this differ from a 3rd-party web browser?

This app should be pulled from the App Store immediately. And really, it should never be allowed back even if they fix this. Apps should not be allowed to act as intermediaries between users and their email providers like this. It is a terrible precedent for user security and Apple shouldn't be allowing it.

This is no different then the default mail application.

The emails are not downloaded by the service, at the basic level, it just filters emails by Gmail labels. There are some more advance features that might require server code ( i.e. the ability to remind you of an email ) but you can do that any number of ways safetly.

Doesn't Mailbox just use WebView just like every other app that displays web pages in iOS? Did he demonstrate this bug NOT happening in Gmail and Apple's own Mail app and other apps that use WebView? I'm unimpressed.

This app should be pulled from the App Store immediately. And really, it should never be allowed back even if they fix this. Apps should not be allowed to act as intermediaries between users and their email providers like this. It is a terrible precedent for user security and Apple shouldn't be allowing it.

This is no different then the default mail application.

No. The Apple mail app does not send your email credentials to a third party. This app does.

If, for the sake of a free mail account, you trust your email to a 3rd party like Google, whose primary revenue model is the acquisition, analysis and subsequent sale of user data, and *then* proceed to deliberately route all that email through yet another third party app because it is free...

... how much can you possibly value your privacy in the first place?

Think about that, just for a split-second, before going all Pavlovian on that downward pointing arrow.

I feel like I'm missing the key vulnerability that this 'bug' exploits.

An iOS app runs some javascript. With the limited-privilege javascript engine that all 3rd-party apps have to use. In a sandbox. All the javascript is doing is using app-specific URI schemes to launch other apps via supported means. None of the launched apps actually do anything without user confirmation.

Is there anything more to this 'serious bug'?

What exactly could the javascript do that is more malicious than stuff which is supported by iOS and is also doable by any other javascript-running app? Is it the automatic running of potentially-hidden javascript that is the problem? How does this differ from a 3rd-party web browser?

Doesn't Mailbox just use WebView just like every other app that displays web pages in iOS? Did he demonstrate this bug NOT happening in Gmail and Apple's own Mail app and other apps that use WebView? I'm unimpressed.

This app should be pulled from the App Store immediately. And really, it should never be allowed back even if they fix this. Apps should not be allowed to act as intermediaries between users and their email providers like this. It is a terrible precedent for user security and Apple shouldn't be allowing it.

This is no different then the default mail application.

No. The Apple mail app does not send your email credentials to a third party. This app does.

Mailbox uses Google's Authentication and Authorization API to get access to your mail. Your credentials are never revealed to Mailbox at all (although their servers do at this point have full access to your gmail account). It's still an attack vector if their system isn't secure, but that's true of the myriad of apps that request access to your email, Dropbox, Facebook, etc.

This app should be pulled from the App Store immediately. And really, it should never be allowed back even if they fix this. Apps should not be allowed to act as intermediaries between users and their email providers like this. It is a terrible precedent for user security and Apple shouldn't be allowing it.

This is no different then the default mail application.

No. The Apple mail app does not send your email credentials to a third party. This app does.

Mailbox uses Google's Authentication and Authorization API to get access to your mail. Your credentials are never revealed to Mailbox at all (although their servers do at this point have full access to your gmail account). It's still an attack vector if their system isn't secure, but that's true of the myriad of apps that request access to your email, Dropbox, Facebook, etc.

That they are not the only service provider to do this isn't an excuse.

The emails are not downloaded by the service, at the basic level, it just filters emails by Gmail labels. There are some more advance features that might require server code ( i.e. the ability to remind you of an email ) but you can do that any number of ways safetly.

I'm sorry, but the emails are downloaded server-side. The app never talks to Gmail servers directly, actually. It uses a proprietary protocol to talk with Mailbox servers that supposedly sends much of the payload over Apple push notifications directly. No third-party IMAP client can offer push email on iOS without accessing your email server side, it just can't be done.

Did I miss something? What attack vector does this app present that every third party web browser and any app that makes use of a webview doesn't posess?

Dan, can we get some clarification here? Seems negligent to omit these details as a security reporter.

Javascript in email isn't typically allowed to run. Otherwise, an email you read in Gmail could "own" the webpage it is embedded in (Gmail itself). The same is true (though not as damning) on desktop clients such as Outlook, as well as mobile apps. Maybe you couldn't use Javascript to take over Outlook, but javascript is still disabled. Not so with Mailbox. Maybe it's not a serious threat, but email is still not supposed to have javascript.

Readers are reminded that "On the radar" stories appearing in the middle of the Ars home page are briefs, not in-depth articles. I made it clear that officials with mailboxapp.com and Dropbox didn't respond to my questions and promptly updated the article when additional details were available. If the information isn't available, it's not available.

I know it's frustrating when key details are missing from an article, but sometimes that's unavoidable when reporting news in real time. What I find frustrating are readers who call reporting negligent just because some key details aren't immediately available.

- I did not notice that this was "on the radar." I still use the old site column layout, so I can't easily differentiate. Sorry for that.

- In this specific case, readers were pointing out the lack of differences between an app that uses webviews and Mailbox, not two different email applications. Javascript running in a webview on iOS (even if in a mail application) does not equate to a "code-execution vulnerability." Arbitrary JS code execution is a feature, not a bug.

- The negligence I was referring to was reporting that "code-execution vulnerability could open users to a series of serious attacks" in the sub-header without vetting that this was actually the case. The video does not demonstrate any non-js arbitrary code execution or use of "more serious exploitation frameworks." As it stands, this is much more of a usability bug than a security bug, which seems inappropriate to publish on ars. Security reporters should be able to sift through overhyped bugs such as this, and report when necessary.

- Given this, Mailbox's response seems appropriate, but "out of an abundance of caution, Mailbox users should switch to another e-mail app until a patch is released" certainly seems like an over-abundance of caution.

So, if the JavaScript executed had any way of contacting a remove server, even via something like loading an image, JavaScript could be crafted to determine if a particular user had installed a specific app. Simply load up a specific image, and then attempting to load an app. If the attempt to load the specially crafted URL fails to load the app, the JavaScript should continue to run, attempting the next app. The would know by omission what app was installed.

This is pure speculation on my part, but judging by the information I've read, it's viable.

Kruzes put it best in one of the comments above. Mail applications aren't supposed to execute JavaScript embedded in email sent by arbitrary users. It helps that iOS apps run in a sandbox, but that doesn't mean what Mailbox was doing was safe. Executing JavaScript included in the body of an email is different than a browser, mail client or other app executing JavaScript that is downloaded from a known source. The speculation from jasonlotito above is right on the mark. Mailbox has acknowledged the potential threat by turning around a patch in such a short period of time.

My request from readers: If you have questions, feel free to ask. If something isn't clear, please say. If you think it's overkill for me to suggest users hold off for a few hours using an app until all the facts are known, please speak up. I'm just asking that people think twice before using loaded words like negligence when a question or difference arises.

Fair enough, I'll retract my use of "negligence" for what it's worth. Its use might have been a bit unwarranted.

I still think the sub-header is somewhat sensational though. I read this assuming that assembly code was being injected.

Last point - plenty of apps run untrusted JavaScript from unknown sources, this isn't entirely a special case for javascript execution.

I appreciate your comments. Thanks for being flexible and meeting me half way. A quibble: The sub-header is a paraphrase of what the original source (a respected and acknowledged security researcher) said. I think "sensational" is another loaded word. If you think what the researcher said is an exaggeration, please just say that.

I'm not aware of another mail app that runs sender-supplied JavaScript included in the body of HTML-formatted email. This is most definitely a taboo among security professionals. Is this what you're talking about? Can you be more specific about the apps that execute untrusted JavaScript from unknown sources?

The sub-header is a paraphrase of what the original source (a respected and acknowledged security researcher) said

…yet you spelled his name wrong initially =P

It certainly is not necessary for mail apps to run javascript and a bit of an oversight by the Mailbox devs to allow it. The push model of email does allow for targeted JS execution, which may enhance a vector for social engineering attacks, but I'm not sure I would consider it a serious security vulnerability in itself.

Examples of other apps that execute untrusted JavaScript? Any app that includes a webview and allows users to browse links with a domain not controlled by the app developer. Facebook, Twitter, Google Chrome, they all do this.

Other than the fact that it's JS running in a place where the user might not expect it, I don't see how this bug is any more dangerous than browsing the web.

P.S. Just noticed that other sites ran similar bylines, so I'll revoke my use of "sensational" as well . It would have been nice to have seen the original posting of the article more rapidly establish the innocuous nature of this, which could have been inferred based on the attack vector.

First of all I would like to thank Dan for the article, and the Ars community for such a great reaction. I really like this kind of informed and civilized discussions, and am considering to join the community for the near future.

In my original report, now updated, I didn't mean to sound "sensational" at all, and I personally do not think this article is "sensational" either.

I just highlighted that Mailbox.app blindly executes Javascript in HTML email bodies, and that this is bad, especially for jailbroken devices. I am perfectly aware of the fact vanilla iOS sandboxes applications, and that this limits the impact, but this should not excuse the design choice, which is poor from both a privacy and security point of view.

Mailbox.app has gained a considerable user base, and it was not acceptable that it used to load external images without asking the user for permission and, worse, execute Javascript code, which allows even more information leakage.

For unjailbroken devices, the sandboxing model, as everything where it comes to security, is not perfect. There is a history of sandbox bypass exploits. It is very likely that a vulnerability that allows malicious attackers to inject actual code using a Javascript vector inside an app to start the attack exists in current iOS versions and will be published in the future. After all, this has happened in the past. I am thinking of Pwn2Own 2010, where Vincenzo Iozzo and Weinmann exploited a vulnerability in MobileSafari to silently transmit the SMS database to a remote server, or the JailbreakMe "Saffron" exploit, that exploited a FreeType parsing vulnerability in the browser to read/write memory past buffer, bypass all restrictions in place in iOS and ultimately jailbreak the phone. In general, Javascript is used as a convenient tool for heap spraying attacks targeting the browser - I am not an iOS expert (my field is web application security), but I can't see why it should be allowed in a such untrusted channel as email.

Some commenters say that this is not different from a normal webview or Safari itself.In my opinion, it is different because while users expect to execute Javascript on a webpage, they do not expect Javascript to be executed by simply opening emails, and emails can be spoofed. I'm also not aware of any other major mail app that runs sender-supplied JavaScript included in the body of emails.

Mailbox.app now claims to filter JS server-side before delivering mails to the client.While I verified that they now strip some Javascript and no longer load external images, I quickly found a way to bypass it, and Javascript is currently still executed without any user interaction. I will not publicly disclose details - I privately reported details to Mailbox.app and am currently waiting for a reply.

It is very likely that a vulnerability that allows malicious attackers to inject actual code using a Javascript vector inside an app to start the attack exists in current iOS versions and will be published in the future.

This is where your blog post crosses the line (in my view) from legitimate concern into sensationalism. Any such flaw is a security issue with iOS, not Mailbox. There is nothing special about Mailbox that makes it any more susceptible to such a bug than any other app which runs arbitrary JavaScript. However, I accept that, being an e-mail client, it allows for more targeted exploits.

EDIT: The above quote is taken from your preceding comment, not your actual blog post. The equivalent bit from the blog post is "and potentially much worse things".

After all, this has happened in the past. I am thinking of Pwn2Own 2010, where Vincenzo Iozzo and Weinmann exploited a vulnerability in MobileSafari to silently transmit the SMS database to a remote server, or the JailbreakMe "Saffron" exploit, that exploited a FreeType parsing vulnerability in the browser to read/write memory past buffer, bypass all restrictions in place in iOS and ultimately jailbreak the phone. In general, Javascript is used as a convenient tool for heap spraying attacks targeting the browser - I am not an iOS expert (my field is web application security), but I can't see why it should be allowed in a such untrusted channel as email.

Running any untrusted code that may be supplied by the attacker opens yourself up to the potential for such an outcome. Web pages are a similarly untrusted channel, as are text messages, bluetooth comms, etc. I don't believe that one particular vector should be locked down more than any other based on the view that a zero-day bug may exist.

Some commenters say that this is not different from a normal webview or Safari itself.In my opinion, it is different because while users expect to execute Javascript on a webpage, they do not expect Javascript to be executed by simply opening emails, and emails can be spoofed.

I expect any untrusted code to be properly sandboxed by the operating system, regardless of where it has come from, or which app is executing it. I don't expect special consideration to be required for e-mails. Yes, I expect JavaScript on web pages, but I don't expect that JavaScript to always be harmless. This is no different for javascript I may receive in e-mails.

Of course, I agree that it is sensible to disable javascript in e-mails. It's just that I don't see why the protections that are in place for all other JavaScript-running apps should somehow be deemed insufficient for an e-mail client.