Protect in-memory policy values from modification |
||||
Issue descriptionCustomer requests that we provide some level of protection for URLBlacklist/Whitelist policies in memory, to protect them from users using memory/process inspection tools from modifying them. Scenario from chromium-dev email: Windows Firewall blocks outbound by default, with Chrome as an exception. Chrome has a URL whitelist applied by GPO. In this scenario, the machine offers a completely secure browsing environment for normal (non-admin) users. However, those same normal, non-admin users can run said tools to modify Chrome in memory. No abnormal rights are required to do this. The only mitigation here (if Chrome can't protect itself from memory hacking) is resorting to something like AppLocker policies. But these are a pain because it would either involve numerous Publisher and Hash rules to block all the memory hacking tools, or even more painfully, a whitelist-only AppLocker mode. Not sure if Proteus folks have some thoughts here - I suspect that other policies (beyond just URLBlacklist/Whitelist) might benefit from similar protection. Adding georgesak/dskaram to prioritize.
,
May 31 2016
Wouldn't it still be possible to inject a DLL into the browser process? Such a DLL could conceivably use Chrome's own exports to override the whitelist or sidestep any obfuscation we put in place anyway.
,
May 31 2016
Wouldn't DLL injection require full access to the Chrome folder? Which in a normal install is in C:\Program Files, not writable by a standard user? I'm not talking about bespoke Chrome hacking here, but merely standard hacking tools like HxD, ProcessHacker, Cheat Engine. None of the authors are targeting Chrome specifically, but their tools make it very trivial to bypass the URL whitelisting / blacklisting features. That's why I don't believe there'd be an 'arms race' either - no one cares enough to author Chrome hacking tools, but end users DO care enough to spend two minutes making use of what already exists.
,
May 31 2016
,
May 31 2016
Any application running at the same privilege level to Chrome can do anything it wants with the system including but no limited to, injecting code into the Chrome browser process, modifying/reading user data on the system. This is a physically local attack and specifically excluded from Chrome's security model: https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-
,
Nov 10 2016
,
Nov 13 2017
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||
►
Sign in to add a comment |
||||
Comment 1 by pkasting@chromium.org
, May 31 2016