README: add section for DLL injection attack mitigations

Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
This commit is contained in:
Pablo de Lara 2023-12-20 09:46:16 +00:00 committed by Tomasz Kantecki
parent 29d99fce26
commit cf967e5a37

View File

@ -76,3 +76,25 @@ Other targets include:
* `make ex` : build examples * `make ex` : build examples
* `make other` : build other utilities such as compression file tests * `make other` : build other utilities such as compression file tests
* `make doc` : build API manual * `make doc` : build API manual
DLL Injection Attack
--------------------
### Problem
The Windows OS has an insecure predefined search order and set of defaults when trying to locate a resource. If the resource location is not specified by the software, an attacker need only place a malicious version in one of the locations Windows will search, and it will be loaded instead. Although this weakness can occur with any resource, it is especially common with DLL files.
### Solutions
Applications using libisal DLL library may need to apply one of the solutions to prevent from DLL injection attack.
Two solutions are available:
- Using a Fully Qualified Path is the most secure way to load a DLL
- Signature verification of the DLL
### Resources and Solution Details
- Security remarks section of LoadLibraryEx documentation by Microsoft: <https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexa#security-remarks>
- Microsoft Dynamic Link Library Security article: <https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security>
- Hijack Execution Flow: DLL Search Order Hijacking: <https://attack.mitre.org/techniques/T1574/001>
- Hijack Execution Flow: DLL Side-Loading: <https://attack.mitre.org/techniques/T1574/002>