1732141 - Request loads forever if code is 101 or 304 and ct=application/pdf

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[jannis]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Visit a URL that returns a response with status-code=101 or 304, content-type=application/pdf and a non-empty body.

• https://demo.websec.saarland/echo/?ecohd_status=101&content-type=application/pdf&ecocnt_img=width=50
• https://demo.websec.saarland/echo/?ecohd_status=304&content-type=application/pdf&ecocnt_img=width=50

Also works if the URL is loaded in an iframe:

• https://demo.websec.saarland/static/iframe-hangs1.html
• https://demo.websec.saarland/static/iframe-hangs2.html

Actual results:

The browser will try to load the response forever and the load event on the page will never fire.

Expected results:

The browser should abort loading/or finish loading (a response is received) and fire the load event on the page.

A (compromised) website A could use this to stop other websites, that include website A in an iframe, from ever loading successfully. If the other websites use the load event on the page to start some important code, it will never execute and cease to work.

Comment 1

[Andrew McCreight [:mccr8]]

What is the behavior when a page takes forever to load under other circumstances?

Stopping the outer page from loading sounds like a DOS at worst, though it also requires getting the victim page to embed you as a iframe.

Comment 2

[jannis]

I think this depends on the reasons why the page takes forever to load.
If I remember my testing correctly, for some incorrect (or incomplete) responses Firefox will time out eventually. (Maybe this is not the case, I do not have an example at the moment).
For other reasons (e.g., the web server is sleeping) the behavior is the same, but this is the only example I currently know of where the web server does not have to spend any resources on it (a sleeping web server cannot close the connection, as this will interrupt the load).

Maybe, it could also be used to exhaust the connection pool without spending server resources, but this is DOS as well.

Comment 3

[Mirko Brodesser (:mbrodesser-Igalia), offline until June 7th]

Chrome apparently doesn't have this issue.

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia), offline until June 7th]

Changing severity to S2 because webpages may load forever because of this bug.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Since this issue is restricted to the mime type application/pdf and when the issue was reproduced, I saw the pdf viewer was loaded, do you think if there is something wrong in the pdf viewer?

Comment 6

[Brendan Dahl [:bdahl]]

This seems to be a timing issue in RangedChromeActions where the stream finishes before the viewer finishes loading and we add a listener for passive loading. Since the listener isn't added early enough we never send the message to the viewer to unblock on the load event. Note: things work correctly if you change the pref to pdfjs.disableStream to true which causes StandardChromeActions to be used.

I'm on PTO until Nov 1st, but if anyone wants to grab this we'll probably need to change something here.

Comment 7

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/pdf.js/pull/14217

Comment 8

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub master push: https://github.com/mozilla/pdf.js/commit/60ab751bb6f4814ef71f16c7d9f466d2eb7c6b1e

Commit merged into master by GitHub
Authored by Brendan Dahl (brendandahl)