[8365] in bugtraq
Re: Sendmail, lynx, Netscape, sshd, Linux kernel (twice)
daemon@ATHENA.MIT.EDU (Pavel Kankovsky)
Tue Nov 3 15:01:39 1998
Date: Mon, 2 Nov 1998 20:10:02 +0100
Reply-To: peak@kerberos.troja.mff.cuni.cz
From: Pavel Kankovsky <peak@KERBEROS.TROJA.MFF.CUNI.CZ>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.LNX.4.00.9809060047320.1137-100000@lcamtuf.ids.pl>
On Sun, 6 Sep 1998, Michal Zalewski wrote:
> Maybe some sshd 1.x/2.0 stupidities:
> ------------------------------------
>
> Unprivledged luser could create symlink in ~/.ssh (or ~/.sshd) to
> virtually any file - root's ~/.ssh entries, /dev/urandom or anything else.
> Sshd, during login attempt, but before any authorization, will happily
> read these files, ignoring ownership (yep, it's running at UID 0). Could
> be dangerous, could be not. But even if not, still allows some interesting
> DoSes from privledged UID.
sshd (at least the late versions of 1.2) invokes an extra process
assuming the right privs to read these files. Have you actually tried
this?
machine1:~/.ssh $ ls -lL
...
-r-------- 1 root sys 9393 Nov 2 17:21 authorized_keys
machine2:~ $ slogin -v machine1
...
machine1: Remote: Could not open /home/xxxx/.ssh/authorized_keys for reading.
...
Credits to some inhabitant of comp.security.ssh.
> Linux kernel: execve & non-readable executables
> -----------------------------------------------
>
> Days ago - discussion about dumping executable-only processes using
> linker tricks. Don't force open doors. This process, just like any
> other, has 'dumpable' flag set to 1, and it could be ptraced (and
> coure could be dumped). Of course, it SHOULD be threated just like
> setuid process. Solution: http://dione.ids.pl/~lcamtuf/pliki/noreadx.c
<quote1>
int init_module(void) {
access=sys_call_table[__NR_access];
while (sys_call_table[__NR_myexecve--]);
sys_call_table[__NR_myexecve]=sys_call_table[__NR_execve];
sys_call_table[__NR_execve]=_new_execve;
return 0;
}
</quote1>
Hmm, hmm... is this supposed to be a protection against lusers or
against lamers? Anyone can use the simple trial-and-error approach to find
the old syscall and invoke it, avoiding any extra checks the module does.
<quote2>
NOTE: This fix has nothing to do with linker problems
reported recently on BUGTRAQ.
</quote2>
Any patch of this kind is useless unless 1. the dynamic linker is fixed,
2. all unreadable binaries are statically linked.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"You can't be truly paranoid unless you're sure they have already got you."
