On Thu, 24 Jan 2008, John Stoffel wrote:
"Daniel" == Daniel Feenberg <[EMAIL PROTECTED]> 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
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
