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

From: Pavel Kankovsky (peakat_private)
Date: Mon Nov 02 1998 - 11:10:02 PST

  • Next message: Joel Eriksson: "mpg123-0.59k bufferoverflow."

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



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:21:39 PDT