6 ms·

It is the NSIS' fault for auto-loading existing dll in the same working directory if presents. And UAC only does its job: To run a command with elevated privile

by fidz 11y ago

It is the NSIS' fault for auto-loading existing dll in the same working directory if presents. And UAC only does its job: To run a command with elevated privilege (so does sudo). UAC does not really care the executed code.

icebraining 11y ago
It is the NSIS fault for auto-loading existing dll in the same working directory if presents. Well, I'd say it's Windows fault for having LoadLibrary do so by default. Unsafe actions should have to be manually enabled, not manually disabled!
- fidz 11y ago
  afaik we can specify absolute path in LoadLibrary function. If it isn't, yes, LoadLibrary will use cwd relative by default -- which is dangerous for non-installed program. This is okay for installed program since you need additional privilege to alter Program Files directory.
  - plorkyeran 11y ago
    It's relative to the location of the executable, not the current working directory. The idea on Windows is that an application's directory is a trusted location created specifically for that application. Running executables directly out of a Downloads folder is a violation of the Windows security model, so in that sense the security vulnerability is Chrome's fault, as the "correct" thing to do is to put downloaded files into different folders as older versions of IE did. Of course, that's terrible UX, and considering that this exact problem has been popping up for decades, I'd consider a manifest flag for "don't trust the application directory" long overdue.
    - userbinator 11y ago
      Of course, that's terrible UX I find the "put everything that gets downloaded in one folder" to be worse UX than being able to choose where each download goes as it means having to move things back out of the downloads folder instead of them being downloaded to where I want them; especially when they're large files I wanted to put on a different drive, so the move turns into a lengthy copy operation.
      - dgoldstein0 11y ago
        I think both have their pros and cons - the "where do you want to save this" dialog sucks if you don't care, but the lack of a dialog sucks if you do care are you are particular about your organization. Personally I don't find organizing after the fact to be that difficult, but then again I don't typically download huge files.
    - chris_wot 11y ago
      That's a pretty awful security model, and an even worse assumption!
    - DCoder 11y ago
      > It's relative to the location of the executable, not the current working directory. It actually searches both the location of the executable and the CWD: https://support.microsoft.com/en-us/kb/2389418#mt1 https://support.microsoft.com/en-us/kb/2389418#mt1
_nedR 11y ago
Doesn't UAC share some blame for telling me the code its running is signed and unmodified but actually it is not?

by fidz 11y ago

icebraining 11y ago

It is the NSIS fault for auto-loading existing dll in the same working directory if presents. Well, I'd say it's Windows fault for having LoadLibrary do so by default. Unsafe actions should have to be manually enabled, not manually disabled!

fidz 11y ago
afaik we can specify absolute path in LoadLibrary function. If it isn't, yes, LoadLibrary will use cwd relative by default -- which is dangerous for non-installed program. This is okay for installed program since you need additional privilege to alter Program Files directory.
- plorkyeran 11y ago
  It's relative to the location of the executable, not the current working directory. The idea on Windows is that an application's directory is a trusted location created specifically for that application. Running executables directly out of a Downloads folder is a violation of the Windows security model, so in that sense the security vulnerability is Chrome's fault, as the "correct" thing to do is to put downloaded files into different folders as older versions of IE did. Of course, that's terrible UX, and considering that this exact problem has been popping up for decades, I'd consider a manifest flag for "don't trust the application directory" long overdue.
  - userbinator 11y ago
    Of course, that's terrible UX I find the "put everything that gets downloaded in one folder" to be worse UX than being able to choose where each download goes as it means having to move things back out of the downloads folder instead of them being downloaded to where I want them; especially when they're large files I wanted to put on a different drive, so the move turns into a lengthy copy operation.
    - dgoldstein0 11y ago
      I think both have their pros and cons - the "where do you want to save this" dialog sucks if you don't care, but the lack of a dialog sucks if you do care are you are particular about your organization. Personally I don't find organizing after the fact to be that difficult, but then again I don't typically download huge files.
  - chris_wot 11y ago
    That's a pretty awful security model, and an even worse assumption!
  - DCoder 11y ago
    > It's relative to the location of the executable, not the current working directory. It actually searches both the location of the executable and the CWD: https://support.microsoft.com/en-us/kb/2389418#mt1 https://support.microsoft.com/en-us/kb/2389418#mt1

_nedR 11y ago

Doesn't UAC share some blame for telling me the code its running is signed and unmodified but actually it is not?