Adobe's CVE-2015-5090 - Updating the Updater to become the bossman

[Abdul_Hariri]

Amongst the many bugs Adobe patched in July 2015, CVE-2015-5090 stands out as being worth a closer look. Adobe lists this vulnerability as a privilege escalation from low to medium integrity, but this doesn’t tell the whole story. In actuality, this bug can used to execute code with SYSTEM privileges, which could allow an attacker to completely take over a target. Since this affects the Adobe updater service, the bug exists in both Adobe Reader and Acrobat Pro. Both of these programs install the ARMSvc service (Updater) and both keep AdobeARM.exe/AdobeARMHelper.exe in c:\progra~1\common~1\Adobe\ARM\1.0.

Our exploit was specifically written for acrobat.exe, but it could be modified for Reader as well. Here’s a short video demonstrating the exploit.

 

Bug information:

ARMSvc.exe supports multiple user controls defined in the function HandlerProc in IDA:

 

Figure 1 – Handler function

Inside UserControls:

 Figure 2 – Controls

The interesting switch cases for this exploit are:

170 - Creates a shared memory section

179 - Executes ELEVATE which in turn runs AdobeARMHelper.exe with arguments from the Shared Memory section.

The problem with user control 170 is that it creates a SharedMemory section with weak permissions. Any user can read and write to it, meaning an attacker can control the arguments passed to AdobeARMHelper.exe.

Looking into AdobeARMHelper.exe, we find sub_42A260. This routine finds the first file in a given directory. It will then check to verify the file is signed by Adobe. If it's signed by, Adobe sub_42A260 copies the file to the directory where AdobeARM.exe resides:

 Figure 3 – Signature check

If this fails, it will bail out:

Figure 4 – Signature check failure

If it succeeds, it copies the file:

 

Figure 5 – Signature check successful

The function does NOT take into account the following items:

1. Path for the folder where the files is to be copied is not checked. An attacker can supply his own path where he wants a file to be copied.

2. When the first file is found, the file name is not checked.

3. When the first file is found, the file extension is not checked.

The function DOES check for:

1. Whether the first file found in a given directory is signed by Adobe.

Exploitation:

What we're able to do:

1. Control arguments passed to AdobeARMHelper/AdobeARM via the SM.

2. Execute AdobeARM.exe under system privileges whenever we want.

3. Overwrite AdobeARM.exe with *any* file as long as it's signed by Adobe.

What we NEED to do:

1. Have something NOT signed by Adobe get executed.

The strategy:

To exploit this bug, we need to overwrite AdobeARM.exe with something signed by Adobe, but something that would allow us to do interesting things.

For example, arh.exe is an Adobe AIR install wrapper. In theory, we can overwrite AdobeARM.exe with arh.exe (which is totally legit since it's signed), and then probably have arh.exe install an arbitrary AIR application. The only problem with this strategy is that arh.exe would not allow any extra arguments to be passed to it, so it will fail since some of the arguments passed from the SM are not directly controlled by us.

The best strategy would be overwriting AdobeARM.exe with a signed binary that won't complain when we pass extra arguments to it.

The exploit:

If we look closely at Acrobat Pro, we would notice that it contains a binary called AcrobatLauncher.exe.

This binary basically allows us to launch Acrobat.exe with a given PDF file. The nice thing about AcrobatLauncher.exe is that it ignores extra arguments and doesn't complain/bail out.

The command line argument is: AcrobatLauncher.exe -open PDF_FILE

Attack chain:

1. Trigger SM creation.

2. Write arguments to SM.

3. Trigger ELEVATE user control to copy AcrobatLauncher.exe (as AdobeARM.exe) to c:\progra~1\common~1\Adobe\ARM\1.0\AdobeARM.exe. This basically overwrites the updater.

4. Run the new AdobeARM.exe, which will execute Acrobat.exe with our PDF exploit. This step is automatically done with the ELEVATE control.

5. The PDF exploit should dump secur32.dll in c:\progra~1\common~1\Adobe\ARM\1.0. This is done using one of our JavaScript bypasses.

6. Clear the temp folder so AdobeARMHelper.exe won't copy anything from the temp folder when we call ELEVATE one more time.

7. Re-write to SM so it will execute our new AdobeARM.exe without any modifications.

8. Execute ELEVATE again which will execute AdobeARM.exe (which is in fact AcrobatLauncher.exe) with only the "-open" option which will load our secur32.dll and pop calc as SYSTEM.

As you can see, CVE-2015-5090 provides attackers a reliable method for executing code with system privileges. If you’re running either Adobe Reader or Acrobat Pro, you should definitely apply the patch that corrects this bug. Also, if you would like more details about JavaScript bypass described in Step 5, be sure to check out our upcoming DEFCON talk for more information.

We’ll see you in Vegas!