3 ms·

Browsers could protect users from this class of vulnerability by making it so that, if you run a browser-downloaded executable from within the browser, it first

Browsers could protect users from this class of vulnerability by making it so that, if you run a browser-downloaded executable from within the browser, it first moves it to an empty directory and runs it there.

marcosdumay 11y ago
Browsers can't do that. At least not in a general enough way, since it's Windows that executes the files. Windows could stop trusting code in folders with some flag. That would be much more useful.
- cornholio 11y ago
  Such flag already exists: http://www.howtogeek.com/70012/what-causes-the-file-downloaded-from-the-internet-warning-and-how-can-i-easily-remove-it/ http://www.howtogeek.com/70012/what-causes-the-file-download... It's a simple fix for Windows to disable local folder DLL loading based on the Zone.Identifier ADS. There's no usecase where an EXE downloaded from the internet should load a DLL from it's current folder. An alternate quick fix for the browser to redirect all DLL/SYS/OCX/Whetever to a DLLs folder inside the Downloads directory, and keep the EXEs in the main folder as before, so as not to confuse the users. Downloading DLLs is so rare that the extra hoop is acceptable.
saulrh 11y ago
Don't need the extra move step. Just put every download in its own directory. Or give every source (domain? something else?) its own directory. There's something in here that feels like cookies and cross-site conventions.
- dgoldstein0 11y ago
  This sounds like an interesting mitigation, but comes with it's own drawbacks: - you now start worrying about if it's possible to get a malicious download from your domain that dll-hijacks non-malicious downloads (better than the current state of the world, but not a lot) - less user friendly: who wants to remember what domain they downloaded something from when they go looking for an old download? also there's the question of should you associate the file with the domain that served it (probably?) or the domain that was in the browser bar when the download was triggered? I think it's unclear because the user's will expect the latter but the former makes more sense as security. Anyhow I think the right answer is that this is on the OS to provide better defense mechanisms. Maybe just something like the ability for the browser to tag the file with the domain it's from, instead of just "the internet". And then the OS could say "exe from www.foo.com is trying to load dll from www.bar.com, this looks fishy do you want to allow?" or maybe just flat out fail it; this way you get your cross-domain restrictions but less usability problems. Or better yet, the OSes could solve this problem entirely by having a much stronger whitelist of what DLLs are included from where. why don't we just require programs to specify the full path to any DLL they try to load, instead of doing a search for the file? Or maybe some sort of code signing technique could apply, and programs could specify they want to load X dll, but only if signed by Microsoft or whoever the expected party is, with some optional power-user way to override this? Or maybe we should just have some sort of warnings when you download a DLL from the internet, and put DLLs in their own download folder or something? That might be the easiest mitigation for a browser to implement.

marcosdumay 11y ago

Browsers can't do that. At least not in a general enough way, since it's Windows that executes the files. Windows could stop trusting code in folders with some flag. That would be much more useful.

cornholio 11y ago
Such flag already exists: http://www.howtogeek.com/70012/what-causes-the-file-downloaded-from-the-internet-warning-and-how-can-i-easily-remove-it/ http://www.howtogeek.com/70012/what-causes-the-file-download... It's a simple fix for Windows to disable local folder DLL loading based on the Zone.Identifier ADS. There's no usecase where an EXE downloaded from the internet should load a DLL from it's current folder. An alternate quick fix for the browser to redirect all DLL/SYS/OCX/Whetever to a DLLs folder inside the Downloads directory, and keep the EXEs in the main folder as before, so as not to confuse the users. Downloading DLLs is so rare that the extra hoop is acceptable.

saulrh 11y ago

Don't need the extra move step. Just put every download in its own directory. Or give every source (domain? something else?) its own directory. There's something in here that feels like cookies and cross-site conventions.

dgoldstein0 11y ago
This sounds like an interesting mitigation, but comes with it's own drawbacks: - you now start worrying about if it's possible to get a malicious download from your domain that dll-hijacks non-malicious downloads (better than the current state of the world, but not a lot) - less user friendly: who wants to remember what domain they downloaded something from when they go looking for an old download? also there's the question of should you associate the file with the domain that served it (probably?) or the domain that was in the browser bar when the download was triggered? I think it's unclear because the user's will expect the latter but the former makes more sense as security. Anyhow I think the right answer is that this is on the OS to provide better defense mechanisms. Maybe just something like the ability for the browser to tag the file with the domain it's from, instead of just "the internet". And then the OS could say "exe from www.foo.com is trying to load dll from www.bar.com, this looks fishy do you want to allow?" or maybe just flat out fail it; this way you get your cross-domain restrictions but less usability problems. Or better yet, the OSes could solve this problem entirely by having a much stronger whitelist of what DLLs are included from where. why don't we just require programs to specify the full path to any DLL they try to load, instead of doing a search for the file? Or maybe some sort of code signing technique could apply, and programs could specify they want to load X dll, but only if signed by Microsoft or whoever the expected party is, with some optional power-user way to override this? Or maybe we should just have some sort of warnings when you download a DLL from the internet, and put DLLs in their own download folder or something? That might be the easiest mitigation for a browser to implement.