There’s an article in the National Journal yesterday that caught my eye. It covers a new report on mobile botnets, and who your smartphone is potentially at risk:

You’ve heard of the “botnet”—a collection of enslaved, malware-infested computers that act together to pump out spam and DDoS attacks, often unbeknownst to their owners. For the past decade, botnets have mostly been a problem for the PC world. But, according to a new report on mobile malware, it may not be long before we start seeing botnets built out of an increasingly sophisticated type of device: cell phones. “It’s only a matter of time before that’s pervasive,” said Karim Toubba, a vice president at Juniper Networks, the publisher of the study.

Whoever wrote the article is rather uninformed; computer security companies have been documenting mobile botnets for years (Google). In fact, back in January Symantec blogged about a mobile botnet that they thought was the largest in China:

In February 2012, we blogged about Android.Bmaster (a.k.a. Rootstrap), which infected hundreds of thousands of devices. At that time, it was the largest mobile botnet documented to date. Recently, the Bmaster botnet has been overtaken by the newly uncovered MDK botnet. Dubbed as Android.Troj.mdk, Kingsoft believes it is hidden in more than 7,000 apps and has infected up to one million devices.

FYI: Botnets are built by malware finding and exploiting security holes on devices. You might visit an unsafe website, install an app that was corrupted, etc, and then the malware you downloaded will go to work corrupting your device.

So what’s the ebook angle?

One of the security holes that malware developers try to exploit is JavaScript, which happens to be supported in Epub3. Right now it is unlikely that you will encounter an Epub3 ebook that you need to worry about, but that could change in the future.

I myself have only recently woken up to the fact that the Epub3 spec includes a massive security hole, and as part of my efforts to raise awareness of this issue I asked Baldur Bjarnason to spin out a plausible scenario in which your smartphone could be hacked:

S works as an assistant in a large office in Oxford. With rental prices in Oxford being has high as they are, S has to commute in on the train every day. Living in Oxford proper is just too expensive on that salary, especially if you’re trying to save up some money. To ease the boredom of the commute S reads ebooks. Since S is a voracious reader on a tight budget S only buys the books he already likes, after downloading from the web and reading them. So S is a regular visitor to an ebook pirating site. S justifies this to himself by saying that his book buying budget is higher than most other’s with his salary, even with the pirating and all, so he reads on the train with an easy conscience. X is the owner of said site, which proudly boasts that it has the complete NYTimes Best Seller list available. The site now has tens of thousands of regular readers who download ebooks from it. Every one of those ebooks has a javascript packet that connects home to a control server. That control server can send arbitrary javascript to all devices connected to it whenever it needs to and the ebooks store the code using local storage. X makes his money by leasing his network out in lots of 100 compromised devices at a time. Even though his ‘user base’ is relatively small in malware terms, they spend a lot of time with the ebooks open (they need to read them, remember), certainly more time than most users spend in compromised mobile phone apps on average. These are high value assets. X’s customers rent these ebook botnets to commit cybercrimes ranging from Denial of Service attacks, to compromising one of the hundreds of thousands of unsafe out of date WordPress installs that have been plaguing the internet for almost a decade. There are a lot of uses for a network of javascript virtual machines.

Given what I quoted from the Symantec blog post this scenario is not only plausible, it also has a high probability of coming true.

Should Epub3 ever become widely adopted, we’re going to read stories about security researchers finding security holes in reading apps. If we’re really unlucky we’re going to read stories about security researchers finding malware that exploits the security holes.

It’s going to be messy, it’s going to be public, and it’s going to be professionally embarrassing to everyone who thought adding Javascript to Epub3 was a good idea.

Fortunately it is also, to a limited degree, preventable.

The best way to prevent this impending disaster would be to not add JavaScript to the Epub3 spec, but that pooch has already been screwed. So all we have left are changing developer behavior and changing user behavior.

Good luck with that. As you can see from the current state of the computer security industry, at best that will minimize the problem, not eliminate it.

The best option, IMO, is to add Epub3 to your personal avoidance list. I don’t visit unsafe website; I try to avoid unsafe downloads, and from here on out I plan to be cautious about installing Epub3 reading apps and downloading Epub3 ebooks.

P.S. Luckily for me there’s not much of a reason to adopt the format. Virtually all of the ebooks I read can be displayed using Epub 2.x, which might explain why Epub3 adoption is lagging so.

In fact, the developers of Calibre (best free ebook conversion software) and Sigil (best free Epub creation software) see no reason to add support for the format. John Schember, the developer of Sigil, has told me that “As of right now EPUB 3 is not a priority.” Kovid Goyal, the developer of Calibre, was more eloquent about the topic:

And currently, epub 3 has no compelling feature that does not work if you are willing to generate non-standards compliant epub 2, which by the way the O’Reilly backwards compliant epub 3 files will be, i.e. non-epub2 standards compliant. O’Reilly wont care since they don’t have to publish their files with various distributors that insist on epubcheck 1.x.

With luck, Epub3 might never be widely adopted. But I would not guarantee that.

P.P.S. I ran this post by Baldur, and he suggested that I add a couple footnotes:

iBooks’ safeguards (i.e. no network, no storage, no fun), in my opinion, very effectively counter most of the security issues with javascript in ebooks. Unfortunately, they also pretty effectively undermine most, if not all, use cases people have proposed for javascript in ebooks.

We still don’t know what the defaults will be for Readium SDK, which in turn will probably decide the defaults for EPUB3 support for a *lot* of future ereading apps. If the SDK disables javascript by default or blocks network and storage by default, then the risk is lessened dramatically.

image by jeffedoe