Another Privilege Escalation ( FileWrite eop) in AMD User Experience Program Launcher from Radeon Software (CVE-2020-8950)

Version: AMD User Experience Program Launcher  1.0.0.1 (latest)
Operating System tested on: Windows 10 1909 (x64)
Vulnerability: RAMD User Experience Program Launcher from Radeon Software Local Privilege Escalation through insecure file move

In previous blog post, old version which I don't know (becoz I forgot to snap/check)  AMD User Experience Program Launcher service can get LPE. But, when I updated Radeon Software , it's also update and can't access fullcontrol the folder "C:\ProgramData\AMD\PPC" by buildin users And previous eop technique doesn't work.

Then, I try to escape again on that lpe bug.  So, I check again not to miss out the processes of that service on process monitor (procmon). But I noticed that buildin users can still have write access on that 3 folder .

Previous blog post's lpe technique doesn't work because of I can't control send folder with fullcontrol access. And even there is no file in "send" folder "C:\ProgramData\AMD\PPC\send"
and even I can symlink , *.gz file write in send folder have not fully access with buildin users.

So, I try to escape on that bug with other techniques.  Then, I checked the processes of amd service by creating a file in *upload* folder "C:\ProgramData\AMD\PPC\upload" and restart the service.

Ah ! I found interested processes again at procmon which is when I create a file in *upload* folder "C:\ProgramData\AMD\PPC\upload",  a file "C:\ProgramData\AMD\PPC\upload\hello123.txt" which I created is moved (SetRenameInformationFile) to *temp* folder as "C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_hello123.txt" and change gz file "C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_hello123.txt.gz". Then, moved again temp folder from "send" folder "C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_hello123.txt.gz" . Flow like below :

Files operation flow: 

C:\ProgramData\AMD\PPC\upload\hello123.txt   (created file)
C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_hello123.txt  (moved file from upload)
C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_hello123.txt.gz (changed to *.gz )
C:\ProgramData\AMD\PPC\send\A39F24CA-A49E-43E1-B078-2FE6809835F2_hello123.txt.gz  (moved from temp) 

Then, I want to define this keyword "A39F24CA-A49E-43E1-B078-2FE6809835F2"  which is dynamic or  static. So, I created another 3 files as 1.txt, 2.txt, 3.txt  into upload folder "C:\ProgramData\AMD\PPC\upload"  then checked the processes again.

And I found the processes which I want to define. It's static keyword "A39F24CA-A49E-43E1-B078-2FE6809835F2" (Base on PC). You can check or define by creating a file in upload and then checking *send* folder  .  C:\>dir  C:\ProgramData\AMD\PPC\send  . Thus, if I created a filename as  "evil.txt" in *upload* folder "C:\ProgramData\AMD\PPC\upload\evil.txt", it's will move to *temp* folder as C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_evil.txt .  It's interesting.

So, I checked the permission of file from "temp" folder  "C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_hello123.txt"  by holding with SetOpLock.exe  of James Forshaw (@tiraniddo) .

I noticed the permission of file "from" temp folder.  "localhost\user  Allow FullControl" . This mean,  the permission of the user who created in *upload* folder with FullControl access.

Example.
if you created the file in *upload* folder "C:\ProgramData\AMD\PPC\upload" with localhost\testuser ,  the permission of file from *temp* folder "C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_hello123.txt" will be "localhost\testuser  Allow FullControl".

Then, I tried to exploit it by creating symboliclink the file from *temp* folder.

POC:
I created a file in upload folder as evil_test.txt  and it'll move to temp folder as C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_evil_test.txt  . Then , I create symlink on "C:\ProgramData\AMD\PPC\temp\A39F24CA-A49E-43E1-B078-2FE6809835F2_evil_test.txt " to point "C:\windows\system32\evil_filewrited.txt" which doesn't default exist in system32 folder.

Then I restart the service (or reboot) and I found that evil_filewrited.txt has been created in system32 folder.

And I checked the permission of that file which can be modified or not.  Ah ,  permission of created file in system32 folder "C:\windows\system32\evil_filewrited.txt" is "localhost\testuser Allow FullControl" access. This mean like, the permission of created file who created with localhost\testuser access in "upload" folder. So , "C:\windows\system32\evil_filewrited.txt"  will get fullcontrol accessed by file creator in *upload* folder. 

On the other hand of exploit technique,
if I create a file with file data, example:
echo  pwned >  C:\ProgramData\AMD\PPC\upload\hello123.txt 
then create symlink on system32 folder and when I check the file from system32 folder
more "C:\windows\system32\evil_filewrited.txt"
pwned

I saw the data from the file hello123.txt which I created in upload folder. And also I can modify that file with fullcontrol access.

So, I created another lpe exploit poc script for this by using @itm4n's UsoDllLoader  as a privileged filewrite weapon to get system shell.
my poc script:  https://github.com/sailay1996/amd_eop_poc

B00M !!!

logic bugs are fun.
happy hunting.

you can look up here if you're interested in hunting logical bugs.
https://github.com/sailay1996/awesome_windows_logical_bugs