On Thu, 24 Jan 2008, Daniel Hagerty wrote:
Daniel Feenberg <[EMAIL PROTECTED]> 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).
Agreed - the difference is on the cost side - the benefit would be
similar.
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.
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
