
DLL hijacking vulnerabilities in Nirsoft tools - svenfaw
http://borncity.com/win/2020/04/16/dll-hijacking-vulnerabilities-in-nirsoft-tools/
======
shawnz
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.

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

~~~
Grollicus
That's why you usually provide your programs in zip files (like nirsoft seems
to do) so they decompress to their own folder.

~~~
hoistbypetard
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. ```

~~~
Grollicus
The windows zip extract dialog gives the name of the zip file as the default
target directory

~~~
hoistbypetard
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.

~~~
shawnz
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.

~~~
hoistbypetard
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.

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

------
jaclaz
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?

~~~
tinus_hn
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.

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

------
LoSboccacc
"It rather involved being on the other side of this airtight hatchway."

[https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...](https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283)

~~~
twhitmore
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.

~~~
LoSboccacc
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.

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

[0] [https://stackoverflow.com/questions/43044855/explanation-
how...](https://stackoverflow.com/questions/43044855/explanation-how-dll-
hijack-of-notepad-worked-please)

[1] [https://www.ghacks.net/2017/03/09/notepad-7-3-3-update-
fixes...](https://www.ghacks.net/2017/03/09/notepad-7-3-3-update-fixes-cia-
vulnerability/)

~~~
shawnz
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.

~~~
geofft
> _Those agencies used DLL hijacking as a convenient technique to inject code
> into Notepad++_

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.

~~~
nemetroid
> 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:

2\. Notepad++ specifically only looks for SciLexer.dll in the same directory
as the executable itself: [https://github.com/notepad-plus-plus/notepad-plus-
plus/commi...](https://github.com/notepad-plus-plus/notepad-plus-
plus/commit/3fa8a89e76bf523cc4ea7ea1a111cb5ec8f21d4c)

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

------
Havoc
I mean you’re downloading an exe and giving it admin access.

That’s already carte Blanche.

Whether any of that can be leveraged further by messing with the contents -
DLL or otherwise - is academic.

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

[https://www.fortinet.com/blog/industry-trends/a-crash-
course...](https://www.fortinet.com/blog/industry-trends/a-crash-course-in-
dll-hijacking.html)

------
eps
Too much fuss, too little substance.

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

~~~
goldenkey
Wrong. Windows dll are first looked in the folder the application is in.

~~~
ygra
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.

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

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

