1468163 - Pre-sandbox initialization communication proof of concept

Status: RESOLVED DUPLICATE of bug 1431441

(Core :: Security: Process Sandboxing, defect, P3)

Description

[Alex Plaskett]

Attachment: senddock.m

Description:

As stated in https://bugzilla.mozilla.org/show_bug.cgi?id=1389494, there are a number of open mach ports which are created before the sandbox is initialized which have a send right. This allows an attacker to send messages to these processes regardless of what the sandbox profile dictates by making use of existing ports.

As a proof of concept I have included two programs (dylibs) which if injected inside a plugin content process demonstrate this. The first of these (sendpoc.m) shows gathering all ports from memory using mach_port_names API, then looping throught the list of retrieved ports and sending a message. This POC also demonstrates resolving the WindowServer port and porting UI actions (NSAlert), which is still available within the content process due to https://bugzilla.mozilla.org/show_bug.cgi?id=1467758. 

The second POC (senddock.m) demonstrates driving the Dock process from the plugin content process. This makes use of the undocumented APIs within ApplicationServices, however, an attacker could also send raw messages to this port via mach_msg (thus exposing the attack surface of the Dock also).      

Recommendation:

It is recommended that the WindowServer connection is ensured to be terminated (https://bugzilla.mozilla.org/show_bug.cgi?id=1467758) by processes without the widevinePluginSandboxRulesAddend sandbox rules. It is also recommended that there are no send rights to the Dock process available. 

Repro steps:

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. Build either attached POC using:

clang sendpoc.m -o sendpoc.dylib -framework Foundation -framework Cocoa -dynamiclib

4. Copy the dylib to path allowed by the sandbox profile. 

e.g. /Applications/Firefox.app/Contents/MacOS/plugin-container.app/Contents/MacOS/sendpoc.dylib or senddock.dylib

5. Dump the mach ports within the plugin process space:

sudo lsmp -p 640

 -          0x130ffc77  recv,send   --------     0  ---      1     1         Y        5         0  0x0000000000000000 0x00008d0f  (640) plugin-container
0x00007007  0x114b1a17  send        --------        ---           13                                                  0x00000000  THREAD (0x36b2)
0x0000710f  0x114b2347  recv        --------     0  ---      1               N        5         0  0x0000000000000000 
0x00007217  0x13100847  recv,send   --------     0  ---      1     1         Y        5         0  0x0000000000000000 
0x00007317  0x0bf8253f  send        --------        D--            1        ->        5         0  0x0000000000000000 0x00001a03  (162) WindowServer

6. 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/sendpoc.dylib 

7. We can see in our message box output, that the port 0x7313, WindowServer port is there. 

8. Clicking ok will send a message to all the ports within the list. 

9. If we check /var/log/system.log we can also see a failed request with msgh_id from our message POC (0x3039 = 12345) going to launchservicesd (pid = 1) - which is also not part of the profile. 

May 29 10:46:41 mwrs-MacBook com.apple.xpc.launchd[1]: plugin-containe.842 sent an invalid request: msgh_bits = 0x80001112, msgh_size = 44, msgh_remote_port = 0x0, msgh_local_port = 0x38503, msgh_id = 0x3039
May 29 10:46:41 mwrs-MacBook com.apple.xpc.launchd[1]: Rejected invalid request.

10. The second POC will send a notification to the Dock.

Comment 1

[Alex Plaskett]

Attachment: sendpoc.m