Useful Info from Bitdefender for Brave on why "Private window with Tor" doesn't work when BD Advanced Threat Defense is Enabled

I’ve had a ticket open with Bitdefender about why Brave’s “New private window with Tor” doesn’t work when Bitdefender’s “Advanced Threat Defense” is enabled. Based on their explanation in the attached PDF file, it seems like maybe there’s something that Brave could be doing to alleviate the situation. Providing the info to Brave here for evaluation.

ATCSUP-8667 - ATD blocks Tor private window in Brave browser.
This is a short description of the specific interaction between Brave and Tor that can fail when small
delays are introduced in a file rename operation.
Relevant implementation details in Brave:
• chromium using ReadDirectoryChangesW in various FileWatcher/
DirectoryWatcherimplementations, which triggers a callback when a directory is changed
(including file rename)
• brave-core/components/tor/tor_file_watcher.cc at
e6c9ca8503d55da7c1cdc14c7c485b39f0171bcc · brave/brave-core
Brave monitors the C:\Users\test\AppData\Local\BraveSoftware\Brave-Browser\User Data\tor\watch
folder for changes. When its callback is called, brave tries to consume a control_auth_cookie file. If
this file is not found or opening fails, no retries are attempted, and the control_auth_cookie is never
read by brave.
Tor creates a control_auth_cookie.tmp file (with no file sharing allowed) in the monitored folder,
and then renames it to control_auth_cookie (using msvcrt rename). The handle to this file is closed
in rename. Until this handle is closed, brave cannot open control_auth_cookie with read access.
On success flows, tor closes its handle before Brave attempts to open control_auth_cookie.
When ATC introduces a small delay in the processing of the file rename operation, and Brave cannot
open control_auth_cookie anymore.
We also reproduced the issue without ATC, using a small driver that introduces a 1 ms delay in the file
rename operation.

Copy editing that PDF file writing …


ATCSUP-8667 – ATD blocks Tor private windows in Brave Browser

This document describes a specific interaction between Brave and Tor that can fail when small delays are introduced during a file rename operation.

Relevant implementation details in Brave

  • Chromium uses ReadDirectoryChangesW in various FileWatcher / DirectoryWatcher implementations to trigger callbacks whenever a directory changes, including file rename events.
  • Brave implementation: brave-core/components/tor/tor_file_watcher.cc
    Commit: e6c9ca8503d55da7c1cdc14c7c485b39f0171bcc

Brave monitors the following directory for changes:

C:\Users\test\AppData\Local\BraveSoftware\Brave-Browser\User Data\tor\watch

When the callback is triggered, Brave attempts to read the control_auth_cookie file. If the file is not found, or if opening the file fails, Brave does not retry, and the control_auth_cookie is never successfully read.

Tor creates a file named control_auth_cookie.tmp in the monitored directory with file sharing disabled. It then renames the file to control_auth_cookie using the MSVCRT rename function. The file handle is closed during the rename operation. Until the handle is closed, Brave cannot open control_auth_cookie for read access.

Under normal conditions, Tor closes the handle before Brave attempts to open control_auth_cookie, so the operation succeeds.

However, when ATC introduces a small delay during processing of the file rename operation, Brave may attempt to open control_auth_cookie before the handle has been released, causing the open operation to fail.

We also reproduced the issue without ATC by using a small driver that introduces a 1 ms delay in the file rename operation.


cc: @Mattches