Bug 211446 – [Cocoa] Block preference services without using CFPrefs direct mode

• Component: WebKit Misc.
• Status: RESOLVED INVALID

[Per Arne Vollan]

Initially, preference services were blocked by using CFPrefs direct mode. However, it is possible to keep denying preference services without using direct mode by issuing temporary extensions to preference services. On startup of the WebContent process, consume these extensions, then perform a dummy preference request to map preferences into memory, and finally revoke the extensions. The WebContent process will then have read access to preferences through the mapped memory region without having access to the preference services. Also preference updates will be reflected in the WebContent process, since the memory region will contain the updated value of preferences. There is no longer any need to push preference values from the UI process.

[Per Arne Vollan]

Created attachment 398504 [details]
Patch

[Per Arne Vollan]

Created attachment 398507 [details]
Patch

[Per Arne Vollan]

Created attachment 398516 [details]
Patch

[Geoffrey Garen]

Comment on attachment 398516 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=398516&action=review

> Source/WebKit/ChangeLog:10
> +        Initially, preference services were blocked by using CFPrefs direct mode. However, it is possible to keep denying preference services
> +        without using direct mode by issuing temporary extensions to preference services. On startup of the WebContent process, consume these
> +        extensions, then perform a dummy preference request to map preferences into memory, and finally revoke the extensions. The WebContent

How does revoking the extension achieve our security goal? 

My understanding is that, if we consume a sandbox extension to "com.apple.cfprefsd.agent" and "com.apple.cfprefsd.daemon", and then connect to them, and then revoke the extension, we will end up with an open connection to these daemons. If so, revoking the extensions will prevent new connections from being made, but will not close the existing connections, which can still be used to send malicious messages.

> Source/WebKit/ChangeLog:16
> +        No new tests, covered by existing API tests in PreferenceChanges.mm.

How does this approach handle preference change notifications?

> Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:207
> +        // Make a dummy CFPrefs request to map preferences into memory
> +        CFPreferencesCopyAppValue(CFSTR("AppleLanguages"), CFSTR("kCFPreferencesAnyApplication"));

How does this read of the AppleLanguages preference enable access to the other preferences we might need?

[Per Arne Vollan]

(In reply to Geoffrey Garen from comment #4)
> Comment on attachment 398516 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=398516&action=review
> 
> > Source/WebKit/ChangeLog:10
> > +        Initially, preference services were blocked by using CFPrefs direct mode. However, it is possible to keep denying preference services
> > +        without using direct mode by issuing temporary extensions to preference services. On startup of the WebContent process, consume these
> > +        extensions, then perform a dummy preference request to map preferences into memory, and finally revoke the extensions. The WebContent
> 
> How does revoking the extension achieve our security goal? 
> 
> My understanding is that, if we consume a sandbox extension to
> "com.apple.cfprefsd.agent" and "com.apple.cfprefsd.daemon", and then connect
> to them, and then revoke the extension, we will end up with an open
> connection to these daemons. If so, revoking the extensions will prevent new
> connections from being made, but will not close the existing connections,
> which can still be used to send malicious messages.
> 

Ah, good catch! This patch is invalid, then.

[Darin Adler]

Comment on attachment 398516 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=398516&action=review

>>> Source/WebKit/ChangeLog:10
>>> +        extensions, then perform a dummy preference request to map preferences into memory, and finally revoke the extensions. The WebContent
>> 
>> How does revoking the extension achieve our security goal? 
>> 
>> My understanding is that, if we consume a sandbox extension to "com.apple.cfprefsd.agent" and "com.apple.cfprefsd.daemon", and then connect to them, and then revoke the extension, we will end up with an open connection to these daemons. If so, revoking the extensions will prevent new connections from being made, but will not close the existing connections, which can still be used to send malicious messages.
> 
> Ah, good catch! This patch is invalid, then.

Setting review- based on this exchange.