I recently noticed a security exploit involving cron and
/dev/caphash. The problem is that when running jobs on the
machine "local" (meaning creating the job via fork+exec
instead of rexexec), cron leaves /dev/caphash open for
writing as fd 3 in the cron job. So anyone who can create a
"local" cron job can become an arbitrary user during that
cron job (and then steal credentials by looking at nvram).
The traditional remote execution isn't affected because it
doesn't inherit file descriptors like fork+exec does. The
only other program that keeps /dev/caphash open is factotum,
and it never does fork+exec for arbitrary people, so I'm
confident cron is the only instance of this kind of mistake.

This is a privilege escalation issue (i.e. the bad guy has
to already have a local login) and is not remotely
exploitable. Also you have to be running cron and allow
untrusted users to have crontabs. I have no evidence that
this has ever been used in the wild -- I noticed it by
accident looking at /proc/$pid/fd of one of my cron jobs on
a standalone system. You could grep 'on local'
/sys/log/cron for suspicious entries, but only if an
attacker didn't clean up after himself.

The bug has existed since I added "local" to cron on 2003/09/18.
There are two possible fixes, both on sources since May 4.
Either suffices to close the hole:

diff /n/dump/2007/0504/sys/src/9/port/devcap.c /sys/src/9/port/devcap.c
> if(!iseve())
> error(Eperm);

diff /n/dump/2007/0504/sys/src/cmd/auth/cron.c /sys/src/cmd/auth/cron.c
< caphashfd = open("#¤/caphash", OWRITE);
> caphashfd = open("#¤/caphash", OCEXEC|OWRITE);

The devcap change eliminates this entire class of bug;
the cron change fixes the specific instance in cron.
There is a new cron binary on sources too.

I just put new kernels on sources too. There haven't
been new kernels since October, so you might find
other things different too, hopefully all good.