Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential Use-After-Free (UAF) vulnerability exists in the browser process of Chromium within the developerPrivate.updateExtensionConfiguration API. Modifying certain configuration options (like file access or incognito access) synchronously reloads the extension, destroying the heap-allocated Extension object. Subsequent operations in the same execution path then dereference the now-dangling raw pointer.

Affected files:

• chrome/browser/extensions/api/developer_private/developer_private_functions.cc

Estimated timestamp from git blame: 2015-03-19

Detailed Description

Within DeveloperPrivateUpdateExtensionConfigurationFunction::Run() (chrome/browser/extensions/api/developer_private/developer_private_functions.cc), a raw pointer to the target Extension is obtained and stored on the stack:

const Extension* extension = GetExtensionById(update.extension_id);

No scoped_refptr is taken to keep the Extension object alive during the function’s execution.

When the configuration update contains a change to file_access (line 634) or incognito_access (line 638), the function invokes helper methods that synchronously trigger an extension reload:

• util::SetAllowFileAccess(...) -> ReloadExtension(...)
• util::SetIsIncognitoEnabled(...) -> ReloadExtensionIfEnabled(...)

For a packed extension (e.g., a Web Store CRX), the reload flow is entirely synchronous:

1. ExtensionRegistrar::DoReloadExtension disables the extension, moving the scoped_refptr reference to the disabled_extensions_ set.
2. ChromeExtensionRegistrarDelegate::LoadExtensionForReload calls InstalledLoader(profile_).Load(...) synchronously using cached in-memory manifest data.
3. This constructs a brand-new Extension object on the heap and adds it via ExtensionRegistrar::AddExtension.
4. ReplaceReloadedExtension executes registry_->RemoveDisabled(extension->id()), which drops the final reference to the old Extension object, destroying it synchronously.

When control returns to DeveloperPrivateUpdateExtensionConfigurationFunction::Run(), the stack-local extension pointer is dangling. Any subsequent configuration fields present in the same update request (such as user_scripts_access, error_collection, or host_access) will dereference this freed pointer. Most notably, constructing the ScriptingPermissionsModifier on line 659:

ScriptingPermissionsModifier modifier(browser_context(), extension);

creates a temporary scoped_refptr from the dangling raw pointer. This results in an AddRef() operation on freed memory, followed by a Release() on scope exit, potentially leading to a double-free or arbitrary destructor execution.

Potential Steps to Trigger the Vulnerability

Note: Our tooling does not currently have the capability to execute code or run dynamic proofs of concept. The following steps are theoretical and based on manual analysis of the static code flow.

1. A victim user must have one of seven deprecated platform apps (such as the Chrome Dev Editor, ID AE27D69DBE571F4B1694F05C89B710C646792231) and any packed extension installed.
2. An attacker compromises the renderer process hosting the allowlisted developer app.
3. The compromised renderer dispatches a LocalFrameHost.Request Mojo message calling developerPrivate.updateExtensionConfiguration with user_gesture = true, target extension_id, and both file_access and incognito_access toggles set to values that differ from current settings.
4. In the browser process, Run() executes, reloads the extension synchronously via the first configuration handler, and frees the old Extension heap allocation.
5. The execution proceeds to the next handlers within the same task, dereferencing the dangling pointer and triggering the Use-After-Free condition.

Limitations on Exploitation

1. Task Boundary Constraints: Because the reload and subsequent dereferences occur entirely synchronously within a single UI thread task, the browser does not return to the message loop. Consequently, Mojo message queues cannot be processed in the interim, making it extremely difficult to reliably race and reclaim the freed heap allocation with controlled bytes before the UAF occurs.
2. Strict Preconditions: The API is restricted to chrome://extensions (WebUI, which is trusted) and seven hard-coded developer platform apps which are deprecated and generally inactive.

Suggested Fix

To prevent the UAF, copy the ExtensionId of the target extension and hold a scoped_refptr<const Extension> on the stack, or re-fetch the pointer from the ExtensionRegistry if any operation that can trigger an extension reload has been executed.

Evaluated with Chrome root at commit: d8b226a3be7c9c1ac9240c09e14698866c82e4ac

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.