[BBLISA] Appreciate the help...

[Daniel Feenberg]

On Thu, 24 Jan 2008, Daniel Hagerty wrote:

> 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).
>

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.
>