Utilizing a custom CodeQL query written as a part of the GitHub Security Lab Bug Bounty program, I've unearthed a local temporary directory hijacking vulnerability.
This particular vulnerability impacts Keycloak/keycloak
You can see the custom CodeQL query utilized here:
https://lgtm.com/query/7674880310425951666/
This particular vulnerability exists because on unix-like systems (not including MacOS) the system temporary directory is shared between all users.
As such, failure to correctly set file permissions and/or verify exclusive creation of directories can lead to either local information disclosure, or local file hijacking by another user.
In the worse case scenario, this can lead to a local privilege escalation vulnerability, as it did in this vulnerability I disclosed in Jetty:
GHSA-g3wg-6mcf-8jj6
In this case, it does not look like code is explicitly intended to be written to these directories. However, it does look like the GzipResourceEncodingProviderFactory.java is used as the creator of a cache. Thus, a malicious user can perform cache poisoning.
Additionally, DirExportProvider.java looks like it's being used to export information. This information can be corrupted by a different user.
One of many root causes here is that mkdir and mkdirs do not fail if the directory already exists. They merely return false. As such, an attacker can create these directories before the java process creates them, but with wider user permissions. Since these directory names are not in any way random, the attacker can simply create these directories ahead of Keycloak. When this happens, the java process doesn't complain that the directories already exist, mkdir and mkdirs simply return false.
However, assuming that the java process is the first thing to create these directories, mkdir and mkdirs will only set the directory following the default umask (I believe); by default that means that these directories are created with the permissions drwxr-xr-x.
Thus allowing a malicious local user to read the contents of this temporary directory.
Official Disclosure
https://access.redhat.com/security/cve/cve-2021-20202
Official Fix
https://github.com/keycloak/keycloak/pull/7859/files
JLLeitschuh Analyst
Utilizing a custom CodeQL query written as a part of the GitHub Security Lab Bug Bounty program, I've unearthed a local temporary directory hijacking vulnerability.
This particular vulnerability impacts Keycloak/keycloak
You can see the custom CodeQL query utilized here:
https://lgtm.com/query/7674880310425951666/
This particular vulnerability exists because on unix-like systems (not including MacOS) the system temporary directory is shared between all users.
As such, failure to correctly set file permissions and/or verify exclusive creation of directories can lead to either local information disclosure, or local file hijacking by another user.
In the worse case scenario, this can lead to a local privilege escalation vulnerability, as it did in this vulnerability I disclosed in Jetty:
GHSA-g3wg-6mcf-8jj6
In this case, it does not look like code is explicitly intended to be written to these directories. However, it does look like the GzipResourceEncodingProviderFactory.java is used as the creator of a cache. Thus, a malicious user can perform cache poisoning.
Additionally, DirExportProvider.java looks like it's being used to export information. This information can be corrupted by a different user.
One of many root causes here is that
mkdirandmkdirsdo not fail if the directory already exists. They merely returnfalse. As such, an attacker can create these directories before the java process creates them, but with wider user permissions. Since these directory names are not in any way random, the attacker can simply create these directories ahead of Keycloak. When this happens, the java process doesn't complain that the directories already exist,mkdirandmkdirssimply return false.However, assuming that the java process is the first thing to create these directories,
mkdirandmkdirswill only set the directory following the default umask (I believe); by default that means that these directories are created with the permissionsdrwxr-xr-x.Thus allowing a malicious local user to read the contents of this temporary directory.
Official Disclosure
https://access.redhat.com/security/cve/cve-2021-20202
Official Fix
https://github.com/keycloak/keycloak/pull/7859/files