SUMMARY

An extension with downloads permission can download a file:// URL by calling downloads.download(), waiting for the download to be interrupted, and then calling downloads.resume() on the interrupted download. This causes the download to be initiated by the browser, bypassing DownloadRequestUtils::IsURLSafe()/CPSP::CanRequestURL() checks.

Downloading local files is meant to be blocked when the extension does not have file:// permissions. The tabs.create() workaround to download some local files was also blocked in https://crrev.com/c/4772028 (August 2023, also see issue 40063229).

The resume bypass also works with all other ways to resume downloads, including resumes made through UI.

When chained with other bugs, such as issue 433800617 or issue 435684924, or if the attacker otherwise convinces user to upload the downloaded file, the attacker can steal the downloaded file’s contents.

VULNERABILITY DETAILS

In DownloadManagerImpl::BeginDownloadInternal()…

void DownloadManagerImpl::BeginDownloadInternal(
    std::unique_ptr<download::DownloadUrlParameters> params,
    scoped_refptr<network::SharedURLLoaderFactory> blob_url_loader_factory,
    bool is_new_download,
    const std::string& serialized_embedder_download_data) {
  // Check if the renderer is permitted to request the requested URL.
  if (params->render_process_host_id() >= 0 &&
      !DownloadRequestUtils::IsURLSafe(params->render_process_host_id(),
                                       params->url())) {
    CreateInterruptedDownload(
        std::move(params),
        download::DOWNLOAD_INTERRUPT_REASON_NETWORK_INVALID_REQUEST,
        weak_factory_.GetWeakPtr());
    return;
  }
  // ...
}

…CPSP::CanRequestURL() is called through DownloadRequestUtils::IsURLSafe() only if render_process_host_id() >= 0.

When downloads.download() is called with a file:// URL, render_process_host_id is greater than zero, and CPSP::CanRequestURL() returns false for file:// URLs, therefore the download is interrupted.

However, when downloads.resume() is called for the interrupted download, render_process_host_id is -1, which per this comment means it’s not associated with a frame. This means the IsURLSafe()/CPSP::CanRequestURL() check is bypassed, and the file is downloaded.

Additional context

In the DownloadUrlParameters() constructor that leaves render_process_host_id at -1, there is this comment that points out the security checks bypass:

  // Constructs a download not associated with a frame.
  //
  // It is not safe to have downloads not associated with a frame and
  // this should only be done in a limited set of cases where the download URL
  // has been previously vetted. A download that's initiated without
  // associating it with a frame don't receive the same security checks
  // as a request that's associated with one. Hence, downloads that are not
  // associated with a frame should only be made for URLs that are either
  // trusted or URLs that have previously been successfully issued using a
  // non-privileged frame.
  DownloadUrlParameters(
      const GURL& url,
      const net::NetworkTrafficAnnotationTag& traffic_annotation);

Unfortunately, this constructor is used in the downloads.resume() code path and most other download resume code paths: DownloadsResumeFunction::Run() calls DownloadItem::Resume() which calls DownloadItemImpl::ResumeInterruptedDownload().

ResumeInterruptedDownload() has this comment explaining why the unsafe constructor is used for resumes:

  // Avoid using the WebContents even if it's still around. Resumption requests
  // are consistently routed through the no-renderer code paths so that the
  // request will not be dropped if the WebContents (and by extension, the
  // associated renderer) goes away before a response is received.
  std::unique_ptr<DownloadUrlParameters> download_params(
      new DownloadUrlParameters(GetURL(), traffic_annotation));

BISECT

Likely commit 00b621f5126d538df488090c19175ee892a7161b (February 2016) which starts using the unsafe constructor in resume code path.

I’ll verify bisect later today.

VERSION

Chrome version: 139.0.7258.67 Stable, 141.0.7340.0 Canary

Operating System: Windows 10

REPRODUCTION CASE

To download a file in a user directory, the PoC first makes a throwaway download to get the username from the download path. Then we make the second download exploiting the vulnerability.

The core vulnerability itself doesn’t need user interaction to download the file, nor does it need to show an extension page or otherwise open a new tab.

I’ll upload chained scenarios in comments.

Setup:

1. Install attached extension: manifest.json, background.js, page.html, page.js.
2. Disable file:// URL access in the extension details page (this is enabled by default for unpacked extensions).

Scenario 1: Chrome history file

1. Click extension icon to trigger download. (Note: Initiating/resuming downloads doesn’t require user interaction, so this step is only for PoC.)
2. Click the page, then select the downloaded file. (Note: When chained, we don’t need user to explicitly upload file.)

Observed: Extension can download file:// URLs without file permission. When chained with other vulns, or through social engineering, user can read downloaded local file.

Expected: Extension cannot download file:// URLs without file permission.

Debug scenario

To see the attack occurring more slowly, you can modify background.js and set debug to true, which delays the resume() call by two seconds. Reminder: Disable file:// access in extension for proper repro.

Credit Information

Reporter credit: Alesandro Ortiz https://AlesandroOrtiz.com