On Thu, Jan 9, 2025 at 3:58 AM Elias Naur <mail@eliasnaur.com> wrote:
>> On Thu Jan 9, 2025 at 2:15 AM CET, Chris Waldon wrote:> > In order to avoid DLL preloading attacks, we should always load our system> > dependencies using the helper that only searches the system library path.> >> > Thanks to Mohsen Mirzakhani and Utkarsh Satya Prakash for bringing this to> > our attention.> >>> Thanks. I applied the change to package app (kernel32.dll is a system dll). Are> you sure you want EGL and GLES loaded from the system DLL directory only? What> if a program supplies its own EGL/GLES libraries along with its executable?> I *think* I remember Plato doing this.
I was actually misremembering how the custom rendering worked in
applications like Plato when I wrote this. Yes, we use this code to
load an application-provided GL implementation. Given that, hardening
this gets considerably harder. I'm inclined to rewrite the load to use
LoadLibraryEx with the LOAD_LIBRARY_REQUIRE_SIGNED_TARGET flag
discussed here [0]. This would ensure that the target DLL is at least
trusted by the system (if I understand it correctly). It would,
however, make building custom rendering applications on Windows harder
by introducing the requirement to get a valid code signature on your
custom GL implementation. There's no way to do that for free; the
signing certs cost $100/yr. Perhaps we should offer something like a
build tag or other mechanism applications can use to opt out of
enforcing signed DLLs?
I'm uncertain of the true scope of damage this DLL preloading opens us
up to. I'm sure it's application-dependent, and some applications
probably want to be really sure they aren't hijacked via DLLs. I'm
inclined to think we should do something to tighten this, but it's
hard to know what that looks like
Cheers,
Chris
[0] https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexa