Linode Safety Digest Oct 30-Nov 6

On this week’s digest, we are going to focus on:

  • an OpenSSL model 3.0.0 safety advisory;
  • a Sqlite array-bounds overflow vulnerability; and
  • a GitHub repojacking assault.

Openssl Safety Advisory

OpenSSL 3.0.0 not too long ago addressed two vulnerabilities: CVE-2022-3602 and CVE-2022-3786. 

CVE-2022-3602, rated essential (9.8/10), includes a 4-byte stack buffer overflow that may result in DoS or Code Execution. For a profitable exploitation, the goal must carry out X509 certificates validation of a malicious certificates, particularly identify constraint checking. An attacker can craft a malicious e-mail deal with to overflow 4 attacker-controlled bytes on the stack. That stated, the assault might be annoyed by stack overflow protections usually enabled in trendy working techniques. The vulnerability was initially described as essential by OpenSSL, and additional evaluation led to downgrading the severity to excessive. Though on the time of writing the Base Rating is 9.8 (essential).  

CVE-2022-3786, rated excessive (7.5/10), is one other buffer overflow that’s triggered by a malicious tls certificates. Just like the aforementioned vulnerability, the assault entails an attacker crafting a certificates with a malicious e-mail deal with. The distinction lies within the characters that can be utilized to trigger an overflow, which is restricted to `.’ character (decimal 46), which results in service crash or Denial of Service. 

Customers that leverage OpenSSL 3.0 are inspired to improve to the most recent model as quickly as doable. This weblog publish might be helpful in serving to customers decide whether or not they have the weak model of the library in use of their environments.  

Sqlite Array-bounds Overflow Vulnerability

TrailofBits disclosed a high-severity vulnerability in a well-liked DBMS library Sqlite not too long ago 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 via 3.39.x earlier than 3.39.2 and impacts purposes that use the SQLite library API. The exploitability is dependent upon how SQLite is compiled; if this system is compiled with out stack canaries enabled, a code execution is feasible. The vulnerability was launched in v1.0.12, launched on October 17, 2000. 

Based on the supply, “On weak techniques, CVE-2022-35737 is exploitable when giant string inputs are handed to the SQLite implementations of the printf capabilities and when the format string incorporates the %Q, %q, or %w format substitution varieties.” This reduces the assault floor and the probability of an software being truly exploitable via this vulnerability, though it’s nonetheless strongly really helpful for customers to judge the chance inside the context of their use of the element.   

The patched SQLite model v3.39.2 is accessible for customers to improve to of their purposes. Customers depending on instruments that use the weak SQLite library would wish to attend for the patch to be launched from the maintainers of the code. Trailofbits has additionally launched the exploit POC which might be discovered on GitHub.  

Github Repojacking

Checkmarx disclosed one more methodology to assault the availability chain by focusing on code repositories hosted on The assault is dubbed repojacking and includes takeover of a repository by bypassing a pre-existing safety management set by Microsoft for the sort of assault. This management is termed “popular-repository-namespace-retirement” and principally disallows GitHub customers from creating repositories with a reputation that matches the one beforehand utilized by a deactivated person with the identical username if the repository had greater than 100 clones inside one week main as much as the username change. It was carried out as a mitigation by GitHub after checkmarx had disclosed the same vulnerability in 2021. 

The brand new assault will get across the mitigation by leveraging a github function referred to as repository switch. Right here’s how the assault is pursued:

  1. “sufferer/repo” is a well-liked GitHub repository retired underneath the “standard repository namespace retirement” safety
  2. “helper_account” creates the “repo” repository
  3. “helper_account” transfers the possession of the “repo” repository to “attacker_account”
  4. “attacker_account” renames  its username to “sufferer”
  5. The brand new “sufferer” account (beforehand “attacker_account”) accepts the possession switch and basically takes over the goal repository

The repair for this vulnerability has been utilized. Checkmarx has additionally launched a device to examine what golang direct dependencies might be weak to the sort of assault. 

Related Articles


Please enter your comment!
Please enter your name here

Latest Articles