Headline

GHSA-xq3w-v528-46rv: Denial of Service attack on windows app using netty

Summary

An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash.

Details

When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed.

At this stage, Netty tries to load both /etc/os-release and /usr/lib/os-release even though it is in a Windows environment.

If netty finds this files, it reads them and loads them into memory.

By default :

The JVM maximum memory size is set to 1 GB,
A non-privileged user can create a directory at C:\ and create files within it.

the source code identified : https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java

Despite the implementation of the function normalizeOs() the source code not verify the OS before reading C:\etc\os-release and C:\usr\lib\os-release.

PoC

Create a file larger than 1 GB of data in C:\etc\os-release or C:\usr\lib\os-release on a Windows environnement and start your Netty application.

To observe what the application does with the file, the security analyst used “Process Monitor” from the “Windows SysInternals” suite. (https://learn.microsoft.com/en-us/sysinternals/)

cd C:\etc
fsutil file createnew os-release 3000000000

The source code used is the Netty website code example : Echo ‐ the very basic client and server.

The vulnerability was tested on the 4.1.112.Final version.

The security analyst tried the same technique for C:\proc\sys\net\core\somaxconn with a lot of values to impact Netty but the only things that works is the “larger than 1 GB file” technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186

Impact

By loading the “file larger than 1 GB” into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application.

This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists.

Client mode :

Server mode :

somaxconn :

Severity

Attack vector : “Local” because the attacker needs to be on the system where the Netty application is running.
Attack complexity : “Low” because the attacker only need to create a massive file (regardless of its contents).
Privileges required : “Low” because the attacker requires a user account to exploit the vulnerability.
User intercation : “None” because the administrator don’t need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings.
Scope : “Unchanged” because only Netty is affected by the vulnerability.
Confidentiality : “None” because no data is exposed through exploiting the vulnerability.
Integrity : “None” because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere.
Availability : “High” because the exploitation of this vulnerability crashes the entire java application.

1 day ago

ghsa

Open in Source

#vulnerability #web #windows #microsoft #dos #git #java

Summary

An unsafe reading of environment file could potentially cause a denial of service in Netty.
When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash.

Details

When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed.

At this stage, Netty tries to load both /etc/os-release and /usr/lib/os-release even though it is in a Windows environment.

If netty finds this files, it reads them and loads them into memory.

By default :

The JVM maximum memory size is set to 1 GB,
A non-privileged user can create a directory at C:\ and create files within it.

the source code identified :
https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java

Despite the implementation of the function normalizeOs() the source code not verify the OS before reading C:\etc\os-release and C:\usr\lib\os-release.

PoC

Create a file larger than 1 GB of data in C:\etc\os-release or C:\usr\lib\os-release on a Windows environnement and start your Netty application.

To observe what the application does with the file, the security analyst used “Process Monitor” from the “Windows SysInternals” suite. (https://learn.microsoft.com/en-us/sysinternals/)

cd C:\etc
fsutil file createnew os-release 3000000000

The source code used is the Netty website code example : Echo ‐ the very basic client and server.

The vulnerability was tested on the 4.1.112.Final version.

The security analyst tried the same technique for C:\proc\sys\net\core\somaxconn with a lot of values to impact Netty but the only things that works is the “larger than 1 GB file” technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186

Impact

By loading the “file larger than 1 GB” into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application.

This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists.

Client mode :

Server mode :

somaxconn :

Severity

Attack vector : “Local” because the attacker needs to be on the system where the Netty application is running.
Attack complexity : “Low” because the attacker only need to create a massive file (regardless of its contents).
Privileges required : “Low” because the attacker requires a user account to exploit the vulnerability.
User intercation : “None” because the administrator don’t need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings.
Scope : “Unchanged” because only Netty is affected by the vulnerability.
Confidentiality : “None” because no data is exposed through exploiting the vulnerability.
Integrity : “None” because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere.
Availability : “High” because the exploitation of this vulnerability crashes the entire java application.

References