|
|
| |
| There is an interesting vulnerability in the default behavior of Firefox built-in 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. |
| |
Credit:
The information has been provided by Michal Zalewski.
|
| |
Vulnerable Systems:
* Firefox version 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 Michal 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).
|
| Subject:
|
Firefox popup Vilnerability |
Date: |
7 Feb. 2007 |
| From: |
Koil |
| This is particularly disturbing because I myself have created a batch file in my honey pot that causes the receiving machine to restart and format all it's local HDDs without user interaction If the local fills can be accessed this way with read wright permission, a lot of various systems could be easily damaged. With "e;echo"e; switched off and "e;force"e; commands anything would be possible. Yeah, that's just a little scary... |
|
| Subject:
|
Clarification |
Date: |
7 Feb. 2007 |
| From: |
guest |
| Firefox 2.0.0.1 is not affected? |
|
| Subject:
|
Nice work! |
Date: |
7 Feb. 2007 |
| From: |
Nick |
| Pretty cool- pretty scary. I don't think I'll be opening any popups now. |
|
| Subject:
|
dukess |
Date: |
7 Feb. 2007 |
| From: |
dukessdukess.dsa |
Firefox 2.0.0.1 Bypass Phishing Protection FLAW:
http://kaneda.bohater.net/security/20070111-firefox_2.0.0.1_bypass_phishing_protection.php
|
|
| Subject:
|
PC only |
Date: |
7 Feb. 2007 |
| From: |
nVir |
I guess that my "e;C"e; drive on my Mac is safe? Nyuk nyuk nyuk nyuk!!!
-duh |
|
| Subject:
|
Roy Schestowitz |
Date: |
7 Feb. 2007 |
| From: |
Roy Schestowitz |
| Is it cross-platform at all? Can the system level set a 'wall'? |
|
| Subject:
|
Clarification II |
Date: |
8 Feb. 2007 |
| From: |
dommy |
| Does this effect Linux the same way? Presumably it would be trivial for the originating site to decide what system is in use and download different code but how much damage could be done to a regular Linux user? |
|
| Subject:
|
Not everyone affected |
Date: |
8 Feb. 2007 |
| From: |
l33t |
| Not every user of Firefox is affected by this. Specifically, those who use a non-standard system temp directory...like me. So if you are 'noid about this happening to you just change your system temp directory to something like c:\temp\ or if you have another HD drive_letter:\temp\. Problem solved. |
|
| Subject:
|
Firefox popup Vilnerability |
Date: |
8 Feb. 2007 |
| From: |
Linux User |
I trust this is only a windoze-platform exploit?
No mention of this was made in the article. |
|
| Subject:
|
just another user vector |
Date: |
8 Feb. 2007 |
| From: |
someonemail.domain |
Hmmm this looks like the user has to click a malicious link, allow a popup, and download a file, before any damage can be done. I will have a hard time educating users to manually unblock an unrequested popup (as if they would even want to do that?), and do ALL THREE ACTIONS successfully in the right order to get them to infect their system.
All in all a bit too much effort on the social engineering front...but thanks for the tip. |
|
| Subject:
|
I agree with someonemail.domain |
Date: |
8 Feb. 2007 |
| From: |
flizz |
It's a pretty unlikely scenario from what I can see.
Anybody stupid enough to carry out (any of) this sequence of events probably deserves everything they get. |
|
| Subject:
|
This would only affect windoze |
Date: |
9 Feb. 2007 |
| From: |
ewok |
LInux systems do not have c:\windows\and_all that rubbish\ nor does it boot.ini Where some are bad sites we can try?
|
|
| Subject:
|
About the TEMP advice from l33t |
Date: |
11 Feb. 2007 |
| From: |
Me |
| The file will be saved in the temp directory even if you changed it. Your system knows where the temp directory is thanks to the Environment variable TEMP. The code in this article is just an example. With a few changes, the trick of changing the system temp directory is useless. |
|
| Subject:
|
Linux safe |
Date: |
1 Mar. 2007 |
| From: |
raven |
Ewok is wrong and right. Linux is safe but not for that reason. Even Linux has a temp folder that the system knows and where files are saved. One can detect the OS at script level and lift (theoretically) a file that they know the location of. Most Linux system files are on predictable locations.
Linux is mostly safe because of user levels. The browser can access those files that the user under which it runs can access and low-level user can't even read critical files. Only running FF as root can be damaging as such an attack could lift password files and/or perform root-level operations. Then again, I doubt anyone running Linux would be careless enough for this. |
|
| Subject:
|
Firefox 2.0 built-in pop-up block useless |
Date: |
17 Jun. 2007 |
| From: |
rc |
| No cookies or no specific sites allowed and guess what they still pop-up |
|
| Subject:
|
More Likely than you think |
Date: |
19 Feb. 2008 |
| From: |
chiefy |
| The pop up usually comes in the form of a Codec or player update so you won't expect it to be malicious. Screen shots are easy to duplicate... |
|
| Subject:
|
Mac OS X safe, hahaha Windows - Fail |
Date: |
12 Sep. 2008 |
| From: |
lol |
Haha, another windows fail....
FTW MAC and LINUX!!!! |
|
|
|
|
