[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-bugs
Subject:    system/578: rpc.pcnfsd issues
From:       Felix Schroeter <felix () schlund ! de>
Date:       1998-08-19 13:23:15
[Download RAW message or body]


>Number:         578
>Category:       system
>Synopsis:       strcpy paranoia for rpc.pcnfsd
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 19 07:30:02 MDT 1998
>Last-Modified:
>Originator:     Felix Schroeter
>Organization:
net
>Release:        Current (as of 980819)
>Environment:
	
	System      : OpenBSD 2.3
	Architecture: OpenBSD.i386
	Machine     : i386
>Description:
	
In /usr/src/usr.sbin/rpc.pcnfsd/pcnfs_cache.c, there are these two
strcpy's (lines 97, 98):
        (void)strcpy(User_cache[0].cpw, p->pw_passwd);
        (void)strcpy(User_cache[0].cuname, p->pw_name);
The cpw field is 32 bytes long, which is definitely too short for
our blowfish passwords (they are 60 characters long, w/o terminating
'\0'). The cuname field is 10 bytes long, which is okay *as long as*
noone uses longer user names (I know that that imposes some other
problems, but anyway that's a security risk we could avoid in our
proactively secure OS).

In pcnfsd_misc.c, there is run_ps630() which isn't used anyway, but
which contains an unsafe looking strcpy (line 244).

The strcpy() for the username in pcnfsd_misc.c, line 434 looks
like it could overflow a buffer by one. The username seems to stem
from a RPC request for which the username is defined to be at most
64 bytes long (from pcnfsd.x):

const USERNAMELEN = 64;
typedef string username<USERNAMELEN>;

I don't know though if that definition in fact means 63 chars plus
terminating null byte.

In line 535 of pcnfsd_misc.c, there's a potentially unsafe strcpy from
a config file (thus, probably not remotely exploitable).

In pcnfsd_print.c, there are also several strcpy()s that look a bit
suspicious.

In pcnfsd_test.c, there's a 256 byte spooldirbuf. In line 225,
a strcpy() copies a path into that buffer that can possibly up
to PATH_MAX (1k) long.

In line 281, the source can be up to 256 bytes long (it stems from
a buffer of that length), and is copied into a 32 bytes buffer.
>How-To-Repeat:
	Use the source, luke.
>Fix:
	Don't use pcnfsd :-) Else, standard methods apply.

>Audit-Trail:
>Unformatted:

[prev in list] [next in list] [prev in thread] [next in thread]