back to article Two pentesters, one glitch: Firefox browser menaced by ancient file-snaffling bug, er, feature

Mozilla has been sitting on a new variant of an age-old flaw for almost a year, even with public disclosure happening back in January. The issue, disclosed by Dr Vladimir Bostanov of SySS GmbH on 16 January 2019 months after he'd privately reported it to Moz in July 2018, relies on an old implementation of Same Origin Policy ( …

  1. Anonymous Coward
    Anonymous Coward

    ""We are currently updating the security model to ensure that files sent to users cannot expose their local files. The patch will be shipped within the next few days."

    Security is only taken seriously when vendors are exposed for failing to react. This is a good argument for publishing exploits when the vendor fails to react, despite being given months to do so.

    1. BillG
      IT Angle

      Adblock to the rescue?

      I wonder - can an ad blocker be configured to block the file:/// prefix?

  2. Dan 55 Silver badge
    Meh

    Sort of open source

    "They almost never talked to me – they talked among themselves without reacting to my posts." He described the discussion as "interesting and productive", but added: "I could not participate – whatever I wrote elicited no response."

    Having seen the way they ignore feedback from proposals for user interface changes and jettisoning features, it's not that surprising.

    1. Flocke Kroes Silver badge

      Re: Sort of open source

      Everybody has ideas for changes (and occasionally improvements) to the user interfaces they use / put up with. Many contradict someone else's proposals and implementing a significant proportion of them would take ages.

      If there is some user interface change that really matters to you, code it, set the default behaviour to the old style and add an on switch for your idea in settings. Test the new idea and test that the old behaviour is correctly restored by pressing clicking the appropriate off button in settings. Publish your patch along with documentation for what it does, how to stop it and why you think it is the best idea since disabling javascript.

      If you are right, people will start using your patch and ask why it is not included as standard. If you are wrong, take a hint from the silence (or flames). If you cannot be bothered to code it yourself (even if that includes learning how to program) then you have no right to complain when other people do not bother to do your work for you for free.

      1. Dan 55 Silver badge

        Re: Sort of open source

        Mozilla's own proposals. It goes something like this:

        1. We're going to make these changes/remove these features.

        2. A load of non-contradictory feedback saying it would be a disaster.

        3. We're going to do it anyway because metrics.

        4. Metrics are not useful because you're changing/removing a power user feature used by a relatively small number of people.

        5. We're going to do it anyway because it'd be too difficult for us to do otherwise.

    2. iron Silver badge

      Re: Sort of open source

      If you want a UI change write a theme.

      1. Dan 55 Silver badge

        Re: Sort of open source

        The new Firefox doesn't do themes, just a coat of paint which Mozilla now call a theme.

        You can edit a .css file in the profile but it can't be made available as an extension unlike before.

  3. Eddy Ito
    Trollface

    ("Click here for your free iPad!")

    Your link is broken.

  4. Anonymous Coward
    Anonymous Coward

    Same Origin Policy

    "We are currently updating the security model to ensure that files sent to users cannot expose their local files."

    Hopefully this will stop bad actors from using short TTL from scanning users files or other devices on the users private network by registering a URL to 127.0.0.1

    (See also: scanandcleanlocal[.]com)

  5. ThatOne Silver badge

    Firejail

    Severely limit what your browser can access, so even if some clever trick gives people access to your files through your browser, they will only get to look into "/Download"?...

    1. ds6 Silver badge

      Re: Firejail

      You should see the Downloads folders of the sheep I have to herd. All of their files are in their Downloads. Multiple times.

      Financials, client documents and personal information... (1) (2) (3)... Gigs of it.

      1. ThatOne Silver badge

        Re: Firejail

        Well, we're speaking about people wanting to protect themselves here, so your argument doesn't stand.

        There is no limit on the way down the carelessness scale: There are people who have security doors and leave their keys under the floor mat, that doesn't mean security doors are useless. It means those people are useless.

  6. Pascal Monett Silver badge

    "and hey presto – some naughty JavaScript swoops in"

    and is stopped cold by NoScript.

    Once again, NoScript is the solution because JavaScript is and always has been a Bad Idea (TM).

  7. Alan Sharkey

    Fixed in 68.0

    I just updated to version 68.0 (dated today). One of the fixes - " Local files can no longer access other files in the same directory."

  8. Lee D Silver badge

    There is only one valid reason for a browser to be accessing the local filesystem (except its own execution) outside of its own program folder, or the users "profile" folder. And that's uploads and downloads.

    file:/// protocol should be dead, killed, executed, put out of its misery. There's no reason for it. A lot of web dev tools won't ever work via file:/// anyway, and force you to run a local web server if you want to prototype them (mainly because browser DOMs now - correctly - ban such actions... I know I can't load an Emscripten / Webassembly file from the local filesystem without the browser just throwing up its arms and not executing it).

    And uploads are easy to fix:

    Browser believe that the user wants to request a file.

    Browser executes, in a completely separate and secure context, a single program that can't be run again until the file is actually selected by the user. Said program runs in its own execution space, takes *no* data from the browser whatsoever (if I was being nice, maybe the *title* of the requested window, but you can see how even that could be scammed and you think you're uploading your photo to Facebook but actually you're uploading your photo to a malicious tab in the background!).

    Said program lets user select file from local filesystems. Reads said file. Provides contents of said file to browser. (Browser could supply a buffer or, more likely, said program creates a suitably-sized buffer and returns the address of it to the browser). Said program has exactly zero requirement to access the Internet or act upon any data from the browser in any way, shape or form.

    Said program terminates, signalling browser that it's done, and where it put the data.

    Browser waits for that termination signal, picks up the data from the location, supplies it to whatever mechanism triggered the request (a file upload, or whatever).

    Downloads are literally the same in reverse - the browser supplies the data and tells a local helper program "Ask the user where he wants this, and save it there for him".

    The problem with modern browser is *not* that they can't be secured. It's that people are dumb and haven't learned the lessons of history. Isolate everything. Have minimal message-passing between contained modules. Don't let even one module get all the privileges. One module to determine users preferences. One module per tab to parse HTML and gather resources. One module per tab to render that content to a video memory area. One module to assemble that content on demand inside a UI (and the tab module doesn't even need to *know* whether it's visible or not!). One module to do file accesses for uploads. One for downloads. And don't let even a single tab be able to control/interface/message/even detect the presence of - any other tab.

    Break it down. Erect walls between them all. Strip permissions from everything back to the bare bones (uploads/downloads don't need to touch networking AT ALL, the UI module requests information from the settings module but never queries them directly, etc.). Then the chances of, say, a dodgy bookmark corrupting the browser's stack to provide full filesystem access to a tab on a related site, etc. are nil.

    When you are designed the one, primary, major interface between a user, an OS and an untrusted third-party scripting language, you're an idiot to do it any other way at all. When a tab falls over, it falls over, and takes... nothing else with it. I can't tell you how often Chrome/Firefox browsers LOCK UP COMPLETELY because one tab goes a bit mad on the old Javascript. It just shouldn't be happening.

    We should have learned this lesson by now. And especially after the "let's put the browser INSIDE the OS and let people poke all the internals!" of the Internet Explorer days.

    I will happily take my browser rendering a fraction of second slower, over it ever making possible a remote compromise of my machine with just a single click from an unprivileged user.

    1. Anonymous Coward
      Anonymous Coward

      You are placing a lot of trust that the operating system this fictional web browser is running on is capable of perfectly isolating all of these avenues like you described. Try developing this on Windows and tell me how airtight it is.

      Fact of the matter is mainstream operating systems do not have fine-grained permission models. You would have to develop it all yourself. And once someone is able to compromise your fancy sandbox (as has happened with browsers before) now they have free reign to kick everyone's sand castles over, because the underlying system has no way of preventing it from happening.

  9. Down in the weeds
    Pint

    Was it just me?

    I saw: "not as strict as we wanted it to be due to compatibility issues"

    I read: "not as strict as we wanted it to be due to complacency issues"

  10. Nodrog

    Re "The patch will be shipped within the next few days."

    Listed as fixed in FF68 released today.

  11. cantankerous swineherd

    sounds as though ff is going to be even less usable.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like