Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



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

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

From: Pavel Kankovsky <peak_at_kerberos.troja.mff.cuni.cz>
Date: Mon, 2 Nov 1998 20:10:02 +0100

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."
Received on Nov 03 1998

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]