Hacker News Reader

Comment by striking | Hacker News Reader

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.

View on HN

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.

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.

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).

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.

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.

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).

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).

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.

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.

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!

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.

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.

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.

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.

That's a pretty awful security model, and an even worse assumption!

> 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

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

Reply on news.ycombinator.com