Ticket History #144: Potential race in in_tkt in libkrb4 potentially giving write access to a root-owned file

From hartmans@MIT.EDU Sat Nov 2 01:00:20 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id BAA21214 for <bugs@RT-11.MIT.EDU>; Sat, 2 Nov 1996 01:00:19 -0500
Received: from STARKILLER.MIT.EDU by MIT.EDU with SMTP
id AA19418; Sat, 2 Nov 96 01:00:19 EST
Received: by starkiller.MIT.EDU (5.x/4.7) id AA13193; Sat, 2 Nov 1996 01:00:18 -0500
Message-Id: <9611020600.AA13193@starkiller.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
Subject: Potential race in in_tkt in libkrb4 potentially giving write access to a root-owned file
X-Send-Pr-Version: 3.99

mit

System: SunOS starkiller 5.4 Generic_101945-37 sun4m sparc



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.




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.



Responsible-Changed-From-To: tytso->hartmans
Responsible-Changed-By: tlyu
Responsible-Changed-When: Wed Nov 20 13:49:14 1996
Responsible-Changed-Why:
Sam said he'd take this one.

State-Changed-From-To: open-closed
State-Changed-By: hartmans
State-Changed-When: Wed Apr 10 15:58:09 2002
State-Changed-Why:
Tom fixed the stat handling for this.