[1264] in Release_7.7_team
security hole in access_on (the sshd version)
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Fri Apr 24 00:50:44 1998
From: <mhpower@MIT.EDU>
To: source-reviewers@MIT.EDU, quality@MIT.EDU
Cc: athena-ws@MIT.EDU, release-team@MIT.EDU
In-Reply-To: "[2034] in Source-Reviewers",
"[1999] in Athena Workstation",
"[1251] in Release_7.7_team"
Date: Fri, 24 Apr 1998 00:50:32 EDT
access_off, as built from the current sources, apparently allows users
to start /etc/athena/sshd running as root with arbitrary entries in
the environment. This is a problem because if a user is logged in on a
machine without an sshd running that's configured to allow switching
sshd on, apparently they can (for example) put a suitable value of
LD_PRELOAD into their environment and cause their execution of
access_off to run arbitrary code as root. For example, on Solaris
echo 'int freopen(){chmod("/etc",0777);}' > foo.c
gcc -B/usr/ccs/bin/ -fpic -c foo.c
/usr/ccs/bin/ld -G -o /tmp/foo.so foo.o
setenv LD_PRELOAD /tmp/foo.so
access_on
The patch is relative to /mit/source/athena/bin/access/access_off.c
Matt
*** access_off.c.old Thu Apr 16 22:43:40 1998
--- access_off.c Thu Apr 23 23:25:01 1998
***************
*** 97,98 ****
--- 97,101 ----
{
+ char *a[2];
+ char *e[1];
+
/* Make ruid and saved uid equal to effective uid before exec,
***************
*** 100,102 ****
setuid(geteuid());
! execl("/etc/athena/sshd", "sshd", (char *) NULL);
perror("Error running sshd");
--- 103,108 ----
setuid(geteuid());
! a[0] = "sshd";
! a[1] = (char *) NULL;
! e[0] = (char *) NULL;
! execve("/etc/athena/sshd", a, e);
perror("Error running sshd");
