diff --git a/cpe/src/lib.rs b/cpe/src/lib.rs index 59f361f..a0e962d 100644 --- a/cpe/src/lib.rs +++ b/cpe/src/lib.rs @@ -1,3 +1,4 @@ +#![doc(html_root_url = "https://docs.rs/nvd-rs/0.0.1")] // Package wfn provides a representation, bindings and matching of the Well-Formed CPE names as per // https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf and // https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7696.pdf diff --git a/cve/src/lib.rs b/cve/src/lib.rs index 46d8180..6852005 100644 --- a/cve/src/lib.rs +++ b/cve/src/lib.rs @@ -1,3 +1,4 @@ +#![doc(html_root_url = "https://docs.rs/nvd-rs/0.0.1")] pub mod cve; pub mod error; pub mod node; diff --git a/cvss/src/error.rs b/cvss/src/error.rs index f331e89..5486914 100644 --- a/cvss/src/error.rs +++ b/cvss/src/error.rs @@ -13,8 +13,6 @@ pub enum CVSSError { #[error("invalid prefix for `{value}`")] InvalidPrefix { value: String }, - #[error("Invalid CVE type `{value}`")] - InvalidCveType { value: String }, #[error("Invalid CVSS `{value}` at {scope}")] InvalidCVSS { value: String, scope: String }, #[error("invalid cvss version `{value}` ({expected})")] diff --git a/cvss/src/lib.rs b/cvss/src/lib.rs index a17844f..85df6ee 100644 --- a/cvss/src/lib.rs +++ b/cvss/src/lib.rs @@ -1,3 +1,4 @@ +#![doc(html_root_url = "https://docs.rs/nvd-rs/0.0.1")] // 通用漏洞评分系统 // https://csrc.nist.gov/schema/nvd/feed/1.1-Beta/cvss-v3.x_beta.json // https://www.first.org/cvss/specification-document diff --git a/cvss/src/metric.rs b/cvss/src/metric.rs index 8292054..2f8a1f3 100644 --- a/cvss/src/metric.rs +++ b/cvss/src/metric.rs @@ -1,3 +1,45 @@ +//! 7.4. Metric Values +//! +//! Each metric value has an associated constant which is used in the formulas, as defined in Table 16. +//! +//! **Table 16: Metric values** +//! +//! +//! | Metric | Metric Value | Numerical Value | +//! | --- | --- | --- | +//! | Attack Vector / Modified Attack Vector | Network | 0.85 | +//! | | Adjacent | 0.62 | +//! | | Local | 0.55 | +//! | | Physical | 0.2 | +//! | Attack Complexity / Modified Attack Complexity | Low | 0.77 | +//! | | High | 0.44 | +//! | Privileges Required / Modified Privileges Required | None | 0.85 | +//! | | Low | 0.62 (or 0.68 if Scope / Modified Scope is Changed) | +//! | | High | 0.27 (or 0.5 if Scope / Modified Scope is Changed) | +//! | User Interaction / Modified User Interaction | None | 0.85 | +//! | | Required | 0.62 | +//! | Confidentiality / Integrity / Availability / Modified Confidentiality / Modified Integrity / Modified Availability | High | 0.56 | +//! | | Low | 0.22 | +//! | | None | 0 | +//! | Exploit Code Maturity | Not Defined | 1 | +//! | | High | 1 | +//! | | Functional | 0.97 | +//! | | Proof of Concept | 0.94 | +//! | | Unproven | 0.91 | +//! | Remediation Level | Not Defined | 1 | +//! | | Unavailable | 1 | +//! | | Workaround | 0.97 | +//! | | Temporary Fix | 0.96 | +//! | | Official Fix | 0.95 | +//! | Report Confidence | Not Defined | 1 | +//! | | Confirmed | 1 | +//! | | Reasonable | 0.96 | +//! | | Unknown | 0.92 | +//! | Confidentiality Requirement / Integrity Requirement / Availability Requirement | Not Defined | 1 | +//! | | High | 1.5 | +//! | | Medium | 1 | +//! | | Low | 0.5 |[](#body) +//! use std::fmt::{Debug, Display}; use std::str::FromStr; diff --git a/cvss/src/v3.rs b/cvss/src/v3.rs index 4c383e3..e7615ed 100644 --- a/cvss/src/v3.rs +++ b/cvss/src/v3.rs @@ -1,3 +1,18 @@ +//! +//! Common Vulnerability Scoring System version 3.1: Specification Document +//! ======================================================================= +//! +//! +//! CVSS Version 3.1 Release +//! ------------------------ +//! +//! This page updates with each release of the CVSS standard. It is currently CVSS version 3.1, released in June 2019. If you wish to use a specific version of the Specification Document, use: +//! +//! * [https://www.first.org/cvss/v3.1/specification-document](https://www.first.org/cvss/v3.1/specification-document) for CVSS version 3.1 +//! * [https://www.first.org/cvss/v3.0/specification-document](https://www.first.org/cvss/v3.0/specification-document) for CVSS version 3.0 +//! +//! * * * +//! use crate::error::{CVSSError, Result}; use crate::metric::Metric; use crate::v3::attack_complexity::AttackComplexityType; @@ -20,33 +35,41 @@ pub mod privileges_required; pub mod scope; pub mod severity; pub mod user_interaction; - +/// +/// The Common Vulnerability Scoring System (CVSS) captures the principal technical characteristics of software, hardware and firmware vulnerabilities. Its outputs include numerical scores indicating the severity of a vulnerability relative to other vulnerabilities. +/// +/// CVSS is composed of three metric groups: Base, Temporal, and Environmental. The Base Score reflects the severity of a vulnerability according to its intrinsic characteristics which are constant over time and assumes the reasonable worst case impact across different deployed environments. The Temporal Metrics adjust the Base severity of a vulnerability based on factors that change over time, such as the availability of exploit code. The Environmental Metrics adjust the Base and Temporal severities to a specific computing environment. They consider factors such as the presence of mitigations in that environment. +/// +/// Base Scores are usually produced by the organization maintaining the vulnerable product, or a third party scoring on their behalf. It is typical for only the Base Metrics to be published as these do not change over time and are common to all environments. Consumers of CVSS should supplement the Base Score with Temporal and Environmental Scores specific to their use of the vulnerable product to produce a severity more accurate for their organizational environment. Consumers may use CVSS information as input to an organizational vulnerability management process that also considers factors that are not part of CVSS in order to rank the threats to their technology infrastructure and make informed remediation decisions. Such factors may include: number of customers on a product line, monetary losses due to a breach, life or property threatened, or public sentiment on highly publicized vulnerabilities. These are outside the scope of CVSS. +/// +/// The benefits of CVSS include the provision of a standardized vendor and platform agnostic vulnerability scoring methodology. It is an open framework, providing transparency to the individual characteristics and methodology used to derive a score. +/// #[derive(Debug, Serialize, Deserialize, Clone)] #[serde(rename_all = "camelCase")] pub struct CVSS { - // 版本： 3.0 和 3.1 + /// Version 版本： 3.0 和 3.1 pub version: Version, - // 向量: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H" + /// 向量: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H" pub vector_string: String, - // 访问途径（AV） + /// [`AttackVectorType`] 访问途径（AV） pub attack_vector: AttackVectorType, - // 攻击复杂度（AC） + /// [`AttackComplexityType`] 攻击复杂度（AC） pub attack_complexity: AttackComplexityType, - // 所需权限（PR） + /// [`PrivilegesRequiredType`] 所需权限（PR） pub privileges_required: PrivilegesRequiredType, - // 用户交互（UI） + /// [`UserInteractionType`] 用户交互（UI） pub user_interaction: UserInteractionType, - // 影响范围（S） + /// [`ScopeType`] 影响范围（S） pub scope: ScopeType, - // 机密性影响（C） + /// [`ConfidentialityImpactType`] 机密性影响（C） pub confidentiality_impact: ConfidentialityImpactType, - // 完整性影响（I） + /// [`IntegrityImpactType`] 完整性影响（I） pub integrity_impact: IntegrityImpactType, - // 可用性影响（A） + /// [`AvailabilityImpactType`] 可用性影响（A） pub availability_impact: AvailabilityImpactType, - // 基础评分 + /// 基础评分 pub base_score: f32, - // 基础评级 + /// [`SeverityType`] 基础评级 pub base_severity: SeverityType, } @@ -55,7 +78,22 @@ impl CVSS { fn update_severity(&mut self) { self.base_severity = SeverityType::from(self.base_score) } - // https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator + /// https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator + /// 7.1. Base Metrics Equations + /// The Base Score formula depends on sub-formulas for Impact Sub-Score (ISS), Impact, and Exploitability, all of which are defined below: + /// + /// | ISS = | 1 - \[ (1 - Confidentiality) × (1 - Integrity) × (1 - Availability) \] | + /// | --- | --- | + /// | Impact = | | + /// | If Scope is Unchanged | 6.42 × ISS | + /// | If Scope is Changed | 7.52 × (ISS - 0.029) - 3.25 × (ISS - 0.02)15 | + /// | Exploitability = | 8.22 × AttackVector × AttackComplexity × | + /// | | PrivilegesRequired × UserInteraction | + /// | BaseScore = | | + /// | If Impact \\<= 0 | 0, _else_ | + /// | If Scope is Unchanged | Roundup (Minimum \[(Impact + Exploitability), 10\]) | + /// | If Scope is Changed | Roundup (Minimum \[1.08 × (Impact + Exploitability), 10\]) |[](#body) + /// fn update_score(&mut self) { let exploit_ability_score = self.exploit_ability_score(); let impact_score_scope = self.impact_score(); @@ -72,10 +110,18 @@ impl CVSS { }; self.base_score = base_score; } - // Roundup保留小数点后一位，小数点后第二位大于零则进一。 例如, Roundup(4.02) = 4.1; 或者 Roundup(4.00) = 4.0 + /// Roundup保留小数点后一位，小数点后第二位大于零则进一。 例如, Roundup(4.02) = 4.1; 或者 Roundup(4.00) = 4.0 + /// /// Where “Round up” is defined as the smallest number, /// specified to one decimal place, that is equal to or higher than its input. For example, /// Round up (4.02) is 4.1; and Round up (4.00) is 4.0. + /// + /// 1. `function Roundup (input):` + /// 2. ` int_input = round_to_nearest_integer (input * 100000)` + /// 3. ` if (int_input % 10000) == 0:` + /// 4. ` return int_input / 100000.0` + /// 5. ` else:` + /// 6. ` return (floor(int_input / 10000) + 1) / 10.0` fn roundup(&self, base_score: f32) -> f32 { let score_int = (base_score * 100_000.0) as u32; if score_int % 10000 == 0 { diff --git a/cvss/src/v3/attack_complexity.rs b/cvss/src/v3/attack_complexity.rs index 5b3611f..3f20356 100644 --- a/cvss/src/v3/attack_complexity.rs +++ b/cvss/src/v3/attack_complexity.rs @@ -1,16 +1,41 @@ +//! ### 2.1.2. Attack Complexity (AC) +//! +//! This metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. As described below, such conditions may require the collection of more information about the target, or computational exceptions. Importantly, the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability (such conditions are captured in the User Interaction metric). If a specific configuration is required for an attack to succeed, the Base metrics should be scored assuming the vulnerable component is in that configuration. The Base Score is greatest for the least complex attacks. The list of possible values is presented in Table 2. +//! +//! **Table 2: Attack Complexity** +//! +//! | Metric Value | Description | +//! | --- | --- | +//! | Low (L) | Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component. | +//! | High (H) | A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected.\[^2\] For example, a successful attack may depend on an attacker overcoming any of the following conditions:
* The attacker must gather knowledge about the environment in which the vulnerable target/component exists. For example, a requirement to collect details on target configuration settings, sequence numbers, or shared secrets.
* The attacker must prepare the target environment to improve exploit reliability. For example, repeated exploitation to win a race condition, or overcoming advanced exploit mitigation techniques.
* The attacker must inject themselves into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g., a man in the middle attack).| +//! +//! _Scoring Guidance_: When deciding between Network and Adjacent, if an attack can be launched over a wide area network or from outside the logically adjacent administrative network domain, use Network. Network should be used even if the attacker is required to be on the same intranet to exploit the vulnerable system (e.g., the attacker can only exploit the vulnerability from inside a corporate network). +//! use crate::error::{CVSSError, Result}; use crate::metric::Metric; use serde::{Deserialize, Serialize}; use std::fmt::{Display, Formatter}; use std::str::FromStr; -// AC +/// Attack Complexity (AC) 攻击复杂度 +/// +/// 攻击复杂度为攻击者无法控制的条件，这些条件必须存在才能攻击脆弱组件。 +/// 如下文所述，这些条件可能需要预先收集有关目标或系统的配置或计算异常等更多信息。 +/// +/// > The Attack Complexity metric describes the conditions beyond the attacker's control that must +/// > exist in order to exploit the vulnerability. As described below, such conditions may require +/// > the collection of more information about the target, the presence of certain system +/// > configuration settings, or computational exceptions. #[derive(Clone, PartialEq, Debug, Deserialize, Serialize)] #[serde(rename_all = "UPPERCASE")] pub enum AttackComplexityType { - // AC:H + /// High(H) 高复杂度 + /// + /// 攻击无法随意完成，攻击者在攻击成功之前，需要对脆弱组件投入大量的准备。 High, - // AC:L + /// Low(L) 低复杂度 + /// + /// 攻击者可以随意攻击，不存在惩罚机制。 Low, } impl Display for AttackComplexityType { diff --git a/cvss/src/v3/attack_vector.rs b/cvss/src/v3/attack_vector.rs index 5593b67..e106174 100644 --- a/cvss/src/v3/attack_vector.rs +++ b/cvss/src/v3/attack_vector.rs @@ -1,23 +1,54 @@ +//! ### 2.1.1. Attack Vector (AV) +//! +//! This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the Base Score) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater Base Score. The list of possible values is presented in Table 1. +//! +//! **Table 1: Attack Vector** +//! +//! | Metric Value | Description | +//! | --- | --- | +//! | Network (N) | The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable _at the protocol level_ one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service (DoS) by sending a specially crafted TCP packet across a wide area network (e.g., CVE‑2004‑0230). | +//! | Adjacent (A) | The vulnerable component is bound to the network stack, but the attack is limited _at the protocol level_ to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE‑2013‑6014). | +//! | Local (L) | The vulnerable component is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either:
* the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or remotely (e.g., SSH); _or_
* the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).| +//! | Physical (P) | The attack requires the attacker to physically touch or manipulate the vulnerable component. Physical interaction may be brief (e.g., evil maid attack\[^1\]) or persistent. An example of such an attack is a cold boot attack in which an attacker gains access to disk encryption keys after physically accessing the target system. Other examples include peripheral attacks via FireWire/USB Direct Memory Access (DMA). | +//! +//! _Scoring Guidance_: When deciding between Network and Adjacent, if an attack can be launched over a wide area network or from outside the logically adjacent administrative network domain, use Network. Network should be used even if the attacker is required to be on the same intranet to exploit the vulnerable system (e.g., the attacker can only exploit the vulnerability from inside a corporate network). +//! + use crate::error::{CVSSError, Result}; use crate::metric::Metric; use serde::{Deserialize, Serialize}; use std::fmt::{Display, Formatter}; use std::str::FromStr; -// AV +/// Attack Vector(AV) 攻击途径 +/// +/// > 该指标反映了攻击脆弱组件的环境可能。该度量值（以及相应的基本分数）将越大， +/// > 攻击者攻击脆弱组件的距离（逻辑上和物理上）就越远。 +/// +/// > This metric reflects the context by which vulnerability exploitation is possible. +/// > This metric value (and consequently the Base score) will be larger the more remote (logically, +/// > and physically) an attacker can be in order to exploit the vulnerable component. #[derive(Clone, PartialEq, Debug, Deserialize, Serialize)] #[serde(rename_all = "SCREAMING_SNAKE_CASE")] pub enum AttackVectorType { - // AV:N + /// Network(N) 远程网络 + /// + /// 可远程利用，即此脆弱组件可被一个以上网络跃点的距离进行攻击（例如，跨路由器的第3层边界）。 Network, - // AV:A + /// Adjacent Network(A) 相邻网络 + /// + /// 攻击仅限于同一共享物理（如蓝牙、IEEE 802.11）或逻辑（如本地IP子网）网络，并且不能跨OSI第3层边界（如路由器）执行。 AdjacentNetwork, - // AV:L + /// Local(L) 本地 + /// + /// 攻击者只能通过本地读/写/执行功能进行攻击。在某些情况下，攻击者可能在本地登录以攻击脆弱组件，或者可能依赖用户交互来执行恶意文件。 Local, - // AV:P + /// Physical(P) 物理 + /// + /// 攻击者只能通过物理方式接触或操作脆弱组件，例如将外围设备连接到系统。 Physical, } - +/// impl Display for AttackVectorType { fn fmt(&self, f: &mut Formatter<'_>) -> std::fmt::Result { write!(f, "{}:{}", Self::NAME, self.as_str()) diff --git a/cvss/src/v3/impact_metrics.rs b/cvss/src/v3/impact_metrics.rs index b38477f..135d60e 100644 --- a/cvss/src/v3/impact_metrics.rs +++ b/cvss/src/v3/impact_metrics.rs @@ -1,30 +1,89 @@ +//! 2.3. Impact Metrics +//! +//! The Impact metrics capture the effects of a successfully exploited vulnerability on the component that suffers the worst outcome that is most directly and predictably associated with the attack. Analysts should constrain impacts to a reasonable, final outcome which they are confident an attacker is able to achieve. +//! +//! Only the increase in access, privileges gained, or other negative outcome as a result of successful exploitation should be considered when scoring the Impact metrics of a vulnerability. For example, consider a vulnerability that requires read-only permissions prior to being able to exploit the vulnerability. After successful exploitation, the attacker maintains the same level of read access, and gains write access. In this case, only the Integrity impact metric should be scored, and the Confidentiality and Availability Impact metrics should be set as None. +//! +//! Note that when scoring a delta change in impact, the **final impact** should be used. For example, if an attacker starts with partial access to restricted information (Confidentiality Low) and successful exploitation of the vulnerability results in complete loss in confidentiality (Confidentiality High), then the resultant CVSS Base Score should reference the “end game” Impact metric value (Confidentiality High). +//! +//! If a scope change has not occurred, the Impact metrics should reflect the Confidentiality, Integrity, and Availability impacts to the vulnerable component. However, if a scope change has occurred, then the Impact metrics should reflect the Confidentiality, Integrity, and Availability impacts to either the vulnerable component, or the impacted component, whichever suffers the most severe outcome. +//! + use crate::error::{CVSSError, Result}; use crate::metric::Metric; use serde::{Deserialize, Serialize}; use std::fmt::{Display, Formatter}; use std::str::FromStr; -// 机密性影响 +/// ### 2.3.1. Confidentiality Impact(C) 机密性影响 +/// +/// 该指标衡量成功利用漏洞对软件组件管理的信息资源的机密性的影响程度。机密 是指仅限于授权用户访问和披露的信息，以及防止未授权用户访问或披露的信息。 +/// +/// This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones. The Base Score is greatest when the loss to the impacted component is highest. The list of possible values is presented in Table 6. +/// +/// **Table 6: Confidentiality** +/// +/// | Metric Value | Description | +/// | --- | --- | +/// | High (H) | There is a total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server. | +/// | Low (L) | There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component. | +/// | None (N) | There is no loss of confidentiality within the impacted component. | +/// #[derive(Clone, PartialEq, Debug, Deserialize, Serialize)] #[serde(rename_all = "UPPERCASE")] pub enum ConfidentialityImpactType { + /// High(H) 高: 高度影响，可能会造成严重的损失。 High, + /// Low(L) 低: 低程度影响，总体上不会造成重大损失。 Low, + /// None(N) 无: 毫无影响。 None, } -// 完整性影响 +/// ### 2.3.2. Integrity Impact(I) 完整性影响 +/// +/// 该指标衡量成功利用漏洞对完整性的影响程度。完整性 是指信息的可靠性和准确性。 +/// +/// This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. The Base Score is greatest when the consequence to the impacted component is highest. The list of possible values is presented in Table 7. +/// +/// **Table 7: Integrity** +/// +/// | Metric Value | Description | +/// | --- | --- | +/// | High (H) | There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component. | +/// | Low (L) | Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact on the impacted component. | +/// | None (N) | There is no loss of integrity within the impacted component. | +/// #[derive(Clone, PartialEq, Debug, Deserialize, Serialize)] #[serde(rename_all = "UPPERCASE")] pub enum IntegrityImpactType { + /// High(H) 高: 高度影响，可能会造成严重的损失。 High, + /// Low(L) 低: 低程度影响，总体上不会造成重大损失。 Low, + /// None(N) 无: 毫无影响。 None, } -// 可用性影响 +/// ### 2.3.3. Availability (A) 可用性影响 +/// +/// 该指标衡量成功利用漏洞对受影响组件可用性的影响程度。虽然机密性和完整性影响指标适用于受影响组件使用的数据（如信息、文件）的机密性或完整性的损失，但此指标是指受影响组件本身的可用性损失，如网络服务（如Web、数据库、电子邮件）。可用性是指信息资源的可访问性，如消耗网络带宽、处理器周期或磁盘空间的攻击都会影响受影响组件的可用性。 +/// +/// This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of _data_ (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component. The Base Score is greatest when the consequence to the impacted component is highest. The list of possible values is presented in Table 8. +/// +/// **Table 8: Availability** +/// +/// | Metric Value | Description | +/// | --- | --- | +/// | High (H) | There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable). | +/// | Low (L) | Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the impacted component are either partially available all of the time, or fully available only some of the time, but overall there is no direct, serious consequence to the impacted component. | +/// | None (N) | There is no impact to availability within the impacted component. |[](#body) +/// #[derive(Clone, PartialEq, Debug, Deserialize, Serialize)] #[serde(rename_all = "UPPERCASE")] pub enum AvailabilityImpactType { + /// High(H) 高: 高度影响，可能会造成严重的损失。 High, + /// Low(L) 低: 低程度影响，总体上不会造成重大损失。 Low, + /// None(N) 无: 毫无影响。 None, } diff --git a/cvss/src/v3/privileges_required.rs b/cvss/src/v3/privileges_required.rs index 095373a..8ae72a5 100644 --- a/cvss/src/v3/privileges_required.rs +++ b/cvss/src/v3/privileges_required.rs @@ -1,18 +1,43 @@ +//! ### 2.1.3. Privileges Required (PR) +//! +//! This metric describes the level of privileges an attacker must possess _before_ successfully exploiting the vulnerability. The Base Score is greatest if no privileges are required. The list of possible values is presented in Table 3. +//! +//! **Table 3: Privileges Required** +//! +//! | Metric Value | Description | +//! | --- | --- | +//! | None (N) | The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack. | +//! | Low (L) | The attacker requires privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources. | +//! | High (H) | The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable component allowing access to component-wide settings and files. | +//! +//! Scoring Guidance: Privileges Required is usually None for hard-coded credential vulnerabilities or vulnerabilities requiring social engineering (e.g., reflected cross-site scripting, cross-site request forgery, or file parsing vulnerability in a PDF reader). +//! + use crate::error::{CVSSError, Result}; use crate::metric::Metric; use serde::{Deserialize, Serialize}; use std::fmt::{Display, Formatter}; use std::str::FromStr; -// PR +/// Privilege Required (PR) 权限要求 +/// +/// 此指标描述攻击者在成功攻击脆弱组件之前必须拥有的权限级别。 +/// +/// This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. #[derive(Clone, PartialEq, Debug, Deserialize, Serialize)] #[serde(rename_all = "UPPERCASE")] pub enum PrivilegesRequiredType { - // PR:H + /// High(H) 高权要求 + /// + /// 攻击者需要对可能影响组件范围设置和文件的易受攻击组件提供重要（如管理）控制的权限。 High, - // PR:L + /// Low(L) 低权要求 + /// + /// 攻击者需要拥有基本用户功能的特权，通常只影响普通用户拥有的设置和文件。或者，具有低权限的攻击者可能只能对非敏感资源造成影响。 Low, - // PR:N + /// None(N) 无要求 + /// + /// 攻击者在攻击之前无需经过授权，因此不需要访问设置或文件来执行攻击。 None, } diff --git a/cvss/src/v3/scope.rs b/cvss/src/v3/scope.rs index da28af6..40bc3de 100644 --- a/cvss/src/v3/scope.rs +++ b/cvss/src/v3/scope.rs @@ -1,3 +1,21 @@ +//! 2.2. Scope (S) +//! +//! The Scope metric captures whether a vulnerability in one vulnerable component impacts resources in components beyond its _security scope_. +//! +//! Formally, a _security authority_ is a mechanism (e.g., an application, an operating system, firmware, a sandbox environment) that defines and enforces access control in terms of how certain subjects/actors (e.g., human users, processes) can access certain restricted objects/resources (e.g., files, CPU, memory) in a controlled manner. All the subjects and objects under the jurisdiction of a single _security authority_ are considered to be under one _security scope_. If a vulnerability in a vulnerable component can affect a component which is in a different _security scope_ than the vulnerable component, a Scope change occurs. Intuitively, whenever the impact of a vulnerability breaches a security/trust boundary and impacts components outside the security scope in which vulnerable component resides, a Scope change occurs. +//! +//! The security scope of a component encompasses other components that provide functionality solely to that component, even if these other components have their own security authority. For example, a database used solely by one application is considered part of that application’s security scope even if the database has its own security authority, e.g., a mechanism controlling access to database records based on database users and associated database privileges. +//! +//! The Base Score is greatest when a scope change occurs. The list of possible values is presented in Table 5. +//! +//! **Table 5: Scope** +//! +//! | Metric Value | Description | +//! | --- | --- | +//! | Unchanged (U) | An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority. | +//! | Changed (C) | An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities. |[](#body) +//! + use crate::error::{CVSSError, Result}; use crate::metric::Metric; use serde::{Deserialize, Serialize}; diff --git a/cvss/src/v3/severity.rs b/cvss/src/v3/severity.rs index e2d94d9..1e0b387 100644 --- a/cvss/src/v3/severity.rs +++ b/cvss/src/v3/severity.rs @@ -1,21 +1,37 @@ +//! 5\. Qualitative Severity Rating Scale +//! +//! For some purposes it is useful to have a textual representation of the numeric Base, Temporal and Environmental scores. All scores can be mapped to the qualitative ratings defined in Table 14.\[^3\] +//! +//! **Table 14: Qualitative severity rating scale** +//! +//! | Rating | CVSS Score | +//! | --- | --- | +//! | None | 0.0 | +//! | Low | 0.1 - 3.9 | +//! | Medium | 4.0 - 6.9 | +//! | High | 7.0 - 8.9 | +//! | Critical | 9.0 - 10.0 | +//! +//! As an example, a CVSS Base Score of 4.0 has an associated severity rating of Medium. The use of these qualitative severity ratings is optional, and there is no requirement to include them when publishing CVSS scores. They are intended to help organizations properly assess and prioritize their vulnerability management processes. +//! use crate::error::{CVSSError, Result}; use serde::{Deserialize, Serialize}; use std::fmt::{Display, Formatter}; use std::str::FromStr; -// 严重性 +/// 定性严重程度 #[derive(Clone, PartialEq, Debug, Deserialize, Serialize)] #[serde(rename_all = "UPPERCASE")] pub enum SeverityType { - // 未校正 + /// 未校正 | None | 0.0 | None, - // 低危 + /// 低危 | Low | 0.1 - 3.9 | Low, - // 中危 + /// 中危 | Medium | 4.0 - 6.9 | Medium, - // 高危 + /// 高危 | High | 7.0 - 8.9 | High, - // 严重 + /// 严重 | Critical | 9.0 - 10.0 | Critical, } diff --git a/cvss/src/v3/user_interaction.rs b/cvss/src/v3/user_interaction.rs index 63d7994..f873403 100644 --- a/cvss/src/v3/user_interaction.rs +++ b/cvss/src/v3/user_interaction.rs @@ -1,16 +1,39 @@ +//! ### 2.1.4. User Interaction (UI) +//! +//! This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner. The Base Score is greatest when no user interaction is required. The list of possible values is presented in Table 4. +//! +//! **Table 4: User Interaction** +//! +//! | Metric Value | Description | +//! | --- | --- | +//! | None (N) | The vulnerable system can be exploited without interaction from any user. | +//! | Required (R) | Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. For example, a successful exploit may only be possible during the installation of an application by a system administrator. |[](#body) +//! + use crate::error::{CVSSError, Result}; use crate::metric::Metric; use serde::{Deserialize, Serialize}; use std::fmt::{Display, Formatter}; use std::str::FromStr; -// UI +/// User Interaction (UI) 用户交互 +/// +/// 此指标描述攻击脆弱组件对除攻击者之外的用户参与的需求，即确定脆弱组件是仅攻击者本身就可以随意利用，还是需要用户（或用户进程）以某种方式参与。 +/// +/// > This metric captures the requirement for a user, other than the attacker, +/// > to participate in the successful compromise of the vulnerable component. +/// > This metric determines whether the vulnerability can be exploited solely at the will of the +/// > attacker, or whether a separate user (or user-initiated process) must participate in some manner. #[derive(Clone, PartialEq, Debug, Deserialize, Serialize)] #[serde(rename_all = "UPPERCASE")] pub enum UserInteractionType { - // UI:R + /// Require(R) 有需求 + /// + /// 需要用户采取一些措施才能成功攻击此脆弱组件，例如说服用户单击电子邮件中的链接。 Required, - // UI:N + /// None(N) 无需求 + /// + /// 不需要任何用户的交互就可以成功攻击此脆弱组件。 None, } diff --git a/src/lib.rs b/src/lib.rs index 059dc12..4b3b378 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -1,8 +1,4 @@ -#[cfg(test)] -mod tests { - #[test] - fn it_works() { - let result = 2 + 2; - assert_eq!(result, 4); - } -} +#![doc( + html_logo_url = "https://avatars.githubusercontent.com/u/30642514?s=360&v=4", + html_root_url = "https://docs.rs/nvd-rs/0.0.1" +)]