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 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.
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.
Readit News
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).
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.
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?
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).
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
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.
[0] https://stackoverflow.com/questions/43044855/explanation-how...
[1] https://www.ghacks.net/2017/03/09/notepad-7-3-3-update-fixes...
From the linked posts, it was rather not convenient at all.
> they could have just as easily accomplished the same thing by replacing the binary with a malicious one instead
From the linked posts, they were going via a shared downloads directory, so they could not have.
Occam's Razor implies there was actually something to the attack and it wasn't that some bored attacker took the long way around for fun.
That’s already carte Blanche.
Whether any of that can be leveraged further by messing with the contents - DLL or otherwise - is academic.
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.
https://www.fortinet.com/blog/industry-trends/a-crash-course...
> It is sufficient for the Malware to place DLLs with the expected names in the relevant folder.
That "relevant folder" is a system directory (like c:\windows) that requires admin rights to modify.