579607 - Ability to use a timing attack via XHR to detect whether a particular IP/host is running an HTTP server

Status: RESOLVED DUPLICATE of bug 354493

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

Description

[Reed Loden [:reed]]

Attachment: PoC

Nicholas B. <[e-mail]> reported a cross-browser information disclosure problem using XMLHTTPRequest objects. I'll quote two pages from the slide deck available at https://www.bordergatewayprotocol.net/aricon/presentations/The_future_is_here.pdf.

=============================================================================

The fun starts when the request is
aborted
* For each request successful or otherwise an event is fired on
the XMLHTTPRequest object.
* This OnReadyStateChange occurs at least twice on
successful requests and at least once on aborted
XMLHTTPRequests.
* When a request is aborted due to lacking the header a
supporting browser triggers this immediately.
* When a rejection or an unreachable event occurs the event is
only fired off when the request times out.
* This means you can use a setTimeout handler to trigger the
abort before the timeout actually occurs.

This results in...
* When an abort occurs prior to the setTimeout() occurring we
know that xmlhttprequest sent to the second server is highly
likely to be listening for http style connections.
* When the setTimeout() occurs prior to the abort the target is
either not reachable by the browser or not listening on that port
for http style connections.
* Finally because this is being initiated by another domain's
javascript the results of these aborts can be issued back to the
original requesting server along with the ip address of the
machine that appears to be listening on the port in question.
* In effect you can use any browser supporting this method to
scan arbitrary networks for listening systems upon executing
the javascript.

Comment 1

[Reed Loden [:reed]]

Attachment: Slide deck

Comment 2

[Boris Zbarsky [:bzbarsky]]

General comment: this timing attack doesn't need XHR.  It can be carried out using onerror handlers on <img> elements just as well.  I think the only reasonable effective mitigation is forbidding access to internal IPs, period.  I also think that most of the stuff in that slide deck making noise about XHR is bullshit, given the above.

Comment 3

[Johnny Stenback (:jst)]

FWIW, bug 552090 (referenced in the whiteboard) has been fixed everywhere for over a year now.

Comment 4

[Josh Aas]

Does this bug still need to be hidden? According to the whiteboard it does not.