6 ms·

I think the bigger joke is that you can hijack DLLs, and the UAC prompt and signed code verification don't say a word about it.

Spivak 11y ago
It's certainly an interesting problem. Suppose that an program that needs administrative permissions depends on lib.dll. Should lib.dll have to be bundled with the application and signed with the same key? Why not statically link at that point then? Since the libraries the application might pull in might not even be available before runtime would you prompt for each load? Maybe prompt for each load that isn't in a system directory -- implying that there isn't prior trust? You could embed the key the library developer signed the library with but then we have a key revocation problem and updating the library might require updating the application and business critical applications might hold entire departments back from getting security fixes. I don't think this is really a problem with DLLs or the signature process, but that the old installer tries to load any library in the executable directory.
- digi_owl 11y ago
  The constant issue of computer security is perhaps that software can only inspect actions, not intent. And any action taken can be either legitimate or nefarious, given the context of intent.
  - marcosdumay 11y ago
    At some point, infosec lies on user education. No arguing about this. But the exact point is open to argument. Software need an interfaces that reflect intent - if your browser dumps stuff from unrelated places at the same folder, and then the OS uses those unrelated stuff as if it was related, there's a completely failure from the software data to reflect the user intent. This is a blatant fault of the software stack (but of no party in particular).
  - vezzy-fnord 11y ago
    The classic way of mitigating the issue of intent, of course, is capability-based security. Standard ambient authority models basically leave the door wide open by decontextualizing all action, such that merely riding on someone's session from their end is sufficient.
    - digi_owl 11y ago
      That finds me thinking that a issue is perhaps that with modern personal computing, the system/kernel view of state (or some such), and the user view of state, are not lined up.
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.
winter_blue 11y ago
It's not Microsoft's or the UAC's fault. It's Nullsoft's fault. NSIS (Nullsoft Scriptable Install System) loads and executes the DLL without any verification. Also, you're not hijacking DLLs -- you're using a DLL to hijack NSIS (which runs with administrative privileges).
- icebraining 11y ago
  How can NSIS verify the DLL? How can an installer from, say, 2012 know if the copy of shfolder.dll in Windows 10 is valid? And worse - in some cases, NSIS wasn't even directly loading the DLLs, Windows was doing it behind its back (eg. NSIS called a Win32 function called OleInitialize, which loaded UXTheme.dll by itself).
  - Strom 11y ago
    All valid points. I think it should be possible, at least for Microsoft DLLs, to specify a flag that you are willing to load only those signed by Microsoft. A malicious version.dll wouldn't probably have a Microsoft signature. The signature verification would be done by the OS and thus would be future-proof. Even a OS-local whitelist for exemptions could work, where an admin could add some unsigned DLL hashes to the list that would still load. None of the downloaded malicious DLL files would pass this test.
- deleted 11y ago
  [deleted]

Spivak 11y ago

It's certainly an interesting problem. Suppose that an program that needs administrative permissions depends on lib.dll. Should lib.dll have to be bundled with the application and signed with the same key? Why not statically link at that point then? Since the libraries the application might pull in might not even be available before runtime would you prompt for each load? Maybe prompt for each load that isn't in a system directory -- implying that there isn't prior trust? You could embed the key the library developer signed the library with but then we have a key revocation problem and updating the library might require updating the application and business critical applications might hold entire departments back from getting security fixes. I don't think this is really a problem with DLLs or the signature process, but that the old installer tries to load any library in the executable directory.

digi_owl 11y ago
The constant issue of computer security is perhaps that software can only inspect actions, not intent. And any action taken can be either legitimate or nefarious, given the context of intent.
- marcosdumay 11y ago
  At some point, infosec lies on user education. No arguing about this. But the exact point is open to argument. Software need an interfaces that reflect intent - if your browser dumps stuff from unrelated places at the same folder, and then the OS uses those unrelated stuff as if it was related, there's a completely failure from the software data to reflect the user intent. This is a blatant fault of the software stack (but of no party in particular).
- vezzy-fnord 11y ago
  The classic way of mitigating the issue of intent, of course, is capability-based security. Standard ambient authority models basically leave the door wide open by decontextualizing all action, such that merely riding on someone's session from their end is sufficient.
  - digi_owl 11y ago
    That finds me thinking that a issue is perhaps that with modern personal computing, the system/kernel view of state (or some such), and the user view of state, are not lined up.

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.

winter_blue 11y ago

It's not Microsoft's or the UAC's fault. It's Nullsoft's fault. NSIS (Nullsoft Scriptable Install System) loads and executes the DLL without any verification. Also, you're not hijacking DLLs -- you're using a DLL to hijack NSIS (which runs with administrative privileges).

icebraining 11y ago
How can NSIS verify the DLL? How can an installer from, say, 2012 know if the copy of shfolder.dll in Windows 10 is valid? And worse - in some cases, NSIS wasn't even directly loading the DLLs, Windows was doing it behind its back (eg. NSIS called a Win32 function called OleInitialize, which loaded UXTheme.dll by itself).
- Strom 11y ago
  All valid points. I think it should be possible, at least for Microsoft DLLs, to specify a flag that you are willing to load only those signed by Microsoft. A malicious version.dll wouldn't probably have a Microsoft signature. The signature verification would be done by the OS and thus would be future-proof. Even a OS-local whitelist for exemptions could work, where an admin could add some unsigned DLL hashes to the list that would still load. None of the downloaded malicious DLL files would pass this test.
deleted 11y ago
[deleted]