Date: Mon, 1 Feb 2010 10:04:34 -0800
From: Michal Zalewski <lcamtuf@...edump.cx>
To: bugtraq <bugtraq@...urityfocus.com>
Subject: Re: Cross-Site History Manipulation (XSHM)

>From the post:

> Checkmarx Research Labs has identified a new critical vulnerability in
> Internet Explorer (other browsers are probably exposed the same way) that
> would allow hackers to easily compromise web applications.

I'm sorry if this response sounds harsh, but phrases such as "critical
vulnerability" and "compromise web applications" caught my eye.

The paper seems to focus on collecting information by navigating to
pages that will conditionally redirect the browser somewhere else
through certain types of client-side navigation (but as I understand
it, not the more common HTTP 30x responses?). By looking at history.*,
the attacking site may detect whether the redirect happened or not.

The paper then enumerates a number of scenarios where this would be of
particular concern (and presumably, meaningfully different from other,
well-known cross-domain privacy leaks - see
http://code.google.com/p/browsersec/wiki/Part2#Privacy-related_side_channels
for a sample). Unfortunately, in my opinion, these scenarios do not
seem to warrant being classified as "critical" (or really, anything
but "low"); and for most part, are not unique to this vector at all:

1) "Login Detection" - if the site redirects to a login page when
/myaccount is requested, we know the user is not logged in. Unless I
am mistaken, the same information can be collected through a number of
well-known vectors: image or script onload / onerror events, including
remote CSS or scripts and testing for side effects, page unload
timing, cache timing, CSS :visited, probing frames.length and other
publicly visible global properties, etc.

All of them are well-known (see "Resource inclusion probes" in BSH),
and AFAICT, do not pose any appreciable security risk. They are a
privacy nuisance, but completely dwarfed in comparison with other
browser fingerprinting vectors.

2) "Resource Mapping" - if the site redirects to a "404" page when
http://intranet/something.txt is requested, we know whether the file
exists or not. The same information can be collected by timing page
loads, frames.length, etc; in most cases I've seen, the 404 URL
incorporates portions of the original URL, too (say,
/NotFound.aspx?origURL=http://intranet/...), so CSS :visited probes
and cache timing is on the table.

Any direct benefit to attackers is probably negligible, especially
keeping in mind they can, for example, also port-scan internal
networks or execute XSRF / XSS / SQL injection attacks against
internal targets freely. The problem of unconstrained Internet ->
intranet fenceposts is very real, but not new - see:
http://code.google.com/p/browsersec/wiki/Part2#Local_network_/_remote_network_divide

3)  "Error Leakage" and "State Detection" - if server errors result in
a redirect to a "500" page, you can get additional feedback about
whether a security attack such as XSS or XSRF succeeded. The same can
be achieved through page load timing, frames.length or - in the
aforementioned common case - with CSS :visited and friends.

I fail to see a significant security impact: well-designed
applications that account for known security issues are not any more
at risk; buggy applications can be freely exploited without this
direct feedback, too. While it may make some attackers a bit happier,
it's not a critical bug.

4) "Information Inference" - gives a hypothetical application that
accepts the URL of
"http://Intranet/SearchEmployee.aspx?name=Jon&SalaryFrom=3000&SalaryTo=3500",
and returns a normal page if matching rows are found, but redirects to
an error page if not (instead of the more intuitive "no matches found"
response).

Load timing, frames.length, and CSS :visited can probably be used to
collect the same info - but that aside, it's an interesting case, if
actually seen in the wild. The example strikes me as a bit unlikely;
are you aware of any application that would, in fact, behave this way
and disclose sensitive information in the process?

5) "Cross-Site User Tracking" - discusses staying in the background
and probing history.length to detect certain page transitions for the
purpose of detecting certain UI actions. The outlined phishing vector
sounds somewhat plausible: it requires the attack page to be running
in parallel in a separate window or a tab, and the user to be
inattentive, but it could happen. It's not specific to history.*,
though: probing frames.length and related properties is an equivalent.

6) "Cross-Site URL/Parameters Enumeration". Discusses calling
history.go(url) to see if a particular URL appears in the current
history

This is actually sort of interesting: this behavior of history.go()
seem to be specific to MSIE, and is a pretty bad idea. That said, the
attack is conceptually similar to CSS :visited, frames, or cache
probing. The author suggests that the fact this vector is restricted
to the current session gives the attacker a distinct advantage; I
would suggest that because it is restricted to short-lived, per-window
history, it puts him at a significant practical disadvantage. It's a
privacy issue, but conceptually similar to well-studied vectors that
probably need to be considered holistically.

...

Bottom line is, my impression is that it's a collection of interesting
thought experiments along the lines of "what could you do with any
generic cross-domain probing technique"; from that perspective, it's
pretty good, and fits the existing body of research. Why this
collection is framed in the context of history.*, or claimed to be a
critical new vulnerability, is lost on me, though.

Cheers,
/mz

Powered by blists - more mailing lists