Re: Sendmail, lynx, Netscape, sshd, Linux kernel (twice)

[peak () kerberos troja mff cuni cz (Pavel Kankovsky)]

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."