1468693 - Full display contents screenshot capture possible from sandboxed content process

Status: RESOLVED DUPLICATE of bug 1467758

(Core :: Security: Process Sandboxing, defect)

Description

[Alex Plaskett]

Attachment: takeshot.m

It is possible for a compromised sandboxed content process to construct a full screenshot of the screen (not just limited to the content processes window itself). The traditional way of doing this using CGWindowListCreateImage (https://developer.apple.com/documentation/coregraphics/1454852-cgwindowlistcreateimage) was found to be failing with an invalid return code. However an alternative approach was found which made use of different APIs in order to perform the capture which was successful (CGGetActiveDisplayList/CGDisplayCreateImage - https://developer.apple.com/documentation/coregraphics/1455691-cgdisplaycreateimage). 

A full screen capture could expose sensitive details or be used to monitor users without their knowledge. 

Proof of concept code for the issue is attached. Please note that this POC requires a development Firefox build (--enable-debug .mozbuild) in order to allow the content process to write to a debugWriteDir specified within the sandbox profile to store the screenshot on the filesystem. In a production build an attacker would also need to determine a way to exfiltrate the image bytes without performing a file system write (such as over the network).  

It is unknown at this stage if this is intentional behaviour or a Apple vendor vulnerability. Therefore it may be necessary to contact Apple to gain clarification of if this is intentional behaviour or an API which has been overlooked. Regardless of this, restricting WindowManager access from the content process should prevent this vulnerability.   

Repro Steps:

0. Ensure a Firefox debug build has been created. 

1. Download https://github.com/scen/osxinj. This tool will be used to inject a dylib into a Firefox plugin process and simulate a compromised content process. 

2. Patch osxinj/main.cpp so it uses the PID instead of the process name (i.e. pid_t pid = atoi(argv[1]);. This is to make it easier to locate the content plugin process, then rebuild the project. 

3. Patch the poc code to reflect the desired directory which the sandbox is to write to and will match with step 5. 
Currently set to :snprintf(path_str, 1023, "/Users/alex/debug/image%d.png", i); 

4. Build the attached POC code as follows:

clang takeshot.m -o takeshot.dylib -framework Foundation -framework Cocoa -dynamiclib -framework CoreGraphics -framework ApplicationServices

5. Copy the dylib to a directory allowed by the plugin-container i.e. /Applications/Firefox.app/Contents/MacOS/plugin-container.app/Contents/MacOS/takeshot.dylib

6. Set the necessary environmental variables to allow the sandbox debug output to be written to the directory specified in the POC:

export XPCOM_MEM_BLOAT_LOG=/Users/alex/debug/test.log

7. Run the Firefox debug build and locate the PID of a plugin process (./mach run).

8. Perform dylib injection into the plugin process by locating the PID for injection and the path of the dylib. 

e.g: sudo ./osxinj 640 /Applications/Firefox.app/Contents/MacOS/plugin-container.app/Contents/MacOS/takeshot.dylib

9. Observe that an image file has been created within the specified directory capturing full screen contents. Please note it creates a dot file, therefore will not be visible in Finder. 

e.g. /Users/alex/debug/.image0.png-qYiD.

Comment 1

[Alex Gaynor [:Alex_Gaynor]]

This is probably the same as https://openradar.appspot.com/radar?id=5610698700750848