[2390] in Kerberos-V5-bugs
krb5-libs/144: Potential race in in_tkt in libkrb4 potentially giving write access to a root-owned file
daemon@ATHENA.MIT.EDU (hartmans@MIT.EDU)
Sat Nov 2 01:01:15 1996
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: tytso@MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, hartmans@MIT.EDU
Date: Sat, 2 Nov 1996 01:00:18 -0500
From: hartmans@MIT.EDU
Reply-To: hartmans@MIT.EDU
To: krb5-bugs@MIT.EDU
>Number: 144
>Category: krb5-libs
>Synopsis: Potential race in in_tkt in libkrb4 potentially giving write access to a root-owned file
>Confidential: yes
>Severity: serious
>Priority: high
>Responsible: tytso
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sat Nov e 01:01:01 EST 1996
>Last-Modified:
>Originator: Sam Hartman
>Organization:
mit
>Release: 1.0-development
>Environment:
System: SunOS starkiller 5.4 Generic_101945-37 sun4m sparc
>Description:
I don't have time to think about whether this is actually
exploitable right now, but if it is, you might be able to use it to
become root when login_get_v4_tickets is enabled. Basically, I'm not sure there isn't a race involved
when the cache file already exists; here is the code in question:
if (lstat(file,&buf) == 0) {
if (buf.st_uid != me || !(buf.st_mode & S_IFREG) ||
buf.st_mode & 077) {
if (krb_debug)
fprintf(stderr,"Error initializing %s",file);
return(KFAILURE);
}
/* file already exists, and permissions appear ok, so nuke it */
if ((fd = open(file, O_RDWR|O_SYNC, 0)) < 0)
goto out; /* can't zero it, but we can still try truncating it */
Actually, there is certainly a race there. I think if you win
the race, you can get an arbitrary file written over with something
starting with your name. Of course, your name is a string you have
some control over.
Anyway, Ted, I would appreciate it if you could decide
whether this is actually important. I don't have time to write up an
exploit to try and win the race, and since you might be able to get
root or overwrite important files, I'd rather you make the call on
whether this should be fixed now.
>How-To-Repeat:
>Fix:
If the file exists and is not owned by the effective user id,
consider failing. If you don't fail, then you should
go through a complicated procedure involving running lstat on the
file, opening it, running fstat, comparing inodes, zeroing the data,
closing, unlinking, and creating exclusive.
Note that there is still a race before the unlink, but this isn't
really a big deal, because the worst case is you blast a Symlink.
>Audit-Trail:
>Unformatted:
