[18356] in bugtraq
buffer overflow in libsecure (NSA Security-enhanced Linux)
daemon@ATHENA.MIT.EDU (Matt Power)
Wed Dec 27 18:46:39 2000
Message-Id: <200012261856.NAA14791@theta.bos.bindview.com>
Date: Tue, 26 Dec 2000 13:56:30 -0500
Reply-To: Matt Power <mhpower@BOS.BINDVIEW.COM>
From: Matt Power <mhpower@BOS.BINDVIEW.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Recently the U.S. National Security Agency released a distribution
called Security-enhanced Linux (see http://www.nsa.gov/selinux/).
This includes a modified version of the kernel and some utilities that
provide a new mandatory access control architecture for Linux.
The most recent version that appears to be available is dated last
week, slinux-200012181053-release.tgz. In this distribution, the
find_default_type function in libsecure/get_default_type.c attempts to
extract a type field from the file /etc/security/default_type and copy
it to a result buffer (specifically, to the argument "char **type").
Memory for this result buffer is allocated using malloc, but the
argument to malloc is always one character too small.
For example, the role argument might typically be "sysadm_r" and the
len argument would then be 8. With the initial installation, the first
value of buf would be "sysadm_r:sysadm_t\n". There are no leading
spaces, so i is 0. In the statement
(*type) = (char*) malloc (sizeof(char) * (strlen(buf)-i-len-1));
the argument to malloc is 18 - 0 - 8 - 1, which is 9. Then,
strcpy ((*type), &buf[i]+len+1);
attempts to copy the 10 characters "sysadm_t\n\0" into the 9-character
buffer.
This patch should address the issue:
*** get_default_type.c.old Thu Nov 30 11:32:58 2000
--- get_default_type.c Tue Dec 26 00:19:04 2000
***************
*** 72,74 ****
/* malloc space for the type */
! (*type) = (char*) malloc (sizeof(char) * (strlen(buf)-i-len-1));
if ((*type) == NULL)
--- 72,74 ----
/* malloc space for the type */
! (*type) = (char*) malloc (sizeof(char) * (strlen(buf)-i-len));
if ((*type) == NULL)
This patch was sent to the mailing list that the NSA set up for
comments and contributions related to their distribution. We've
received a response and expect that this patch will be incorporated
into a later release. People who follow the above description of the
bug in the slinux-200012181053-release distribution may wish to
incorporate this patch into their own copy of the code. Please note
that our bug report does not describe a direct way to copy untrusted
user input to memory locations beyond the end of a buffer. The main
risk we know of is that, for some lengths of type fields in the
/etc/security/default_type file, a memory location may be modified
that either contains application data (in another malloced buffer), or
contains overhead data that a malloc implementation was relying on.
Matt Power
BindView Corporation, RAZOR Team
mhpower@bos.bindview.com
