Closed Bug 369390 Opened 18 years ago Closed 18 years ago

popup blocker + XMLHttpRequest + srand() = oops

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: BenB, Assigned: dveditz)

References

Details

(Keywords: fixed1.8.0.10, fixed1.8.1.2, Whiteboard: [sg:low] user interaction required)

Date: Mon, 5 Feb 2007 13:18:52 +0100 (CET) From: Michal Zalewski <lcamtuf@dione.ids.pl> To: bugtraq@securityfocus.com Message-ID: <Pine.LNX.4.58.0702051038270.30846@dione> There is an interesting vulnerability in the default behavior of Firefox builtin popup blocker. This vulnerability, coupled with an additional trick, allows the attacker to read arbitrary user-accessible files on the system, and thus steal some fairly sensitive information. This was tested on 1.5.0.9. For security reasons, Firefox does not allow Internet-originating websites to access the file:// namespace. When the user chooses to manually allow a blocked popup however, normal URL permission checks are bypassed. The attacker may fool the browser to parse a chosen HTML document stored on the local filesystem, and because Firefox security manager treats all file:/// URLs as having "same origin", such a document could read other local files at its discretion with the use of XMLHttpRequest, and relay that information to a remote server. Now, to make the attack effective, the attacker would need to plant a predictably named file with exploit code on the target system. This sounds hard, but isn't: Firefox sometimes creates outright deterministic temporary filenames in system-wide temporary directory when opening files with external applications; even if we ignore this possibility (since it requires the user to take an additional step that may be difficult to justify), "random" temporary files are created using a flawed algorithm in nsExternalAppHandler::SetUpTempFile and other locations. The problem here is that stdlib linear congruential PRNG (srand/rand) is seeded immediately prior to file creation with current time in seconds (actually, microseconds, but divided by 1e6); rand() is then used in direct succession to produce an "unpredictable" file name. Normally, were the PRNG seeded once on program start and then subsequently invoked, results would be deterministic, but difficult to blindly predict in the real world; but here, the job is much easier: we know when the download start, we know what the seed would be, and how many subsequent calls to it are made - we know the output. In a different setting, there would be a level of uncertainty caused by the fact that system clocks tend to drift or have imprecise settings (although today, most Windows systems either synchronize with Windows Time, or domain time services, so this is less of a factor). Still, there's a yet another nail to the coffin: on first call, Javascript Math.random() is seeded using the same call in the same manner, PR_Now() * 1e-6. The seed, and hence a time very close to the moment of file creation, can be trivially computed by analyzing Math.random() output. But wait, why bother at all - Javascript can be used to directly read system clock with a 1-second resolution. One of several attack scenarios I could think of might look as follows: 1) Have user click on a link on a malicious page. The link would point to "evil.cgi", and have onClick handler set to function foo(). This function would acquire current system time, and use setTimeout to invoke window.open("p2.html?" + curtime,"new",""); in 100 ms. The aforementioned cgi script would return: Content-type: text/html Content-disposition: attachment; filename="foo.html" <html><body><script> x = new XMLHttpRequest; x.open("GET", "file:///c:/BOOT.ini", false); x.send(null); alert("The script attempted to read your C:/BOOT.ini:\n\n" + x.responseText); </script> 2) After user clicks the link, a download prompt will appear, and a copy of evil.cgi output would be saved in - for example - C:\WINDOWS\TEMP\c3o89nr7.htm. The download prompt will be immediately hidden under the newly created p2.html window (this, by default, bypasses popup blocker. because the window is created in response to user action). 3) The page currently displayed on top, p2.html, instructs the user to accept the popup to open a movie player or whatnot; since unsolicited popups are an annoyance, not a security risk, even an educated user is likely to comply. To create a popup warning, a script embedded on the page calls: window.open('file:///c:/windows/temp/xxxxxxx.htm','new2',''), with a name calculated by repeating a procedure implemented in SetUpTempFile() with a seed calculated by the server based on reported system time (p2.html?time). 4) When the user opens that particular popup, attacker-supplied HTML file is loaded and executed with local file read privileges (in the aforementioned example, the contents of BOOT.ini file would be reported back to the victim). (Ta-dah!) /mz
I guess the bugs are: * Bug 230606, Tighten the same-origin policy for local files. * Manually opening a popup should not get around CheckLoadURI. * Predictable random numbers are used for creating filenames that are intended to be unpredictable. Is there another bug on the missing CheckLoadURI? Is it already fixed on trunk?
See also bug 322529 ("Upgrade Math.random() to a better algorithm, such as Mersenne Twister"). Looks like wtc is interested in this for NSPR too. We should use MT in the tempname equivalent or whatever it is. jst says he doesn't know of a CheckLoadURI vs. popup manual open bug. /be
Jesse, please file bugs if you can. The stupid reseeding one should be easy to fix ASAP. Thanks, /be
Wikipedia says "Unlike Blum Blum Shub, [Mersenne twister] in its native form is not suitable for cryptography. Observing a sufficient number of iterates (624 in the case of MT19937) allows one to predict all future iterates." So switching to MT won't help against this attack.
Blum Blum Shub, a play on Jar Jar Binks? What a world. Ok, but please to be updating the other bug ;-). /be
Michal said simply seeding earlier (at startup) would help already.
Depends on: 369427
Depends on: 369428
Ok, there are now bugs on each part of this exploit: * Bug 230606, Tighten the same-origin policy for local files. * Bug 369427, Showing a blocked pop-up bypasses CheckLoadURI (can load file: URLs) * Bug 369428, nsExternalAppHandler::SetUpTempFile uses a poor source of randomness, resulting in predictable filenames
Depends on: 230606
Two of the three sub-bugs are fixed on the branches, any one of them stops this exploit. Calling this "fixed".
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.0.10, fixed1.8.1.2
Resolution: --- → FIXED
Whiteboard: [sg:low] user interaction required
You need to log in before you can comment on or make changes to this bug.