Recent

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

Nimral

  • Sr. Member
  • ****
  • Posts: 251
  • 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 2.2.0 on Windows 7,10,11, Debian 10.8 "Buster", macOS Catalina, macOS BigSur, VMWare Workstation 15, Raspberry Pi

y.ivanov

  • Sr. Member
  • ****
  • Posts: 434
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: 4719
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: 2928
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 on Windows 7 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 11764
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 »
Black themes should be banned.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 764
Crutch solutions are bad anyway. There are intended ways to achieve such goals. Such as digital signing.
29.12.2021 - migration to DynamicData 4.1 is completed - complete overhaul of data access driver.
My project still requires full Delphi 2009 support to be ported to Lazarus.
It's time to finally do it, because Delphi 2009 is 13 years old.

Thaddy

  • Hero Member
  • *****
  • Posts: 11764
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 »
Black themes should be banned.

PascalDragon

  • Hero Member
  • *****
  • Posts: 4282
  • 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: 4719
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: 4667
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