[BBLISA] Appreciate the help...

[Daniel Feenberg]

On Thu, 24 Jan 2008, John Stoffel wrote:

>>>>>> "Daniel" == Daniel Feenberg <feenberg at nber.org> writes:
>
> Heh... I'm going to write about the security here, not about Scott and
> how he asks questions.  :]
>
> Daniel> Like you, I don't understand why Scott doesn't answer
> Daniel> directly, but the rationale seems obvious enough. If Sendmail
> Daniel> won't obey a .forward in a group or world writable directory
> Daniel> (for fear that a trojan may executed from that file), why
> Daniel> should cron be less carefull?
>
> Because sendmail has to parse and handle potentially insecure email
> that was sent by someone malicious.  So sendmail tries to be good by
> refusing to allow unsafe things to happen due to outside interference.

Yes, but sendmail only executes the program named in the .forward, so the 
content of the mail is not really at issue. I think sendmail is worried 
that if .forward is writable by all, then any user can impersonate any 
other user by (1) placing a program in the other user's .forward and then 
(2) sending a message to the user. The content of the message doesn't 
really matter. I suppose it is possible to imagine a .forward that 
processes the messages and provides a convinient way for the intruder to 
send instructions to the trojan, but since the the intruder needed to be 
on the system and able to write to the .forward, no new real vulnerability 
is created.

>
> In this case, a world writeable directory means that someone could
> have sendmail forward all your email to someone else.  Not good.
>

World writable really only means "writable by anyone with an account on 
this system", so when I say "intruder" it might be a legit user with 
malicious intent. But the larger point is that hijacking email is only one 
of many possible problems if one user can adopt the permissions of another 
user.

> Cron, on the other hand, can only be setup and run by the user
> (ignoring root) and cannot be run because a user leaves a world
> writeable directory around.  Cron runs a specific program, not a
> generic one.
>

Cron runs a specific program only in the sense that the name must be 
specific. If the directory is world writable, then anyone with a user 
account could modify the program to be anything at all, including a shell 
reading commands from another user.

> Daniel> It seems like a reasonable question.
>
> Sure, in context.
>
> Daniel> The security problem that sendmail is addressing comes up only
> Daniel> in the presence of a user error, but the same can be said for
> Daniel> cron.
>
> It's not the same issue at all.

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.

Daniel Feenberg

>
> Daniel> Indeed, by extension perhaps chmod should refuse to make
> Daniel> executable such a file, although it would be a nuisance for
> Daniel> chmod to do the obverse check (that there were no executable
> Daniel> files in a directory about to become world writable).
>
> First off, the executable bit on a directory entry means something
> else compared to the executable bit on a file.  Second, making a
> directory world writeable is a more conscious decision here (modulo
> that someone has hacked your account, etc...)
>
> Daniel> It isn't something I would be prepared to tell someone else
> Daniel> they must or must not do this, but it is perhaps worth
> Daniel> thinking about costs and benefits.
>
> Yup, I agree.
>
> John
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>