Closed Bug 1468693 Opened 6 years ago Closed 6 years ago

Full display contents screenshot capture possible from sandboxed content process

Categories

(Core :: Security: Process Sandboxing, defect)

Unspecified
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1467758

People

(Reporter: alex.plaskett, Unassigned)

References

Details

(Keywords: csectype-disclosure, sec-vector)

Attachments

(1 file)

Attached file takeshot.m (deleted) —
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.
Group: core-security → dom-core-security
OS: Unspecified → Mac OS X
Depends on: 1426100
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: