[18409] in bugtraq
Re: buffer overflow in libsecure (NSA Security-enhanced Linux)
daemon@ATHENA.MIT.EDU (Matt Power)
Wed Jan 3 11:50:11 2001
Message-Id: <200101030106.UAA10577@theta.bos.bindview.com>
Date: Tue, 2 Jan 2001 20:06:27 -0500
Reply-To: Matt Power <mhpower@BOS.BINDVIEW.COM>
From: Matt Power <mhpower@BOS.BINDVIEW.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20001227153528.A3722@webcom.com>
In http://www.securityfocus.com/archive/1/153355, Perry Harrington
<perry@webcom.com> wrote:
>From your message, it would appear that the file parser is at fault, not
>truncating the newline in the value. If the newline is removed, like most
>config file parsers, then the allocation logic is correct.
Actually, in the code from slinux-200012181053-release.tgz, the
allocation logic is still incorrect even if the newline character is
removed from the end of each line that's read from the
/etc/security/default_type file. If the newline is removed, the number
of characters to copy is reduced by one, but the buffer size is also
reduced by one. For example, if the buf field were "sysadm_r:sysadm_t"
rather than "sysadm_r:sysadm_t\n", then strlen(buf)-i-len-1 is
17 - 0 - 8 - 1, which is 8; and the strcpy would attempt to copy the 9
characters "sysadm_t\0" into the 8-character buffer.
In any case, the NSA has announced a new release that fixes this
buffer-overflow problem. There's a copy of the NSA's announcement at
http://marc.theaimsgroup.com/?l=selinux&m=97847509307650&w=2
Matt Power
BindView Corporation, RAZOR Team
mhpower@bos.bindview.com
