I wouldn't really call this a vulnerability, it is a common caveat when dealing with basically any Windows software. If you have write access to the program directory of a piece of software, you can inject code into it through DLL hijacking techniques. But you can also just replace the binary itself with a malicious one, which is an even simpler attack, and the techniques described in this article can't prevent that.
Only sometimes - one easy attack is to trigger a web browser to download a .dll file, which doesn't let you overwrite existing files but does get new files on the load path of programs being run out of the download folder. (This was an easy attack on how many people run PuTTY, for instance.)
The million-and-one reason to change so that the browser always prompt you for where to download a file.
That must be one the most braindead defaults of the century. But I guess I'm the weird one as usual.
This is a huge issue for linux as well. Trigger a download and just wait until the OS or some file-exporer inspect the file and exploit the parser (which is typically ridden with security issues).
I was replying to the quote about the browser asking where to download the file. By default you get that prompt you mention but it won't let you choose where, if you choose to download it goes without asking to the downloads folder unless you've changed that setting in the options page to always ask where. Chrome is definitely a worse offender, it does not even ask you to confirm the download.
Unfortunately the zip files don't have top level directories, so the default download, extract, run "happy path" would leave them loading any DLL sitting there in the downloads folder.
```
$ unzip -t processactivityview-x64.zip
Archive: processactivityview-x64.zip
testing: ProcessActivityView.exe OK
testing: ProcessActivityView.chm OK
testing: readme.txt OK
No errors detected in compressed data of processactivityview-x64.zip.
```
I'm not sure which dialog you're talking about. Whenever I've extracted a zip file in Windows using Explorer, it's been using "Extract all" or "Extract here". I don't even see a way to get a dialog on my win 10 VM.
Those two options result in whatever's in the zip file being dumped into the same directory as the zip file itself. If the archive contains a top level directory, a directory appears. If it's just an exe and a chm and a readme, like the Nirsoft zips, then those files appear next to the zip archive.
There is only "Extract All", and that opens the dialog. Perhaps you also have 7-Zip installed which creates an "Extract Here" option that dumps the files in the current directory.
I do have 7-zip installed here. I could also be mixing memories across a few Windows versions. I know I've caused files to be extracted without a dialog in the past, which irritated me a great deal, on a vanilla system. But it's entirely possible that's a vista-era memory at this point.
> I sent him multiple mails about his STARTER ERRORS, but the guy is * deaf and dumb: NO reaction!
Is it necessary to write things like this about an individual in a blog? I mean, the guy made these tools and gave them away for free. You're not a customer. It's up to him to reply to your emails, and it's fine if he doesn't.
I am not sure to understand the actual level of "danger".
If I get this right, you should have a malware running in the background, waiting for the Nirsoft tool execution, in order to have a malicious .dll be copied in the folder (the author suggests "normally" the "Downloads" one is used) from which the tool is run.
Of course possible, but shouldn't be there other tools to avoid that a malware is running?
A website can just force a download of a dll into the downloads folder and most people wouldn’t notice it. If you then download the tools and run them you run the code in the dll as well.
Maybe, but then most people wouldn't use any of the Nirsoft tools.
On the other hand - personally - but not because of particular security measures, only for convenience, I tend to run those tools from within the .zip file (opened in 7-zip) i.e. in practice in a "random" directory created on the fly, i.e. something like \7zO6BD1.tmp (inside the users Temp folder).
Besides AFAIK/AFAICR all tools are available in .zip files, I don't think that the "common" user will open the .zip in the "Download" folder and routinely extract its contents in the same "Download" folder (as opposed to a path like C:\Nirsoft\<name of the tool> or similar).
I haven't tried, but DLL hijacking attacks are old, so I assume Chrome will warn you that a file may be dangerous if it's a DLL before dropping it to the Downloads folder.
Raymond Chen in this article seems to rather minimize the severity of arbitrary code execution attacks allowed by buffer overruns.
His logic is also faulty since he conflates 'End-User' permitted capabilities (what the App correctly allows the user/ request to do) with Application permissions to the OS.
Really this seems like it might be blinded by too many years of C/ C++ & immersion in stale campus group-think.
it's not arbitrary, this program execs what the user asks it to exec. if some non user can get it to exec something the user doesn't want it to exec, then yeah, it can be a problem. but a non user has to go trough the user to have the dll in place, so the problem is the user and the vector social engineering, not a vulnerability.
Just a reminder that powers agencies [0] [1] and malware have exploited dll hijacking on software as specific as Notepad++ , and also some common software used by technically inclined people, so a targeted attack at Nirsoft is not so unthinkable.
I think this is pretty misleading because the Notepad++ 7.3.3 update doesn't really improve the security of the product in any way. Those agencies used DLL hijacking as a convenient technique to inject code into Notepad++ but they could have just as easily accomplished the same thing by replacing the binary with a malicious one instead. The change in the 7.3.3 update was basically for political purposes only.
> From the linked posts, they were going via a shared downloads directory, so they could not have.
Do you mean the Stack Overflow answer? That looks like original research to me. Yes, Windows will by default try loading DLLs from the current working directory, but:
1. it has lower priority than the program's own directory, and Notepad++ ships with a copy of SciLexer.dll, and more importantly:
> it wasn't that some bored attacker took the long way around for fun.
There are other conceivable reasons for putting the hijack inside a DLL, e.g. because you're more likely to inspect the executable. But permissions wise, it was no easier than modifying the executable.
As far as I remember, the "DLL hijacking" is a serious issue when the program like Microsoft Word searches for the DLL exactly at the location of the user file to be opened and exactly after the user selects the file: if you e.g. open a .DOC file from the Documents folder and an attacker placed in the Documents folder his own DLL, that DLL would have been then loaded too by some unpatched versions of Microsoft Word.
I don't see such a scenario described in this article, so it can be that the issue here has much less potential to be misused?
There is also a system-wide solution for all programs at once: SafeDllSearchMode registry entry.
Well, unless the application modifies the search order. But that's precisely the reason why applications should not be installed in and run from user-writable directories, like, say, your downloads folder, or Appdata.
Sure, but if you are starting elevated processes from public-writable folders, this is not a Nirsoft-specific issue. It's an issue with your own ignorance or negligence. That's not Nirsoft's problem.
I’m a bit confused - these aren’t long running tools, but are tools you use once or twice for troubleshooting. I’m trying to work out a scenario where this would be a major issue.
Wait, why does that make a difference? If an attacker can get you to run privileged malicious code once, they've won.
This seems like the Windows-land equivalent of the old GNU ldd bug - it's rare that you use ldd and rarer still that a sysadmin runs it as root on a user-provided binary, but once they do, the user can immediately escalate privileges (and use whatever means they like for persistence).
