mailing list archives
Re: buffer overflow in libsecure (NSA Security-enhanced Linux)
From: Matt Power <mhpower () BOS BINDVIEW COM>
Date: Tue, 2 Jan 2001 20:06:27 -0500
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
BindView Corporation, RAZOR Team
mhpower () bos bindview com
- Re: buffer overflow in libsecure (NSA Security-enhanced Linux) Matt Power (Jan 03)