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 attachment 73966 [details, diff] 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.
