Home Online Business Linode Safety Digest Oct 30-Nov 6

Linode Safety Digest Oct 30-Nov 6

0
Linode Safety Digest Oct 30-Nov 6

[ad_1]

On this week’s digest, we’ll talk about:

  • 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 just lately 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 mentioned, the assault could possibly be annoyed by stack overflow protections usually enabled in fashionable working methods. 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 ends up in service crash or Denial of Service. 

Customers that leverage OpenSSL 3.0 are inspired to improve to the newest model as quickly as doable. This weblog submit could possibly 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 preferred DBMS library Sqlite just lately 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 by 3.39.x earlier than 3.39.2 and impacts purposes that use the SQLite library API. The exploitability will depend on 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. 

In keeping with the supply, “On weak methods, CVE-2022-35737 is exploitable when massive string inputs are handed to the SQLite implementations of the printf capabilities and when the format string accommodates the %Q, %q, or %w format substitution varieties.” This reduces the assault floor and the probability of an software being truly exploitable by this vulnerability, though it’s nonetheless strongly really helpful for customers to judge the chance throughout the context of their use of the part.   

The patched SQLite model v3.39.2 is on the market 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 will be discovered on GitHub.  

Github Repojacking

Checkmarx disclosed yet one more methodology to assault the provision chain by focusing on code repositories hosted on github.com. The assault is dubbed repojacking and includes takeover of a repository by bypassing a pre-existing safety management set by Microsoft for this sort of assault. This management is termed “popular-repository-namespace-retirement” and mainly 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 applied as a mitigation by GitHub after checkmarx had disclosed an analogous vulnerability in 2021. 

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

  1. “sufferer/repo” is a well-liked GitHub repository retired underneath the “widespread 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 software to test what golang direct dependencies could possibly be weak to this sort of assault. 

[ad_2]

LEAVE A REPLY

Please enter your comment!
Please enter your name here