This week, we’ll discuss a high-severity vulnerability in the Linux kernel, an LDAP server vulnerability for Linux, and a zero-day in a popular Java framework.
Local Privilege Escalation in Linux Kernel
A heap buffer overflow was found in the IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. According to NVD, this flaw allows a local attacker with a user privilege to overwrite the kernel heap objects and potentially cause a local privilege escalation. The vulnerability is numbered CVE-2022-27666 with a CVSS base score of 7.8. The exploit for the vulnerability appears to be available on GitHub and claims to achieve local privilege escalation on the latest Ubuntu Desktop 21.10. The fix for this vulnerability was applied recently to upstream >= 5.10 LTS kernels.
Root Cause – The security researcher behind the exploit, Xiaochen Zou aka @ETenal7, states “the vulnerability was introduced in 2017, by commit cac2661c53f3 and commit 03e2a30f6a27. The basic logic of this vulnerability is that the receiving buffer of a user message in esp6 module is an 8-page buffer, but the sender can send a message larger than 8 pages, which clearly creates a buffer overflow.”
The exploitation of this vulnerability incorporates various interesting techniques like the heap feng shui, which is the selective manipulation of layout of the heap memory space, similar to a careful arrangement of entities in space in the Chinese system of feng shui.
Improper Authentication in Directory Server
389 Directory Server is an Open Source LDAP server for Linux. A vulnerability was found in the 389 Directory Server that allows expired passwords to access the database to cause improper authentication. The vulnerability is numbered CVE-2022-0996 and rated CVSS 7.5 High.
While there’s not a whole lot of information available on this vulnerability, the update can be installed with the “dnf” package manager. Use su -c ‘dnf upgrade –advisory FEDORA-2022-2558f14c58‘ at the command line. For more information, refer to the dnf documentation.
According to the researcher behind the proof-of-concept: “In my testing I have only one ACI in the database that allows access to any user who is “authenticated”. After the error 49 (expired password) that connection should be considered “anonymous”, but it looks like it’s still being seen as “authenticated” in regards to access control (ACI).”
Critical Zero Day Remote Code Execution in Spring Core
The Spring Framework is an application framework and inversion of control container for the Java platform. The framework’s core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE platform. The Spring WebFlux application running on JDK 9+ is vulnerable to remote code execution (RCE) and is numbered CVE-2022-22965.
The CVE is rated Critical and various trusted security resources like LunaSec and Rapid7 have confirmed the presence of the vulnerability. Due to a large customer base of the framework, the vulnerability is being compared and named similarly to the infamous log4shell, this one being called spring4shell.
While the impact of the vulnerability is certainly high since once exploited it can allow for arbitrary code execution, there are a certain set of requisites for an implementation to be exploitable. For that reason some security researchers argue that the vulnerability, although is a high severity one, does not reach the same levels of trouble as the log4shell. Some of those requisites are also security risks documented in the Spring docs like the usage of allowfields property on the databinder.
Other requisites include usage of the framework with Tomcat in a WAR deployment and spring beans enabled. That said, since this is an actively evolving incident, there might be different attack pathways possible and therefore customers that are impacted with the vulnerability are advised to perform a thorough analysis of the implementation before performing any actions to accept/mitigate the security risk. LunaSec’s blog post on the matter provides an in-depth explanation of the vulnerability and can be a helpful resource for obtaining more information and potential mitigation strategies.
Patches are now available for Spring4Shell in Spring versions 5.3.18 and 5.2.20.
Comments