4 ms·
I wish the author went into a bit more detail about how MSI fixed it, as is usual in write ups like this. It left me thinking maybe the patch introduced a diff
by drdexebtjl 4mo ago
I wish the author went into a bit more detail about how MSI fixed it, as is usual in write ups like this.
It left me thinking maybe the patch introduced a different vulnerability that’s still under an embargo :)
- KennyBlanken 4mo agoMore likely MSI just being MSI. They're infamous for being far more concerned about image than most vendors so don't expect much info.
- ashikns 4mo agoVideo 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 https://youtu.be/Eck8NnoaD4M
- everyflavourvms 4mo ago> 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.
- drdexebtjl 4mo agoI 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).
- everyflavourvms 4mo agoOh right, yes, either that, or one of them is bound to have a DLL hijack issue that can be taken advantage of.
- drdexebtjl 4mo agoOr just a TOCTOU race :)
- basilikum 4mo ago> At this point, just inject a thread into that GUI process and send the command Can you or someone else expand on that?
- drdexebtjl 4mo agoSure. 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.
- everyflavourvms 4mo agoYep. 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