751931 - Investigate implicitly loaded DLLs into elevated processes

Status: RESOLVED DUPLICATE of bug 752056

(Toolkit :: Application Update, defect)

Description

[Brian R. Bondy [:bbondy]]

James Forshaw wrote in bug 750850:

> ...this still doesn't fix the potential for implicit loads via loading of DLLs
> which you don't directly link against, which could change depending on what
> software a user has installed (AV being a special problem with their habit of 
> loading DLLs into all processes).

This bug is to investigate the feasibility of such an attack, how it is done, and how to protect against it.

Comment 1

[Brian R. Bondy [:bbondy]]

James do you know how a program like an antivirus could inject DLLs into a process that is run elevated to load implicitly? 

And if this is possible and they did this, wouldn't they add an absolute path to the DLL?

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

I think the program doing the injecting would need to itself have elevated (admin) rights. I'm not sure how we would specifically block this - or if we would want to.

Close invalid/incomplete?

Comment 3

[Brian R. Bondy [:bbondy]]

I think it can be closed but I just posted originally in case there is a PoC that can be built from James' original comments.

Comment 4

[James Forshaw]

Well take for example Sophos AV, which forces sophos_detoured.dll into all processes (even running as admin/system). Now it loads it by an absolute path so the DLL itself isn't a problem, but it has a dependency on psapi.dll which is not a known DLL. This means that any process (well that loads user32.dll) started under any account will always try and first load psapi.dll from the application directory (at least on XP, haven't double checked on Win7 where it does some things to protect against bad InitDLLs). Therefore when you load updater.exe on a system with sophos you could get priv escalation using a dummy psapi.dll in with updater.exe even though you don't ever directly load it. 

Of course this is their problem rather than anyone elses, but normally it isn't an issue because most system/admin processes run from secure locations. 

My point was not that it happens (it will) it was that pre-loading the DLLs you know you are using is not enough to cover all bases, as you do not know the dependencies of anything loading implicitly or explicitly into your process. Therefore I considered it a very brittle way of fixing the issue, however I do not believe this needs a separate bug open, as the way to fix it is to not run updater.exe from the untrusted location.

Comment 5

[Brian R. Bondy [:bbondy]]

Ya I think this will be covered by running updater in a secured location (probably from within the maintenance service directory).
I'll mark this as a dupe of that bug.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

James, Brian, thanks!