Bugzilla Bug 113741

In the latest Gentoo release of mit-krb5, ksu doesn't clean up its created
credentials cache upon exit, leaving them in /tmp indefinitely (until tmpwatch
runs). When I ran strace on a running ksu process, this is what happens:

# cat -A strace/ksu 
waitpid(22104, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED) = 22104$
--- SIGCHLD (Child exited) @ 0 (0) ---$
setresuid32(-1, 0, -1)                  = 0$
setresuid32(-1, 0, -1)                  = 0$
stat64("M- ^C^B^A^I^A", 0xbfe761bc)            = -1 ENOENT (No such file or
directory)$
exit_group(0)                           = ?$

I used cat -A to make sure that the control characters in the stat call are
showing. That's an obvious sign of memory corruption, if you ask me. Since ksu
is a SUID root program and it corrupts memory, I'm kind of worried that this
might turn out to be an exploitable bug.

It seems that this problem is limited to Gentoo, since I haven't ever seen it
happen on other distros (including Fedora Core 4 and Ubuntu 5.10). It also
happens on all my Gentoo machines (I have three of them running the latest
mit-krb5 release so far), so it's not just a isolated event.

Auditors, please confirm...

I took the time to debug this, and I found that this was indeed a bug, and that
it was also linked to another bug I had.

The bug was in src/lib/krb5/ccache/cc_file.c, in the dereference() function,
where there is a line like this:
    for (fccsp = &fccs; *fccsp == NULL; fccsp = &(*fccsp)->next)

Obviously, the loop condition shouldn't be "*fccsp == NULL", but "*fccsp !=
NULL". This leads to that the library frees the wrong ccache occasionally
(recurringly in ksu). Therefore, it is a matter of premature freeing of memory,
which may or may not be exploitible.

In any case, the bug is fixed in Kerberos 1.4.3, which, however, hasn't been
released in Gentoo.

If there are no plans to release 1.4.3 in Gentoo anytime soon, I think this bug
should at least be patched, since it not only is a potential security problem,
but also causes a number of other problems:
 * When using ksu, more and more ccache files will gather in /tmp.
 * When using ksu, the source ccache file isn't closed and might remain read
locked, which will cause processes that want to write lock the ccache to sleep
until ksu exits.
 * Might cause programs to segfault. I find it quite strange that lots of
programs haven't already segfaulted left and right, considering that this bug is
freeing the wrong memory. I guess most only keep one ccache file open at a time.

I also realize now that since the source ccache file isn't being closed, it can
lead to the following situation:

User A ksus to user B. User A doesn't fully trust user B, so he runs kdestroy to
make sure that user B can't get hold of his TGT. However, unknowingly to user A,
ksu never closed the source ccache fd, which means that his shell, running as
user B, inherited that fd. User B can now ptrace the shell process and make it
read user A's TGT. User B can now impersonate user A.

This might not be a very common situation, but it isn't exactly impossible either.

Created an attachment (id=73966) [edit]
Fix for the bug

This patch fixes the bug. Apply with -p1 in the src directory.

fix is good, can't comment on exploitability, my knowledge of the usage isn't
good enough.

kerberos please advise.

I'd prefer that upstream advised on this issue. Frederick, have you notified
upstream of this? If not, I'll be contacting them this afternoon.

Upstream has already fixed this bug in later releases of Kerberos. It's just
that while MIT has released Kerberos 1.4.3, Gentoo still only ships 1.4.1.
Thus, it is safe to say that upstream is aware of and has acknowledged this as
a bug.

1.4.3 in portage, marked as ~  when that goes stable, I'll put in a version for
~ which should fix some of the other bugs people are seeing. For the purposes
of security, the 1.4.3 ebuild now in should do.

seemant has committed app-crypt/mit-krb5-1.4.3 to address this issue, moving in
to vulnerabilities for arch stabilisation. 

Calling arches

sparc stable.

ppc64 stable

Stable on hppa

Marked ppc stable.

x86 stable

Stable on alpha + ia64.

mips stable.

amd64 finally stable, sorry for the delay

Ready for GLSA vote

Mhhhh, suid root and memory corruption ... i think it's better to have one, so
a weak yes.

If it was sufficiently exploitable upstream would have had an advisory. I vote
no.

It's been fixed and we dont have any evidence that it is exploitable, so I
would say no need to issue a glsa, weak NO.

#23, it is definitely exploitable, as I showed in #3 (I tried it myself).
That's a rather weak exploit, admittedly, but an exploit nonetheless.

Closing, feel free to reopen if you indended to vote yes.