upvote
Video by GN has a little bit of info (but not a lot). Basically they made it so that the pipes only accept input from MSI signed software + the pipes can only invoke MSI signed executables.

https://youtu.be/Eck8NnoaD4M

reply
> pipes only accept input from MSI signed software

This does not inspire confidence. I'm assuming the pipe exists so that some GUI process running as the current user can perform privileged actions since the other end of the pipe runs as SYSTEM. At this point, just inject a thread into that GUI process and send the command - the service will think it is coming from MSI software, because it is.

The "only invoke MSI signed executables" mitigation is a good one, but if these two things are all they have done, while leaving the "arbitrary registry write" primitive in, then this is still 100% vulnerable to local privilege escalation.

reply
I don’t think “only invoke MSI signed executables” inspires confidence either. There’s ought to be an MSI signed executable that launches arbitrary executables by design and defeats the mitigation.

The author got around a similar mitigation in their exploit for ASUS DriverHub (linked in the original article).

reply
Oh right, yes, either that, or one of them is bound to have a DLL hijack issue that can be taken advantage of.
reply
Or just a TOCTOU race :)
reply
> At this point, just inject a thread into that GUI process and send the command

Can you or someone else expand on that?

reply
Sure. On Windows, you can allocate memory into an arbitrary process’s address space with VirtualAllocEx, write arbitrary code into those allocated pages using WriteProcessMemory, and start a thread there with CreateRemoteThread.

Now, of course you can’t do this for every process, or it would be trivial to escalate privileges. But I’m pretty sure you can do this for child processes running as the same user.

reply
Yep. There's a system of ACLs and integrity levels which determine whether you're allowed to do this or not (doesn't have to be a child process), but for the most common case:

* a process running at medium integrity level with the current user's token

* another medium integrity process with the same token can open it with PROCESS_CREATE_THREAD and PROCESS_VM_WRITE rights

reply
More likely MSI just being MSI. They're infamous for being far more concerned about image than most vendors so don't expect much info.
reply