Bug 211446

Summary: [Cocoa] Block preference services without using CFPrefs direct mode
Product: WebKit Reporter: Per Arne Vollan <pvollan>
Component: WebKit Misc.Assignee: Per Arne Vollan <pvollan>
Status: RESOLVED INVALID    
Severity: Normal CC: benjamin, bfulgham, cdumez, cmarcelo, darin, ews-watchlist, ggaren
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch darin: review-

Per Arne Vollan
Reported 2020-05-05 07:34:26 PDT
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.
Attachments
Patch (12.52 KB, patch)
2020-05-05 07:42 PDT, Per Arne Vollan 		no flags
DetailsFormatted DiffDiff
Patch (12.14 KB, patch)
2020-05-05 08:01 PDT, Per Arne Vollan 		no flags
DetailsFormatted DiffDiff
Patch (13.96 KB, patch)
2020-05-05 09:04 PDT, Per Arne Vollan 		darin: review-
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Per Arne Vollan
Comment 1 2020-05-05 07:42:16 PDT
Created attachment 398504 [details] Patch
Per Arne Vollan
Comment 2 2020-05-05 08:01:32 PDT
Created attachment 398507 [details] Patch
Per Arne Vollan
Comment 3 2020-05-05 09:04:08 PDT
Created attachment 398516 [details] Patch
Geoffrey Garen
Comment 4 2020-05-05 10:38:29 PDT
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
Comment 5 2020-05-08 08:05:55 PDT
(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 6 2020-05-09 17:14:34 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.