Vendors shipping products based on Chromium might wish to rate the severity of security issues in the products they release. This document contains guidelines for how to rate these issues. Check out our security release management page for guidance on how to release fixes based on severity.
Any significant mitigating factors will generally reduce an issue's severity by one or more levels:
Bugs that require implausible interaction, interactions a user would not realistically be convinced to perform, will generally be downgraded to a functional bug and not considered a security bug.
Conversely, we do not consider it a mitigating factor if a vulnerability applies only to a particular group of users. For instance, a Critical vulnerability is still considered Critical even if it applies only to Linux or to those users running with accessibility features enabled.
Also note that most crashes do not indicate vulnerabilities. Chromium is designed to crash in a controlled manner (e.g., with a __debugBreak) when memory is exhausted or in other exceptional circumstances.
Critical severity (S0) issues allow an attacker to read or write arbitrary resources (including but not limited to the file system, registry, network, etc.) on the underlying platform, with the user's full privileges.
They are normally assigned Priority P0 and assigned to the current stable milestone (or earliest milestone affected). For critical severity bugs, SheriffBot will automatically assign the milestone.
For critical severity (S0) vulnerabilities, we aim to deploy the patch to all Chrome users in under 30 days.
Critical vulnerability details may be made public in 60 days, in accordance with Google's general vulnerability disclosure recommendations, or faster (7 days) if there is evidence of active exploitation.
Example bugs:
Note that the individual bugs that make up the chain will have lower severity ratings.
High severity (S1) vulnerabilities allow an attacker to execute code in the context of, or otherwise impersonate other origins or read cross-origin data. Bugs which would normally be critical severity with unusual mitigating factors may be rated as high severity. For example, renderer sandbox escapes fall into this category as their impact is that of a critical severity bug, but they require the precondition of a compromised renderer. (Bugs which involve using MojoJS to trigger an exploitable browser process crash usually fall into this category). Another example are bugs that result in memory corruption in the browser process, which would normally be critical severity, but require browser shutdown or profile destruction, which would lower these issues to high severity. A bug with the precondition of browser shutdown or profile destruction should be considered to have a maximum severity of high and could potentially be reduced by other mitigating factors.
They are normally assigned Priority P1 and assigned to the current stable milestone (or earliest milestone affected). For high severity bugs, SheriffBot will automatically assign the milestone.
For high severity (S1) vulnerabilities, we aim to deploy the patch to all Chrome users in under 60 days.
Example bugs:
Medium severity (S2) bugs allow attackers to read or modify limited amounts of information, or are not harmful on their own but potentially harmful when combined with other bugs. This includes information leaks that could be useful in potential memory corruption exploits, or exposure of sensitive user information that an attacker can exfiltrate. Bugs that would normally be rated at a higher severity level with unusual mitigating factors may be rated as medium severity.
Certain vulnerabilities in sandboxed GPU shader compilers should be marked as medium severity.
They are normally assigned Priority P1 and assigned to the current stable milestone (or earliest milestone affected). If the fix seems too complicated to merge to the current stable milestone, they may be assigned to the next stable milestone.
Example bugs:
Low severity (S3) vulnerabilities are usually bugs that would normally be a higher severity, but which have extreme mitigating factors or highly limited scope.
They are normally assigned Priority P2. Milestones can be assigned to low severity bugs on a case-by-case basis, but they are not normally merged to stable or beta branches.
Example bugs:
If there is evidence of a weaponized exploit or active exploitation in the wild, the vulnerability is considered a P0 priority - regardless of the severity rating -with a SLO of 7 days or faster. Our goal is to release a fix in a Stable channel update of Chrome as soon as possible.
If the bug can't impact Chrome users by default, this is denoted instead by the Security-Impact_None hotlist (hotlistID: 5433277). See the security labels document for more information. The bug should still have a severity set according to these guidelines.
The security FAQ covers many of the cases that we do not consider to be security bugs, such as denial of service and, in particular, null pointer dereferences with consistent fixed offsets.
“MiraclePtr” is a technology designed to deterministically prevent exploitation of use-after-free bugs. Address sanitizer is aware of MiraclePtr and will report on whether a given use-after-free bug is protected or not:
MiraclePtr Status: NOT PROTECTED No raw_ptr<T> access to this region was detected prior to the crash.
or
MiraclePtr Status: PROTECTED The crash occurred while a raw_ptr<T> object containing a dangling pointer was being dereferenced. MiraclePtr should make this crash non-exploitable in regular builds.
MiraclePtr is now active on all Chrome platforms in non-renderer processes as of 118 and on Fuchsia as of 128. Severity assessments are made with consideration of all active release channels (Dev, Beta, Stable, and Extended Stable); BRP is now enabled in all active release channels.
As of 128, if a bug is marked MiraclePtr Status:PROTECTED, it is not considered a security issue. It should be converted to type:Bug and assigned to the appropriate engineering team as functional issue.
If a GPU shader compiler is in a separate process outside the GPU process and sandboxed, the overall attack surface of a vulnerability in that specific compiler may be much lower than an in-GPU-process shader compiler. Unlike the renderer process, which can make hundreds of different IPCs to the browser process, a well sandboxed shader compiler process can make a very limited number of IPCs back to the GPU process. Furthermore, code execution in a sandboxed GPU shader compiler is now limited to writing arbitrary shaders, which is a much lower threat surface than code execution in the GPU process as a whole.
Currently, only the Metal shader compiler is in its own sandboxed process, so vulnerabilities that would otherwise be high severity should be considered medium severity if they are specific to that compiler.
Vulnerabilities specific to the Metal shader compiler will typically call into the MTLCompiler in the stack trace, and a PoC will only be reproducible on MacOS devices. An example of a stack trace specific to the metal shader compiler can be found at (40074630).
| 防晒衣什么颜色最防晒 | 七月半吃什么 | 发蜡是什么 | 12月生日是什么星座 | 什么叫次日 |
| 佳偶天成是什么意思 | 半夜12点是什么时辰 | dvt是什么意思 | 为什么胸闷一吃丹参滴丸就好 | 什么是大三阳和小三阳 |
| 菠萝蜜过敏什么症状 | 欧米茄属于什么档次 | 1月出生是什么星座 | 猫字五行属什么 | 金鱼吃什么食物 |
| 刚怀孕需要注意什么 | 例假量多是什么原因 | 哲理是什么意思 | 面肌痉挛是什么原因引起的 | 冥冥中是什么意思 |
| 晗是什么意思hcv8jop4ns6r.cn | 血管瘤是什么意思qingzhougame.com | 眼睛屈光不正是什么意思hcv8jop7ns7r.cn | bp是什么意思hcv9jop8ns1r.cn | 大黄鸭是什么牌子hcv7jop7ns3r.cn |
| 回应是什么意思hcv9jop8ns0r.cn | 杜建英是宗庆后什么人hcv8jop3ns7r.cn | 忘带洗面奶用什么代替hcv8jop3ns3r.cn | 慢性结肠炎用什么药hcv9jop3ns5r.cn | 抄送和密送是什么意思hcv9jop7ns3r.cn |
| 雷诺综合征是什么病hcv8jop0ns0r.cn | tips是什么意思hcv8jop1ns1r.cn | 人工流产和无痛人流有什么区别hcv9jop1ns5r.cn | 阴道出血用什么药hcv9jop0ns9r.cn | 抑郁症看什么科hcv9jop7ns4r.cn |
| 房客是什么意思hcv8jop0ns7r.cn | 唐筛检查什么bjcbxg.com | 高知是什么意思hcv9jop0ns9r.cn | 江西有什么景点inbungee.com | 中山大学是什么级别hcv9jop0ns7r.cn |