Recent

Author Topic: Hardening application against DLL hijacking - find dll executable path  (Read 1139 times)

ArminLinder

  • Sr. Member
  • ****
  • Posts: 314
  • Keep it simple.
Any ideas how I can harden my application against DLL hiackjing (aka putting a fake dll into the dll search path so it is loaded instead of the intended dll). Specifically I am asking this regarding the two OpenSSL libraries.

I am on Windows (10/11) and Linux (Debian, Ubuntu).

The standard approach was to link statically, I guess, like described here: https://forum.lazarus.freepascal.org/index.php?topic=15712.0


Another and probably more practical approach was that my application detects that the dlls have been tampered with, and terminates/refuses to work. For this to work I'd have to find the path to the executable of the actual library code loaded by loadlibrary, calculate the hash and compare it with the known hash of the original library. Can I find the path to a dll executable after it has been loaded by the OS?

Thnx, Armin.

 

Lazarus 3.3.2 on Windows 7,10,11, Debian 10.8 "Buster", macOS Catalina, macOS BigSur, VMWare Workstation 15, Raspberry Pi

alpine

  • Hero Member
  • *****
  • Posts: 1038
I've never done this, but on Windows it must be achievable with: GetCurrentProcessId() -> OpenProcess() -> EnumProcessModules() -> GetModuleFileNameEx()
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
I suspect there might be a problem where the OS tries to reuse a DLL/shared-object which is already in memory, I have a very vague recollection of the search path being ignored and in any event the name of the library is not the full path of the file from which it was loaded.

If in any doubt at all, link security- or safety-related libraries statically.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 3946
Any ideas how I can harden my application against DLL hiackjing (aka putting a fake dll into the dll search path so it is loaded instead of the intended dll).
If you're using LoadLibrary to load the dll, the simplest way is to specify the full path to the dll in the LoadLibrary call.  That guarantees only the dll at that location  can be loaded.

HTH.


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Finding the dll is not hardening at all. It is a security risk.
Hence since about 30 years ago MS provided relocation for such code. 30 YEARS.
Trying to re-invent wheels, you usually come up with a Hexagon at best....

Most SSL libraries allow for relocation for precisely that. ;D
If they don't, don't use.

Finding the dll is easy, but using and abusing it should be difficult. And it is....
« Last Edit: June 29, 2022, 09:10:13 pm by Thaddy »
Specialize a type, not a var.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
Crutch solutions are bad anyway. There are intended ways to achieve such goals. Such as digital signing.
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Indeed, but even digital signing can be circumvented. (Although I recommend it)
PIC is more flexible. Professionally written code use more than the above tools.
« Last Edit: June 30, 2022, 09:44:22 am by Thaddy »
Specialize a type, not a var.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Finding the dll is not hardening at all. It is a security risk.
Hence since about 30 years ago MS provided relocation for such code. 30 YEARS.
Trying to re-invent wheels, you usually come up with a Hexagon at best....

Most SSL libraries allow for relocation for precisely that. ;D
If they don't, don't use.

Finding the dll is easy, but using and abusing it should be difficult. And it is....

What does relocation have to do with some adversary replacing the OpenSSL library with a different one (before the user starts the application)?

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
What does relocation have to do with some adversary replacing the OpenSSL library with a different one (before the user starts the application)?

...and I think that OP made it clear that his interest was in detecting impersonation by verifying the path/filename from which a DLL/so had been loaded.

As Thaddy points out, verifying signatures etc. is important. But at the same time I'm sure that lurking in the complexity of modern OSes is a vulnerability that relies on exchanging a properly-signed library loaded from an "improper" location with one containing malware at some point between its being opened and a particular block being loaded into application space.

So while it might be argued that what OP's doing is redundant (because such-and-such modern OS will only allow loading from a single predetermined "safe" location), it might also be possible to argue that it can't do any harm and is in fact a prudent extra safeguard.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

jamie

  • Hero Member
  • *****
  • Posts: 6090
Compile a known working dll into resource and compare it with the one provided on os or app folder?

 This can be done before the use of the dll when your app starts.
The only true wisdom is knowing you know nothing

 

TinyPortal © 2005-2018