buffer overflow in libsecure (NSA Security-enhanced Linux)

[Matt Power <mhpower () BOS BINDVIEW 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