In this week’s digest, we will discuss:
- an OpenSSL version 3.0.0 security advisory;
- a Sqlite array-bounds overflow vulnerability; and
- a GitHub repojacking attack.
Openssl Security Advisory
OpenSSL 3.0.0 recently addressed two vulnerabilities: CVE-2022-3602 and CVE-2022-3786.
CVE-2022-3602, rated critical (9.8/10), involves a 4-byte stack buffer overflow that can lead to DoS or Code Execution. For a successful exploitation, the target needs to perform X509 certificate validation of a malicious certificate, specifically name constraint checking. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. That said, the attack could be frustrated by stack overflow protections typically enabled in modern operating systems. The vulnerability was initially described as critical by OpenSSL, and further analysis led to downgrading the severity to high. Although at the time of writing the Base Score is 9.8 (critical).
CVE-2022-3786, rated high (7.5/10), is another buffer overflow that is triggered by a malicious tls certificate. Similar to the aforementioned vulnerability, the attack entails an attacker crafting a certificate with a malicious email address. The difference lies in the characters that can be used to cause an overflow, which is limited to `.’ character (decimal 46), which leads to service crash or Denial of Service.
Users that leverage OpenSSL 3.0 are encouraged to upgrade to the latest version as soon as possible. This blog post could be useful in helping users determine whether they have the vulnerable version of the library in use in their environments.
Sqlite Array-bounds Overflow Vulnerability
TrailofBits disclosed a high-severity vulnerability in a popular DBMS library Sqlite recently patched The CVE assigned to this vulnerability is CVE-2022-35737 and is rated 7.5/10.
The vulnerability is an array overflow in SQLite 1.0.12 through 3.39.x before 3.39.2 and affects applications that use the SQLite library API. The exploitability depends on how SQLite is compiled; if the program is compiled without stack canaries enabled, a code execution is possible. The vulnerability was introduced in v1.0.12, released on October 17, 2000.
According to the source, “On vulnerable systems, CVE-2022-35737 is exploitable when large string inputs are passed to the SQLite implementations of the printf functions and when the format string contains the %Q, %q, or %w format substitution types.” This reduces the attack surface and the likelihood of an application being actually exploitable through this vulnerability, although it is still strongly recommended for users to evaluate the risk within the context of their use of the component.
The patched SQLite version v3.39.2 is available for users to upgrade to in their applications. Users dependent on tools that use the vulnerable SQLite library would need to wait for the patch to be released from the maintainers of the code. Trailofbits has also released the exploit POC which can be found on GitHub.
Github Repojacking
Checkmarx disclosed yet another method to attack the supply chain by targeting code repositories hosted on github.com. The attack is dubbed repojacking and involves takeover of a repository by bypassing a pre-existing security control set by Microsoft for this type of attack. This control is termed “popular-repository-namespace-retirement” and basically disallows GitHub users from creating repositories with a name that matches the one previously used by a deactivated user with the same username if the repository had more than 100 clones within one week leading up to the username change. It was implemented as a mitigation by GitHub after checkmarx had disclosed a similar vulnerability in 2021.
The new attack gets around the mitigation by leveraging a github feature called repository transfer. Here’s how the attack is pursued:
- “victim/repo” is a popular GitHub repository retired under the “popular repository namespace retirement” protection
- “helper_account” creates the “repo” repository
- “helper_account” transfers the ownership of the “repo” repository to “attacker_account”
- “attacker_account” renames its username to “victim”
- The new “victim” account (previously “attacker_account”) accepts the ownership transfer and essentially takes over the target repository
The fix for this vulnerability has been applied. Checkmarx has also released a tool to check what golang direct dependencies could be vulnerable to this type of attack.
Comments