Subject: bin/35304: /usr/src/sbin/sysctl/sysctl.c off-by-one nul byte overwrite
To: None <gnats-admin@netbsd.org, netbsd-bugs@netbsd.org>
From: None <vague@ngdev.net>
List: netbsd-bugs
Date: 12/21/2006 14:25:00
>Number:         35304
>Category:       bin
>Synopsis:       Off-by-one nul byte overwrite in mode_bits routine of sbin/sysctl
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 21 14:25:00 +0000 2006
>Originator:     C J Coleman
>Release:        NetBSD 4.99.4
>Organization:
	NetBSD user
>Environment:
System: NetBSD perdition.ngdev.net 4.99.4 NetBSD 4.99.4 (GENERIC_LAPTOP) #0: Tue Nov 28 22:10:35 GMT 2006 c.c@perdition.ngdev.net:/usr/obj/sys/arch/i386/compile/GENERIC_LAPTOP i386
Architecture: i386
Machine: i386
>Description:
        There is an off-by-one in the mode_bits function of sbin/sysctl.
        The ordering and packing of variables on the i386 platform built
        with USE_SSP=yes on November 28th 2006 -current means that the
        off-by-one nul overwrite will cause the SSP canary to be
        damaged.  This results in program termination by SSP as
        mode_bits concludes it's journey.

	It is possible that this bug may cause issue on other platforms,
	but I do not have the capability to test this (nor the knowledge
	of SSP-based or standard variable alignment issues for other
	platforms).

	This bug was introduced with the inception of the mode_bits
	function in revision 1.108.
>How-To-Repeat:
	1. Compile sysctl with USE_SSP=yes with revision 1.108 or later
	   of /usr/src/sbin/sysctl/sysctl.c on i386.
	2. Run sysctl in such a manner as to require mode_bits to
	   translate some value, such as `kern.coredump.setid.mode' --
	   for example, `sysctl -a'.
>Fix:
	The first line of local declarations in mode_bits (line 2496 in
	revision 1.121 of /usr/src/sbin/sysctl/sysctl.c) reads:

		char buf[11], outbuf[100];

	This is not adequate for the strmode(3) operation (lines 2560
	and 2572 in revision 1.121).  As quoted from the strmode(3)
	manual page:

		``The strmode() function converts a file mode (the type
		  and permission information associated with an inode,
		  see stat(2)) into a symbolic string which is stored in
		  the location referenced by bp.  This stored string is
		  eleven characters in length plus a trailing nul
		  byte.''

        The fix is simply to change buf to be `buf[12]'.  The secondary
        nul byte termination (occurring after the strmode(3) call in
        both instances), is not necessary -- further it is one byte
        early.  (Though, it seems that this byte tends to be a space,
        anyway.)