You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using andlabs/ui which is loading GTK and Cairo - all static compiled into the binary. But it loads dynamically other DLLs like write DWrite.dll or UxTheme.dll etc.
These are loaded with relative paths - so before the trivrost.exe is even loaded, it tries to find them in the current directory as well. This allows DLL dependency injection if a malicious DLL is placed there.
This is usually not the case, even in the Download directory, people to not download random DLLs. But this is still not nice.
Since this code runs before our init() or main(), we cannot change the DLL Search Path or do anything about it. Windows Manifests allow doing things with assemblies, but not simple DLLs. At least we were not able to find anything to control the DLL loading.
We exhausted all options except:
Using a wrapper to unpack trivrost into a clean temporary directory and run it from there if it is not at it's final path. Will cause a lot of new access problems. Rather ugly/complicated approach
Do not use andlabs/ui anymore but a UI library that does not load DLLs like this.
If anyone has any other idea, I'd be more than happy to hear!
The text was updated successfully, but these errors were encountered:
We are using andlabs/ui which is loading GTK and Cairo - all static compiled into the binary. But it loads dynamically other DLLs like write DWrite.dll or UxTheme.dll etc.
These are loaded with relative paths - so before the trivrost.exe is even loaded, it tries to find them in the current directory as well. This allows DLL dependency injection if a malicious DLL is placed there.
This is usually not the case, even in the Download directory, people to not download random DLLs. But this is still not nice.
Since this code runs before our init() or main(), we cannot change the DLL Search Path or do anything about it. Windows Manifests allow doing things with assemblies, but not simple DLLs. At least we were not able to find anything to control the DLL loading.
We exhausted all options except:
If anyone has any other idea, I'd be more than happy to hear!
The text was updated successfully, but these errors were encountered: