An Epub3 eBook Could be Used to Hack Your Tablet, Steal Your Identity, and Cause the Downfall of Western Civilization

Editor's Note: The comments have been disabled on this post due to an overwhelm,ing abundance of spam. Sorry. 3859852351_d65f71267b[1]Here's a story that is a couple weeks old but seems to have gone unreported. If you've been following digital publishing news then you've probably heard about the Publishing Hackathon. This was a contest that was held at the same time as BEA 2013. A total of 30 contestants submitted project ideas which, following the true spirit of a hackathon, were developed over the course of a weekend. I only got a chance to look at that contest and the entries today, and I am surprised that there seems to be no commentary on the fact that one entry truly is a hack.

Eric Hellman showed off an idea that, assuming someone wanted to use it maliciously, could be used as the first step in hacking your tablet, smartphone, or ereader. That is not how Eric used the idea, and that's not at all how he described it, but it is still one possible use.

What Eric showed off was a new way to generate an "about the author" page inside Epub3 ebooks. Rather than create a static page when the ebook is published/updated, this project created the page from scratch by pulling content from external websites and displaying that content inside the ebook. This idea only worked in the Readium Epub3 reading app, and it pulled content from the Open Library and other safe places.

On a technical level this is very cool, but it should also be raising red flags.

Eric's idea involves code being executed inside an ebook which goes to an external website, gets content, and displays it inside your ebook.

Do you see the problem?

This might sound a little paranoid, but how do you know that the external website is safe and that the content it downloaded into your ebook is not doing something nefarious behind the scenes?

You don't know, and that's a problem. For all we know the code inside a given ebook could lead to a site that will try to hack your ereader, tablet, or smartphone.

Update: A reader has pointed out that this security concern is mentioned in the Epub3 spec (here). Good; let's hope developers take it seriously.

Second Update: Baldur Bjarnason has raised this issue a couple times before(EPUB javascript security, Javascript in ebooks). Those posts are well worth a read.

Before you decide that I am completely off my rocker, let me point out that I am not the first person to identify this issue. Apple, for example, supports JavaScript in Epub3 but does not support letting JavaScript inside an ebook call for external websites (according to Eric).

sm-geo-ebook[1]And I also know that Apple wasn't the first to consider the possibility that an ebook might access external websites. Liza Daly of Threepress Consulting (now with Safari Books Online) was blogging about the idea as early as June 2010. Her demo involved a location-aware ebook, so it was not any threat to users, but it stands as proof of what is possible.

Are you scared yet? Good.

I'm deeply concerned that Readium has such an obvious security hole, but I also know that there is a relatively simple way to fix this issue. App developers are going to need to either block external connections or at the very least they will need to make it optional and include popup warning messages.

This reminds me of an old trope about ebooks which is becoming more true as time goes by. eBooks have often been described as web content wrapped into a file, and while that analogy doesn't quite work with the simpler ebook formats when it comes to Epub3 it is almost literally true.

Given the HTML5, CSS3, and JavaScript support in the Epub3 spec. an Epub3 ebook is effectively a website inside a file. While this can be quite useful, it also means that we need to start treating Epub3 ebooks with the same caution that we apply to our web browsing activities.

Readers are going to need to be careful where they download ebooks, and more importantly reading app developers are going to need to start thinking about how their apps can behave like the security firewalls found on most computers.

Reading apps are going to have the first responsibility of controlling malicious ebooks. If nothing else they will get the blame should something bad happen, and that is why I think the developers should start planning for the worst.

image by walknboston

About Nate Hoffelder (11481 Articles)
Nate Hoffelder is the founder and editor of The Digital Reader: "I've been into reading ebooks since forever, but I only got my first ereader in July 2007. Everything quickly spiraled out of control from there. Before I started this blog in January 2010 I covered ebooks, ebook readers, and digital publishing for about 2 years as a part of MobileRead Forums. It's a great community, and being a member is a joy. But I thought I could make something out of how I covered the news for MobileRead, so I started this blog."

38 Comments on An Epub3 eBook Could be Used to Hack Your Tablet, Steal Your Identity, and Cause the Downfall of Western Civilization

  1. I would have thought it obvious that any technology that allows javascript is a security risk. However, I’m a little puzzled about the idea that outbound links are are a concern only for ePub3 or that somehow the text files inside an ePub are not a webpage. Of course they are. I can take any of those files from an ePub, upload them to a webserver and there you go. A webpage. There’s an html/xml declaration, for pity’s sake.

    A eReader is a browser.

    Right now, if I were a bad person, I could create an ePub with outbound links to to a website. And I could make the destination look like a legitimate place to buy more books by yours truly. Only instead, that website could be stealing the payment information.

    Or maybe the destination of my outbound link is totally legitimate only it’s been hacked and is now a man-in-the-middle attack and diverting my sale to a third party, with me and the end user none the wiser.

    Any device with access to the internet is a security risk.

    I, personally, do not know if anyone has tried to gain access to an eReader engine from a malicious site or whether a smartphone or tablet might have a vulnerability that lets a site drop a malicious file onto the device. I would say that is possible, given that there have been apps and even OS files that have been phoning home to app developers.

    What I do think is concerning about ePub3, from a security standpoint, is that javascript can access a file system. A careless app, or a Reader engine that does not prohibit file level access could potentially install malware on that device. If you can root your phone or tablet, then so can malware, which, actually, has been done.

    So, basically, yes, it’s a concern, but by no means a new one.

    • I was under the impression that most current reading apps kick you out to the web browser to download stuff, and that few support JavaScript. With Epub3 the downloading can happen behind the scenes.

      And while I agree that the situation you describe is a concern, you’re still discussing it in terms of the web browser. I’m concerned about things that happen inside the reading app, which is a problem that I have not seen anyone address yet.

      At the very least Readium does not appear to have addressed the security issue. That is worth a post, IMO.

  2. Disabling web access is not enough. The malware can already be bundled inside the book. With enabled Javascript, epub3 books have exactly the same problems that pdf-, flash-, exe-files, etc have. Every bug or not considered weakness in the reading app could be used to attack the system. Just consider the the script to perform some busy loops (or complex computations) that drains the battery or prevents the system to enter sleep mode.

    Disabling web access would at least inhibiting the book on spying on the reader as i.e. Kobo does (tracking which books you are reading, how long you read each page, etc). But if epub3 ever gets a critical mass, it’ll probably not take long when books refuse to show their content unless web access is available (either for tracking, for importing ads, for DRM, whatever).

  3. Oh, Great! I guess I’m going to have to get an anti-virus app for my eReader.

  4. Mr Dead Kindle Format is at it again!.
    Why don’t you check the epub3 spec before spreading McCarythite propaganda?

    • What makes you think that all developers are going to notice the section on scripting, realize the issues, and disable scripting?

      I’m expecting to see a bunch of Q&D apps based on Readium SDK that implement the basic code without very many additions in much the same way that we see webkit based apps now. Those apps present serious security concerns.

      And even of some developers are careful, users are still going to have to rethink their activities. My point about the changes needed in user behavior is still valid.

      • “What makes you think that all developers are going to notice the section on scripting, realize the issues, and disable scripting?” Sorry, are you talking about reader developers? Of course, they will look at every section of the specs. There is absolutely no reader developer in the world who hasn’t thought about security issues and examined that section of the specs.
        Or are you talking about ebook developers? The ones who deliberately might want to make a trojan ebook. That is the wrong target. As the book “EPUB 3 Best Practices” notes: “True security is implemented at the level of the reading system or device, not the EPUB 3 specification”.
        And, yes, if I was a reader developer I simply wouldn’t offer scripting support. Then I’d never have to deal with the security issues.

        • “And, yes, if I was a reader developer I simply wouldn’t offer scripting support. Then I’d never have to deal with the security issues.”

          That’s a good idea, but I am afraid that we’ll see at least some app developers simply use the SDK unchanged. I have seen far too many Epub reading apps which poorly implement the Epub 2 spec to be confident that Epub3 reading apps will be secure.

          • You’re being conservative.
            I expect *most* developers will ship the unmodified Adobe reader in their rush to get “standard” epub3 support as a checklist item on the specsheet.
            Me, I’m not touching any epub3 reading app or device for at least a year after intro. I may never touch an epub3 app on a multifunction device.
            Version 1.0 of any new platform is always a risk but v1.0 or epub3 is a ticking timebomb; somebody *will* get burned.
            It won’t be me.

  5. OK, let’s all panic right now!!! Hey, maybe the NSA is behind this!!! Except, uhh, no e-reader supports this (and probably will not). Second, assuming some e-reader (Readium doesn’t count) DID support going out and getting stuff off the net, that’s no different from how the web works anyway. What WOULD get me worried is if someone figured out how to hack around the limitations all e-readers impose on external net connections. Let me know when that happens.

    • William Ockham // 10 June, 2013 at 7:21 am //


      The Readium SDK does count. It will become the basis of Kobo’s and Bluefire’s Epub3 renderer. The problem is the spec. It is truly awful. Stories don’t need Javascript. The books that need app-like functionality need a separate spec that deals with security in a responsible way.

      We don’t need to panic, but storytellers should be concerned. There is real potential for market harm from the stupid actions of the IPDF.

      • That is so wrong it’s beyond belief.

        • William Ockham // 10 June, 2013 at 8:09 am //

          Oh, really? Malicious code masquerading as content is a favorite technique for the bad guys. How many PDF exploits have there been? Office documents? Flash? Why create another exploitable format? Why increase the complexity of producing ebooks for something that is unneeded by the vast majority of commercial books?

          If you don’t see the potential for exploits, you are blind. If you don’t think a few well-publicized exploits would hurt the ebook market, you are a fool. Epub3 should be considered harmful in its current state.

      • The Readium SDK is just that, an SDK. E-reading device manufacturers are free to do whatever they want with it, and most if not all will disable external net access. Some may make a strategic decision to allow it. In that case, assuming books are produced for that one e-reading device that take advantage of that capability, then it is a competitive market situation where some readers may choose to make that security/functionality trade-off.

        Regarding other comments on this post, I think it’s highly important to distinguish between scriptability and net access. Scriptability is required for net access, but it does not necessarily imply it. We can have scriptability without net access, and that brings a host of advantages in terms of functionality in books.

        • eReading devices are free to do whatever they want with te SDK and generic reader, yes.
          And historically, they have done very little.
          How many reading devices still display the annoying “page number” on the side of the screen?
          Most low-end generic reading devices just port the generic mobile ADE and move on to the embedded ebookstore. And there is no reason to expect any better on the generic epub3 readers if and when they get to market.
          And those are relatively safe implementations; being dedicated devices all the hackers might get is your account data. A nice start at identity theft but nothing compared to the windfall the might get out of hacking a phone or tablet.

    • If it’s in the final Readium release, it *will* be deployed.
      Take it to Vegas. 🙂

      It is up to the Readium consortium to either strip it out or padlock it and default to off.
      I’d rather the former but expect neither.
      The BPHs *want* this.

  6. Nate, did you really only just realize that support for JavaScript might have security implications? You’re definitely late on this one! Here is a note from Feb 21 2011 that begins with the great line “I have found a way to include a trojan in an EPUB 3 document.”
    And as a reader pointed out, the EPUB 3 specs themselves are very aware of the security issues. The vulnerability is entirely due to support for scripting provided by the reader software. If I was a reader developer, I’d simply drop support. End of problem.

    • I was aware of the security issues in code in PDF and other docs, and I was aware of the need for browser security. But what I didn’t know was that these security issues were deliberately being introduced into Epub3. Silly me, I assumed that the spec team wouldn’t go out and create yet another exploitable format.

  7. Last year there was an article on how javascript in epub3 files can be used by publishers to gather info on readers and “phone home” to report.
    It produced a bit of discussion over at Mobilereads:

    The inclusion of javascript in epub3 and the possibilities it offers is not an accident but an intended feature of the system. The creators of the spec put them in to be used and used *their* way. So spyware ebooks are going to happen. And malware ebooks *will* happen, just as pdf maware has happened. (Nate had an article hereabouts a couple years back detailing the pdf files are programs that can use exploits in the “security” of Acrobat and other reading apps to hack the underlying platform. epub3 shares most of the design philosophy of pdf and thus shares the exact same abilities.)

    As for Readium it is the official reference design and code base for ADEPT-based commercial ebook readers. Pretty much every ADEPT-capable reading app and device that currently relies on mobile ADE for commercial epubs is likely to be updated/replaced with Readium-derived apps. And as happens today, many of those ADEPT epub3 readers will be only minimally tweaked from the generic Adobe implementation and will not be getting much in the way of updates and bug fixes in the cheaper Chinese generic readers.

    In other words, epub3-borne spyware and malware will be primarily an issue for users/supporters of the generic interoperable epub3 ecosystem. Users of the epub3 subsets and forks like KF8 and iBook will be at lower risk since it is very likely that, as pointed out in the digitalbookworld article above, have a vested interest in keeping their epub3 derivatives clean and safe. So, no, users will likely not need to worry overmuch about ebook malware… as long as they are customers of the big walled gardens. 🙂

    With Kindle I think it is a safe bet that Amazon will make try to make sure any such code in epub3 files used as feedstock for their KF8/KF9/KFX readers is stripped away and that the reading apps do not allow ebooks to phone home or execute arbitrary code. Malware writers and publishers will of course look for holes in the readers’ security but the front line of this war will be at Amazon/Apple more than at the reading device. End users will actually have more to worry about in the DRM-free ebooks they sideload, both with Kindle and iBooks. Fans of interoperable epub3 will be at the mercy of Adobe and its licensees neither of which has a terribly good track record of prompt and effective updates and bug fixes, much less security.

    Bottom line: as long as Javascript is a feature of epub3, users will be marginally safer in the grip of the evil empires. 😀

    Caveat emptor, now more than ever.

    • Just a short note about malware PDFs. There have been several whitepapers circulating privately in the anti-malware industry outlining how the very design of Adobe’s PDF browser plugin makes securing it impossible. The technical details went way over my head at the time (read it over two years ago and haven’t got a copy on hand) but the gist of it was that the interaction between three different programming language virtual engines (flash, built-in PDF javascript, and browser javascript) meant that it was theoretically impossible to secure the behaviour of those programming languages embedded in a PDF or in a webpage hosting a PDF.

      Unfortunately, unlike many theories, this one had several practical real-world examples even when the paper was first written.

      So, the situation with PDFs is much worse than in EPUB3. PDFs should never have been allowed to embed flash or javascript and the plugin should never have been made scriptable.

  8. Lemme see… I first wrote about this issue three years ago in a comment at the Threepress blog, albeit from a pretty high level. (

    This was ignored at the time by everybody but Liza.

    Then I wrote about it in detail on my own blog a year ago ( when it was completely and utterly ignored by ereader developers, Readium devs and the IDPF and I know that people from all those groups have read the piece.

    The short version of this is that Apple has put limitations (i.e. no network access, no storage beyond cookies) on javascript in epub in iBooks for a very good reason.

    Unfettered javascript in ebooks has major privacy and security implications. I went over only a fraction of the possible damage they can do in my post.

    Unfettered javascript in epub is a security hazard that Apple can only lock down by either whitelisting the books you are allowed to read (which would have massive free speech implications and is essentially what they do with apps on the app store) or by limiting the APIs available to javascript in ebooks.

    And, yes, letting javascript run rampant in an ereader is a lot riskier than a regular website for several reasons:

    * Ebooks are not bound to a url and can be distributed peer to peer. I.e. there isn’t the possibility of using the domain to distinguish a safe book from an unsafe one like you can with web apps (e.g. and versus phishing sites).
    * Ebooks are open, on average, a lot longer than a website, giving malware much more time and resources to stage an attack.
    * Malware ebooks have a built in distribution vector: pirated/shared bestsellers.

    Side note: that blog post of mine on EPUB javascript security is pretty much exactly the point when I gave up on blogging about ebook formats, development, and technology. Here I was somebody with years of experience in the anti-malware industry who has researched ebooks for more than a decade raising a serious issue with long-term consequences and I didn’t get a squeak in response. I was comprehensively ignored.

    So, good luck to you in trying to raise the issue. I don’t have high hopes.

    (Oh, and btw, Amazon is extremely unlikely to ever support javascript in KF8 because they know how much work would be involved in implementing that support properly and safely.)

    • The key word being “safely”.
      Amazon and Apple know security is essential and job one. The publishing industry? Their idea of security is locking down their literary masterpieces from the peasant looking to steal their jewels. Beyond that, though…

      The publishing industry is effectively a bunch of wide-eyed tourists heedlessly strolling through a minefield giving nary a thought to decades of tech industry experience on the need to protect your customers.

      Publishing is a special snowflake!
      And besides, their customers–big chain book buyers–have nothing to fear. 😉

    • Let’s assume for the sake of argument that there is an e-reader which permits JS in e-books to access the outside world. OK, so it can send information out, and get information in.

      What information can it send out? Only what’s available within the sandboxed JS environment within that e-book, which is basically–almost nothing. JS in e-books cannot even get at the book metadata. It could send out information about what page is being read, or even the text on those pages, but to what avail? About the worst one can imagine is that information on reading habits is harvested, or that the book uses up a lot of bandwidth. If you encounter such a book, then remove it from your bookshelf.

      What can the book do with information that it retrieves from the net? Again, almost nothing useful or harmful. It can put the information up on pages–an ad is an obvious case. It could link to dictionary definitions, or do some geopositioning (which sounds useful for a travel book). But could it spread a virus or malware? How? To where? I guess it could put the book in an infinite loop, which would get shut down in due course by the JS execution environment.

      Of course, we should never say never. Exploits have a way of popping up. However, in this case there is a fundamental difference, which is that the JS environment in a book is sandboxed, as per the spec. It has no access to anything at the e-reader level, unlike a desktop application which can read and write to the file system or even install a rootkit. A book cannot possibly modify the e-reader software.

      It is interesting in this regard to note that although iBooks has supported JS in relatively full-fledged fashion for years already, there has not been one published exploit worthy of the name. When and if there is one, it would presumably be due to a flaw in the sandboxing logic. Which would then be fixed/plugged.

      Although in general it’s useful to talk about potential vulnerabilities, and never to assume they cannot be found or exploited, there’s a baby and bathwater aspect to this discussion. Even if we don’t want to wait for the first exploit, and we make the assumption that there will be a critical mass of reading devices permitting net access from within books, it would at least be reasonable to expect people talking about the vulnerabilities to describe the possible nature of the vulnerabilities in general terms, what would give rise to them, what they might look like. Do they have specific proposal for changes to the epub3 spec that would reduce/eliminate the supposed vulnerabilities–is the definition of sandboxing inadequate, for example? Or is the concern that low-end device makers won’t get sandboxing right? In the absence of such a discussion, the entire dialog has a “sky is falling” feeling to it.

      Given the low level of knowledge about the situation in many quarters, it is also unsettling that vague warnings about vulnerabilities, which in fact could occur only when e-readers permit net access to books AND sandboxing is flawed, could lead to the misunderstanding that scripting in books in general is somehow dangerous and undesirable and should be banned. At that moment we give up the entire vision of the rich interactivity which e-books should make possible. Sure, not every book needs it, and not everyone wants it, but for a huge segment of the publishing world we have the opportunity of redefining what a book is and what it can do. I, for one, certainly would be unhappy to see that potential shut off.

  9. LOL, I love these complaints “I am not touching epub3 ever ever ever because the javascript is going to upset my stomach!”

    Like nothing else could cause digital damage like uh using Windows.

  10. LOL I run a mac and nothing installed to protect me.It’s been that way since 1986. The last malware I experienced was the WDEF on a work machine in 1990.
    I guess its very different digitalling in a MS/Android world.

  11. In our hack, we considered how things would work in the case that no internet access was possible. One answer is embedded content. The ebook distributor could insert up-to-date content at time of download. There’s really no risk involved, and real opportunity for publisher-distributor cooperation. If that ever existed.

  12. iBooks coming to the Mac. You can put away the digital condoms.

  13. I agree pretty much with what Baldur wrote last year, by the way. denying js access network access except possibly for a whitelist is necessary for a variety of reasons. But we need good solid js for ebooks.

  14. Wow, this is interesting. A thought: how long before a publisher uploads a “pirate” version of a book to a torrent site with all sorts of malicious nasties in it. Didn’t some record label do this a few years back?

  15. learn about buena park // 20 June, 2013 at 12:20 pm //

    Re: Whomever made the remark that this was a good web site truly needs to possess their brain looked at.

Comments are closed.