Chromium

The "potentially dangerous extension" prompt is determined by this function, right?

If so, I do feel like being able to bypass it for DANGEROUS file types is pretty dangerous. We currently only have three file types in that category: dll, scf, and ini. They're classified as DANGEROUS because they can negatively impact the user without the user ever opening the file (e.g. DLL hijacking attacks). I would definitely support restrictions on this very small set of file types, even if the UX is a little surprising.

I'm not convinced it's much of a security bug to be able to bypass it for ALLOW_ON_USER_GESTURE file types. That's a much broader category of file types, and in practice, users tend to bypass these warnings fairly often for regular downloads. I don't know that the value of a warning outweighs the cost of this prompt coming out of nowhere.

estark@ and I chatted and I'm talking this through with my team.

My general feeling is still well represented by #comment17. I don't have any concern about .exe/.bat writes, since FSA gives strictly more protection than regular downloads there. For regular downloads, any user gesture could trigger a download which is then checked with Safe Browsing and no additional prompting is done (if its safe). For FSA, the user explicitly consented to something being written to disk. We also check with Safe Browsing for FSA.

The only remaining thing is that I'm a little torn on things like DLL/INI. The considerations are:

• DLL hijacking means the user could be harmed without every opening the file.
• INI (if I recall correctly) can leak an NTLM hash just by being shown in Explorer.
• On regular downloads, we show a soft warning about these downloads so they aren't on disk without explicit user consent
• For FSA, we do have the directory permission prompt, but that's far less explicit about it being a DLL/INI written to disk
• FSA does protect against directory write permission to a "sensitive" directory, which mitigates DLL a lot.

If anyone has thoughts on the balance of these, feel free to chime in. Otherwise my team's security UX folks can try to figure it out.

Project: chromium/src
Branch: main
Author: Nathan Memmott <memmott@chromium.org>
Link:      https://chromium-review.googlesource.com/5875189

[FSA] Check for DANGEROUS extension types when creating a new file.

[FSA] Check for DANGEROUS extension types when creating a new file.

FSA API already checks for safe_browsing::DownloadFileType::DangerLevel
on showSaveFilePicker(), but not on handle.getFileHandle().
This change aligns these two cases, with an exception of ".local" files,
per the existing comment on local files affecting its own directory,
and that the directory already has permission, hence okay to allow.

Bug: 40062534
Change-Id: I695dce1dfc68cf5f2518172d4e63aada074588fe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5875189
Commit-Queue: Nathan Memmott <memmott@chromium.org>
Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1363763}

Dear owner, thanks for fixing this bug. We've reopened it because security bugs need the Severity (S0-S3) and the Found In set, which will enable the bots to request merges to the correct branches ( as well as helping out our vulnerability reward and CVE processes). Please consult with any Chrome security contact (security@chromium.org) to arrange to set these labels and then this bug can be marked closed again. Thank you! Severity guidelines: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/severity-guidelines.md#severity-guidelines-for-security-issues FoundIn guidelines: https://chromium.googlesource.com/chromium/src/+/main/docs/security/security-labels.md#labels-relevant-for-any-type_bug_security Thanks for your time!

Hello, as always, reward decisions will be updated on the bug after a VRP decision panel has been made. This is in the queue for a reward decision. As rewards are decided in order of severity, it may be a bit more time before we get to this one.

CVEs are issued when a fix for a security bug ships in a Stable channel update of Chrome. This fix landed in 131, so this fix should ship in the M131 Stable channel release of Chrome. https://chromium.googlesource.com/chromium/src/+/main/docs/security/vrp-faq.md#will-i-receive-a-cve-for-my-bug

We did not meet last week due to many of us being out of office. Additionally, bugs are assessed in order of severity so it may be some more weeks until we get to this issue. As always bugs will be updated directly with the reward decision once that has occurred. Thank you for your patience.

Congratulations Ameen! Thank you for your efforts and reporting this issue to us.

Hello,

Can i get to know what are all the places my name is acknowledged.(kindly share the links too)

You are acknowledged in the Chrome Stable release notes in the release version the fix for the issue you reported ships. In this case, it's: https://chromereleases.googleblog.com/2024/11/stable-channel-update-for-desktop_12.html

also is this included in google hall of fame too?

The Google HoF no longer exists. There is the Bughunters (https://bughunters.google.com/leaderboard) leaderboard and honorable mentions lists. To be included on these you need to have a bughunters profile.

inaddition to this, should i have to wait for a mail from p2p-vrp(how long will it take) or I have to sent mail?

As explained above in c#34, p2p-vrp will process your payment or reach out to you, if needed. It will not be immediately however, and may a day or two.

Your profile must be public. Please check the status of your profile. If this issue persists, please reach out to bughunters-feedback@google.com

This bug has been closed for more than 14 weeks. Removing issue access restrictions.