[Secure-testing-team] Bug#565223: possible vulnerability in sudo glob processing
Ken Raeburn
raeburn at permabit.com
Wed Jan 13 23:17:36 UTC 2010
Package: sudo
Version: 1.6.9p17-2
Severity: grave
Tags: security patch
Justification: user security hole
I'm investigating #556562 (wildcard "*" sudoers rules are broken),
filed by a co-worker. I discovered it's your basic use-after free
problem, fixed by the following patch:
--- parse.c 2010/01/13 21:59:04 1.1
+++ parse.c 2010/01/13 21:59:12
@@ -316,9 +316,11 @@
break;
}
}
- globfree(&gl);
- if (*ap == NULL)
+ if (*ap == NULL) {
+ globfree(&gl);
return(FALSE);
+ }
+ globfree(&gl);
if (!sudoers_args ||
(!user_args && sudoers_args && !strcmp("\"\"", sudoers_args)) ||
However, in tracking down just why globfree causes *ap to be NULL in
our case, and digging into the malloc/free implementation details, it
appears that the first word stored in the freed object (in this case
the gl.gl_pathv array) can be overwritten with a linked-list pointer.
Depending on the block size, other fields can be overwritten too.
This means it may be influenced by other malloc/free activity in the
process, and the number of entries in the directory matching the glob
pattern, and the lengths of the filenames freed up before the
gl.gl_pathv array itself is freed up, and I have not yet convinced
myself that the first isn't subject to some amount of control by an
attacker logged in to the system. If the attacker can cause *ap to be
non-null when it shouldn't be, he may be able to execute commands he
shouldn't be able to.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (1001, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-2-permabit1-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages sudo depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libpam-modules 1.0.1-5+lenny1 Pluggable Authentication Modules f
ii libpam0g 1.0.1-5+lenny1 Pluggable Authentication Modules l
sudo recommends no packages.
sudo suggests no packages.
-- no debconf information
More information about the Secure-testing-team
mailing list