[3192] in bugtraq
Re: [linux-security] Re: Possible bufferoverflow condition in
daemon@ATHENA.MIT.EDU (Casper Dik)
Sat Aug 17 21:08:42 1996
Date: Fri, 16 Aug 1996 17:59:03 +0200
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Casper Dik <casper@holland.Sun.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In-Reply-To: Your message of "Thu, 15 Aug 1996 11:46:09 CDT."
<199608151646.LAA23929@primus.paranoia.com>
>The problem in mount, aside from the obvious buffer overrun, is that the
>most basic maxim for coding privileged programs was ignored--again. All
>privileged programs should run without those privileges enabled except
>during execution of the critical code that needs them.
>
>For example:
>
>main()
>{
> ... /* variable decls */
> seteuid( getuid() );
> ... /* non-privileged code, including sprintf() */
> seteuid( 0 );
> mount( ... );
> seteuid( getuid() );
> ... /* more non-privileged code */
>}
>
>If mount were written like this, then I seriously doubt that a minor
>bounds-checking goofup could have caused this major security problem.
Sorry, but the latest rdist buffer overflow did happen in code
that had both uids set back to the original user.
If you can exec a shell from the spamming, how difficult do you think it
is to set euid and uid back to zero?
No, the safe set-uid programming paradigm saves you from a lot of trouble,
but not from buffer overflows.
Casper
