[BBLISA] Appreciate the help...

[Daniel Hagerty]

Daniel Feenberg <feenberg at nber.org> writes:

> Seems fairly similar to me. The major difference is that for the cron 
> attack the user has to make the mistake of pointing a cronjob to a that is 
> world-writable in some sense, while in the sendmail case the mistake might 
> be having a user created ,forward world writable, or possibly having a 
> world writable directory that sendmail might look for a .forward in. The 
> latter is possibly a sys-admin's mistake. The exposure is similar, and 
> sendmail is obviously "checking up" on a situation that shouldn't exist, 
> so it could be considered unnecessary. Cron doesn't check.

    As somebody else pointed out, it can't, at least in any reliable
way (I personally try to forget about the existence of sh -c, but
that's not a good idea when auditing).

    Cron has no idea what the command portion of a crontab means.
It's blindly passing the string to $SHELL -c for interpretation.  Note
$SHELL; it could be bash, it could be tcsh, it could be something
truly insane like scsh (not likely), each of these having wildly
different semantics for "which parts of this string get passed to
exec()?" (note plural).

    Scott's real issue is that the exec*() system calls will happily
execute things in situations he doesn't consider safe.  If you try to
fix it somewhere else, you might reduce the problem footprint, but
there will still be plenty of situations where user B can impersonate
user A because of a mistake rooted in A's cron usage.

    Maybe SE-Linux has some story for this.

    Nonetheless, this ought to be the hint that you should be
investigating completely different routes more deeply.