843278 - Remote denial of service via crafted PDF files (resource exhaustion)

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Harry Sintonen]

Attachment: sample PDF files that reproduce the resource exhaustion DoS

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17

Steps to reproduce:

Open the crafted pdf file(s) in the browser. To successfully reproduce the issue it may be necessary to open multiple sample files at the same time. Navigating between the different open PDF tabs appears to make the issue trigger easier.

It's notable that this issue doesn't appear to crash 64bit version of the browser. Firefox 19 crashes on both Mac OS X and win32, while 64bit OS X Aurora [20.0a2 (2013-02-19)] does not. The 64bit version consumes up to 6GB of memory when all sample files have been opened.

It is likely that some pathological file could easily be developed that triggers the issue much easier.


Actual results:

1) Displaying each sample file consumes several GB of memory.
2) The browser runs out of memory and crashes.

Note: It is possible that some heap corruption might be in play, but this wasn't looked into yet. I think it is more likely that some malloc() fails and abort() gets triggered.


Expected results:

1) The browser should gracefully handle the low memory situation instead of crashing.
2) The built-in PDF reader should not gobble humongous amounts of memory with the crafted files.

Comment 1

[Harry Sintonen]

There wasn't "built-in PDF reader" choice to pick so it might be that this issue has been categorized wrong.

Comment 2

[Harry Sintonen]

Attachment: crashdump from os x firefox 19.0

Comment 3

[Harry Sintonen]

Attachment: OS X crash dump

Comment 4

[Matthias Versen [:Matti]]

You can DOS the browser also with simple html

Comment 5

[Yury Delendik (:yury)]

Cannot reproduce with the attachment above. Error in the web console:

[07:24:17.765] Warning: Indexing all PDF objects
[07:24:17.785] Invalid or corrupted PDF file.
PDF.JS Build: 4e90760
Message: InvalidPDFException

Comment 6

[Yury Delendik (:yury)]

Daniel, Matthias,

How was you able to replicate it? It's not even a PDF file (and rejected by built-in PDF Viewer if file type is renamed to PDF).

Closing as invalid?

Comment 7

[Matthias Versen [:Matti]]

I didn't test this because it's would not surprise me that it's possible to DOS a browser with many different ways. (just send a video file as text/html as example)

Comment 8

[Yury Delendik (:yury)]

Attachment: Worker sample

Comment 9

[Yury Delendik (:yury)]

Attachment: Minimal test case to replicate the issue

Comment 10

[Yury Delendik (:yury)]

Comment on attachment 716161 [details]
sample PDF files that reproduce the resource exhaustion DoS

Shall stay application/octet-stream. It's not trivial to extract packaged files on mac. (Extracted files can temporary be found at http://people.mozilla.com/~fbraun/meh/, files sample-10.pdf, sample-14.pdf, sample-19.pdf)

Comment 11

[Yury Delendik (:yury)]

The minimal test case (see attachment 716527 [details] and attachment 716523 [details]) is based on sample-10.pdf. Moving to different compartment.

Comment 12

[Yury Delendik (:yury)]

(reported also upstream https://github.com/mozilla/pdf.js/issues/2766)

Comment 13

[Harry Sintonen]

(In reply to Yury Delendik (:yury) from comment #6)
> Daniel, Matthias,
> 
> How was you able to replicate it? It's not even a PDF file (and rejected by
> built-in PDF Viewer if file type is renamed to PDF).
> 
> Closing as invalid?

Indeed, .tar.xz isn't a pdf file. It's a tar archive compressed with XZ.

To decompress the archive you can use:
- Windows: 7zip, http://www.7-zip.org/
- Mac OS X: The Unarchiever, http://wakaba.c3.cx/s/apps/unarchiver.html
- Linux: make sure that xz-utils package is intalled. Then: tar Jxf samples.tar.xz

Comment 14

[Harry Sintonen]

(In reply to Matthias Versen [:Matti] from comment #4)
> You can DOS the browser also with simple html

(In reply to Matthias Versen [:Matti] from comment #7)
> I didn't test this because it's would not surprise me that it's possible to
> DOS a browser with many different ways. (just send a video file as text/html
> as example)

1) The file is hosted as application/pdf not with some incorrect content-type such as text/html.
2) The files do not contain any HTML or javascript in them. They merely appear to trigger the built-in pdf.js to consume ton of resources. That combined with the inability of the engine to handle low resource situations gracefully leads to the DoS situation. pdf.js should probably attempt to perform some sort of minimal sanity checking against such pathological files. Even better, the javascript engine and/or the browser itself should not crash if malloc returns 0.
2) The crafted PDF file can be couple of hundred of bytes of size and easily gobble gigabytes of memory. That's slightly different from sending couple of gigabytes of video file as text/html.
3) If the browser can be DoSed in some other way too, wouldn't it rather make sense to report those issues separately so they can be tracked and fixed?

App crashing when running out of address space (malloc returning 0) doesn't look very professional, regardless of how it can be achieved.

Comment 15

[Harry Sintonen]

...and I need to learn to count. :-)

Comment 16

[Yury Delendik (:yury)]

(In reply to Harry Sintonen from comment #14)
> 2) The crafted PDF file can be couple of hundred of bytes of size and easily
> gobble gigabytes of memory. That's slightly different from sending couple of
> gigabytes of video file as text/html.

Purpose if PDF.js is take advantage of natural JavaScript sandboxing. By creating "crafted" PDF, you just "craft" HTML/JavaScript page. If you can do the same by opening PDF at http://mzl.la/pdf-js, then any crafted HTML can do that as well.

> 3) If the browser can be DoSed in some other way too, wouldn't it rather
> make sense to report those issues separately so they can be tracked and
> fixed?

Yes, I filed the separate issue (see comment 12). But by fixing only pdf.js logic you will still have the DoS issue that can be caused by the regular HTML page.

Comment 17

[Ted Campbell [:tcampbell]]

Fixed by pdf.js update.