On Thu, 24 Dec 1998, Bennett Todd wrote:
> If that were true, then this would be a case of a ghastly system design, that
> could indeed help from a bandaid applied in the OS. But it's not; a CGI bug
> generally means a non-privileged account is compromised, together with
> whatever access to files --- read and/or write --- it needs to function. An
Which normally leads pretty quickly to a root compromise. I've seen
quite a few CGI compromises of servers running as nobody that ended up as
root compromises (thankfully none on my own machines).
For example, write access to a /dev entry that isn't [nosuid,nodev]
automatically wins in a worst-case situation and in all probability compromise
of another non-privileged account from the compromised account will yield
permissions suitable for gaining such access on most systems if you can't do
it from nobody directly.
I'm sure that someone with a lot more creativity than me can come up with
more scenerios that GP OS' don't protect against that are quite normal
even for installations where the administrator has some clue value
greater than 0.
[Yes, I think it's ghastly system design, but it's what we're stuck with]
> admin can surely badly configure an http daemon to run CGIs as root, but
> that's in violent disagreement with some pretty clear documentation:-). And an
> admin could fail to adequately restrict permissions on a system --- but then,
> they could do a poor job of configuring a trusted OS, too. Just that it costs
> more $$$, and you have a more complex ball o' bits, with a trusted OS.
I can also count the number of CGI programmers I've seen with a shell
CGI on one hand [for "emergency fixes"], but again I'd rather that number
were zero. That complex ball o' bits provides significantly higher assurance
than the other complex ball o' bits. This would be especially true in
the service provider arena where other people's scripts abound.
Security almost always costs more than insecurity.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
