Debugging Chromium

This content originally appeared on text/plain and was authored by ericlaw

A customer recently complained that after changing the Windows Security Zone Zone configuration to Disable launching apps and unsafe files:

… trying to right-click and “Save As” on a Text file loaded in Chrome fails in a weird way. Specifically, Chrome’s download manager claims it saved the file (with an incorrect size):

However, if you click on the entry, Chrome notices that the file doesn’t exist:

Weird, right?

I previously mentioned a closely-related scenario in my blog post on how Security Zones still impact modern browsers:

if you’ve configured the setting Launching applications and unsafe files to Disable in your Internet Control Panel’s Security tab, Chromium will block executable file downloads with a note: Couldn't download - Blocked.

…but this case here is somewhat different than that.

The customer claims that it is a regression, so let’s bisect.

python3 tools/bisect-builds.py -a win -g 1324255 -b 1589604 --verify-range -- --no-first-run https://webdbg.com/dl/txt.txt

Bisecting, we find that it is indeed a behavior change. Chrome 130 didn’t have this problem. The bisect process tells us:

You are probably looking for a change made after 1366085 (known good), but no later than 1366127 (first known bad)
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/8c10e43000483bdc4a1b5bf092b39266597d3fc8..ac84b1ec75f49a771ad490760cdaf8872aae8a29

42 changelists is a pretty wide range, so let’s try the Win64 version to see if we can narrow either side:

python3 tools/bisect-builds.py -a win64 -g 1366500 -b 1366250 --verify-range -- --no-first-run https://webdbg.com/dl/txt.txt

You are probably looking for a change made after 1366107 (known good), but no later than 1366146 (first known bad).

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/f3063c6a843ccf316d31f9169972b1ae546945b2..5f8917fb6721c1fd070cfccf45fa2ba44a8d0253 

Okay, so if we take the tightest constraints, we end up with a narrower range of 1366107 to 1366127, which is only 20 CLs.

Within that range, only one CL (1366109) appears to have anything to do with downloads. I quickly clicked through the others just to be sure.

Looking at the code of the 1366109 change, we don’t see anything directly related to the Save As scenario.

Neat. I like mysteries. If we follow Sherlock Holmes’ quote: “When you have eliminated the impossible, whatever remains, however improbable, must be the truth” we conclude that the CL in question must be responsible. But how could it be?

Well, this looks mildly interesting:

The code was changed to allow a parallel process to delete the file where that would not have been allowed previously. But still, what would delete the temp file in the middle of the overall download process?

Spoiler Alert: The answer turns out to be the Windows code called to apply the Mark-of-the-Web by the Chromium quarantine code!

If we fire up SysInternals’ Process Monitor against the current version of Chrome, we see that what’s happening is that the downloaded file created in the temp folder (before moved/renamed to its final name) is deleted by CAttachmentServices code when it is called by Chrome’s QuarantineFile function:

In contrast, in the older build of Chrome, we see that the temporary file cannot be deleted because the code that tries to delete it hits a SHARING_VIOLATION, since Chrome’s handle to the file didn’t offer SHARE_DELETE:

So… neat. It was basically an accident that this file could be saved in older Chrome.

Now, with all that said, we’re left with even more questions. For example, you’ll see that if you try to download a dangerous file type via a normal download when the Zone settings are configured as above, the download is blocked:

… but if you try to download our text file via the regular file download flow, it’s allowed:

So how can it be that if you try to perform a Save As on that same text file, it’s somehow blocked? What’s up with that? Chrome’s quarantine code runs on both files!

The secret is how the Windows Attachment Manager code decides whether a file is dangerous during the CAttachmentServices::Save call. Windows’ attachment manager has to rely on the file’s extension to decide whether the type is dangerous. In the “Save As” case, the file’s extension is .tmp, whereas in the regular download manager case, the file has the correct and final extension (.txt).

Chrome’s quarantine code correctly notes that the call is supposed to happen on the final filename:

You can confirm that the .tmp extension is indeed causing the problem by using the registry to temporarily declare that .tmp is a low-risk file extension:

After you make this change, the Save As scenario works correctly.

I’ve filed a bug on Chrome’s SaveAs code to ensure that the file has the correct filename before the quarantine logic runs.

This content originally appeared on text/plain and was authored by ericlaw