view-source/resource “vulnerability” does not expose personal information

Ronald van den Heetkamp has claimed that he found a vulnerability that affects all released versions of Firefox, and so the Mozilla security group and others have been investigating it, as we do all such claims.

In this case, it appears to me as though Ronald is simply mistaken. The files to which Ronald demonstrates access do not have the user’s settings, though he claims otherwise. Those files (the user’s data) are not stored in the Program Files hierarchy on Windows, or the equivalent on other operating systems. Instead, the preference files that he is showing in his “exploit” are ones that are defaults that are shipped with Firefox, and made freely available on the web. Again, these are not user settings, but defaults that are shipped with all copies of Firefox and contain no personal information.

(NB: this issue should not be confused with the recent “flat chrome” directory traversal vulnerability that affected users of some extensions, and which 2.0.0.12 fixes.)

I don’t know if Ronald will issue an update to his post, as he did for a previous mistaken vulnerability report, but since the story has been taken at face value by Slashdot and likely others, I thought I’d post about it here.

Edit: this is the same thing that RSnake and others on his blog discussed last May; comments there are possibly of interest. Ronald participated in the thread but didn’t think it was an important problem back then, if I understand his comment correctly.

16 comments to “view-source/resource “vulnerability” does not expose personal information”

  1. Ronald van den Heetkamp
    entered 10 February 2008 @ 10:50 am

    I’m not mistaken.

    I never claimed directory traversals, I clearly said it was an information leak. Besides this .js file I was also able to reach .manifest files which leaked the personal installation directory due to some extensions that register the path inside that manifest file. (XULmaker for instance).

    So you think it stays with this info leak? hardly, consider the file upload flaw. If possible, I could trigger to upload the manifest file extract the personal Firefox path from it, redirect surfers back and read all personal files from the personal Firefox directory. Bang! a vulnerability, or not?

    Saying it isn’t an issue is a really narrow viewpoint on exploiting someone. By combining several found flaws it can become a serious issue. The best example was the traversal through extensions. Btw I didn’t slashdot it nor commented there, it’s their game to making it bigger than it really is, not mine.

  2. entered 10 February 2008 @ 10:52 am

    Mike,

    Would this be an issue in cases where users are running a portable installation of Firefox (where the app and profile are grouped in the same directory)? I suspect that a unique profile name would assist here (making it difficult / impossible to get to by script), but I don’t know all the details. Just thought I’d throw that out there.

    • Ben
  3. Boris
    entered 10 February 2008 @ 12:42 pm

    If possible, I could trigger to upload the manifest file

    That doesn’t rely on the resource:// thing, now does it? You already know where this manifest file is: it’s in the standard install directory.

    redirect surfers back

    Back to where, exactly?

    I’m sorry, but is seems to me that you’re grasping at straws here…

  4. take
    entered 10 February 2008 @ 1:08 pm

    @boris you missed the point, a web site never should have the permission to get your files! This is a serious flaw.

  5. entered 10 February 2008 @ 1:10 pm

    Ronald: your post says:

    “Because directory traversal through plugins is all nice and such, we don’t need it. We can trick Firefox itself in traversing directories back.”

    That sounds like you’re claiming directory traversal, because you say “traversing directories”.

    I have a hard time reconciling your “and this without any plugins” position with your example of extensions putting path information in the manifest, but even ignoring that I don’t understand the “read all personal files from the personal Firefox directory” part of your proposed exploit. Your post shows script transclusion, but manifests aren’t script. Trying to pull even greprefs.js into an iframe to reach the DOM is blocked in my 2.0.0.12, as it should be.

    What exactly do you mean by “personal Firefox directory”? resource: doesn’t load anything outside of the program installation directory (with the lone exception of a non-traversable parent directory list, as you correctly point out in another post), and Firefox doesn’t “by default” — in your words — put any information in there that Mozilla doesn’t also put on its FTP site.

    And even with XULMaker installed to both local and global locations, I don’t see any path information stored in manifest files — could you tell me what version you’re using?

  6. entered 10 February 2008 @ 1:12 pm

    Ben: I don’t believe that Portable Firefox puts profiles inside the program directory, but rather alongside it. If they put the profile data inside the program directory, and they use a guessable name, then there might be risk, but I’d need to look at the specifics of an implementation to say.

  7. entered 10 February 2008 @ 1:57 pm

    Granted you’re not likely to be able to do anything with this “vulnerability”, but web sites shouldn’t be allowed to read from your hard drive, should they?

  8. Boris
    entered 10 February 2008 @ 5:21 pm

    take, I didn’t miss the point at all. Reading this file tells the site absolutely nothing they didn’t already know. They could just as easily get this file by getting it via http from bonsai, pulling it directly from the CVS repository.

    I agree that it’s not great that even this completely safe read is allowed, because it makes a trifle harder to prove that unsafe ones are not allowed, and the added complication in the proof confuses people at tomes. So we’re working on disallowing it at some point. But since it is completely safe, this is a low priority endeavour.

  9. entered 10 February 2008 @ 7:53 pm

    While I generally agree with Mike and Boris that this is NOT a vulnerability-that-requires-a-point-release, I would like to point out that this

    Reading this file tells the site absolutely nothing they didn’t already know. They could just as easily get this file by getting it via http from bonsai, pulling it directly from the CVS repository.

    is incorrect in two ways.

    1. As mentioned in RSnake’s comments, you can use this to bust user-agent spoofing, because you can trap-and-load resource://gre/defaults/pref/firefox.js and access the default value of general.useragent.extra.firefox to get the name and exact version number, even if the user has changed the UA string.

    2. Linux distributions modify some of these files during packaging. Ubuntu, for example, changes about a dozen of the default preferences listed in this resource://gre/defaults/pref/firefox.js (search http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_2.0.0.12+1nobinonly+2-0ubuntu0.7.4.diff.gz for “firefox.js”). Off the top of my head, I can’t think of any way to exploit this… just pointing out that millions of Firefox users are using .js files that are different from those in your CVS repository.

  10. Ronald van den Heetkamp
    entered 11 February 2008 @ 5:36 am

    –What exactly do you mean by “personal Firefox directory”?– says Shaver.

    Are you playing with me? would make a great forum sig. btw :)

    I told you what it was and what it wasn’t. And there are files that are being written in. XPIinstal.manifest is one of them, it contains the full path to the –yep again– personal firefox installation dir. Not that I care, I use Opera, I just don’t like web-servers browsing my browser, even if it is a reconnaissance technique.

    Besides I only mention traversing directories in relation to an early find by Gerry that did exactly the same, only through plugins. That was his first finding which utilized the extensions to read the all.js file. Well, turns out we don’t have to, because the resource:/// translates back to the dir we want to traverse. THAT is was I said, thus it seems you are bothered on your own interpretation of it.

  11. Ronald van den Heetkamp
    entered 11 February 2008 @ 5:52 am

    “Edit: this is the same thing that RSnake and others on his blog discussed last May; comments there are possibly of interest. Ronald participated in the thread but didn’t think it was an important problem back then”

    Well, can’t I change my perception of flaws –or life in general– ? back then I didn’t see it as such and I was comfortable with that, But hey guess what: I’m human also, even I make progress over time. It’s not that I’m the same person as I was back then. I know where you are heading at, and that is fine.

  12. Martijn
    entered 11 February 2008 @ 8:32 am

    Ronald, could you post an example of the vulnerability you are seeing?

  13. steven
    entered 11 February 2008 @ 2:25 pm

    regarding, “view-source/resource “vulnerability” does not expose personal information” http://shaver.off.net/diary/2008/02/10/view-sourceresource-vulnerability-does-not-expose-personal-information/

    shaver: If they put the profile data inside the program directory, and they use a guessable name, then there might be risk

    In my case, hold over from OLD Netscape days, I keep my Profile in my SeaMonkey directory (& still called Mozilla at that). Wouldn’t install.log (if extensions are installed) give away location of Profile? And that would be accessible via view-source:resource:///install.log ([1/3] Installing: C:\WLIB\Mozilla\USERS\therube\chrome\nukeanything.jar)

    If I type view-source:resource:///USERS/therube/hostperm.1 on the URL line, my hostperm.1 is visible. Is that also the case to someone non-local, across the internet? (time to change the location of my Profile?)

  14. VanillaMozilla
    entered 12 February 2008 @ 4:08 pm

    Yes, show us exactly what information you can get that you say is so damaging. Tell us exactly what “personal files” you can get from “the personal Firefox directory”.

  15. entered 28 February 2008 @ 3:48 pm

    Well, you can certainly get a list of every extension my browser has installed by looking at view-source:resource:///install.log

  16. entered 22 June 2008 @ 1:59 pm

    Yes please, Show us exactly what information can be obtained you say is so damaging. Tell us exactly what “personal files” can be reached since “the staff directory Firefox.”