Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
On Tue, 25 Jun 2002 14:50:30 + (UTC)
Rob Andrews <[EMAIL PROTECTED]> wrote:
>
> Oh, the package created an 'sshd' user, and set it's homedir to
> $HOMEDIRS/sshd, but didn't create the homedir itself. Since there isn't any
> PoC code to test this with, I don't know how the chroot will end up. Anyone
> got any ideas? I'd hate for the sandbox to end up being /.
I installed it on woody, no problem (I didn't understand what's the problem
with PAM, I have the default config with no authentification I can
think at other than /etc/passwd and /etc/shadow)
Indeed it's using a chroot call relatively early, it changes the user to sshd
and the group to nogroup :
[pid 11197] chroot("/var/run/sshd") = 0
[pid 11197] chdir("/") = 0
[pid 11197] getuid32() = 0
[pid 11197] setgid32(0xfffe)= 0
[pid 11197] open("/etc/group", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 11197] setgroups32(0x1, 0x8094128) = 0
[pid 11197] setgid32(0xfffe)= 0
[pid 11197] setuid32(0x6d) = 0
[pid 11197] getuid32() = 109
[pid 11197] geteuid32() = 109
Alain
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
On Tue, 2002-06-25 at 18:27, Tycho Fruru wrote: > In the "recommended" config it would be something like "/var/empty", not > writable by the sshd user. I don't have a system handy to verify > whether the package does the right thing here though. The debian package chroots to the empty and root:root owned dir /var/run/sshd I myself changed this to root:sys, but that shouldn't really matter. -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl signature.asc Description: This is a digitally signed message part
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
On Tue, 2002-06-25 at 16:50, Rob Andrews wrote: > [Raymond Wood wrote in newsgate.debian.security] > > Potato and Woody are both patched then. What is the recommended > > course of action for those running Sid? Should Sid users > > install the Woody patch, or is this a bad idea? > > Personally, I've dist-upgraded all woody and sid boxen I have, the sid > machines took the woody package without trouble. Just set PAM auth by > keyboard interactive to "no" and left it to it. > > Oh, the package created an 'sshd' user, and set it's homedir to > $HOMEDIRS/sshd, but didn't create the homedir itself. Since there isn't any > PoC code to test this with, I don't know how the chroot will end up. Anyone > got any ideas? I'd hate for the sandbox to end up being /. In the "recommended" config it would be something like "/var/empty", not writable by the sshd user. I don't have a system handy to verify whether the package does the right thing here though. Cheers, Tycho -- Tycho Fruru [EMAIL PROTECTED] "Prediction is extremely difficult. Especially about the future." - Niels Bohr signature.asc Description: This is a digitally signed message part
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
[Raymond Wood wrote in newsgate.debian.security] > Potato and Woody are both patched then. What is the recommended > course of action for those running Sid? Should Sid users > install the Woody patch, or is this a bad idea? Personally, I've dist-upgraded all woody and sid boxen I have, the sid machines took the woody package without trouble. Just set PAM auth by keyboard interactive to "no" and left it to it. Oh, the package created an 'sshd' user, and set it's homedir to $HOMEDIRS/sshd, but didn't create the homedir itself. Since there isn't any PoC code to test this with, I don't know how the chroot will end up. Anyone got any ideas? I'd hate for the sandbox to end up being /. -- rob [EMAIL PROTECTED] 0x8bb5c71e -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
This one time, at band camp, Raymond Wood said: > Potato and Woody are both patched then. What is the recommended > course of action for those running Sid? Should Sid users > install the Woody patch, or is this a bad idea? > > Thanks for all the hard work Debian Security people! > > Cheers, > Raymond I would think that would be an excellent idea. This: deb http://security.debian.org/ woody/updates main contrib non-free will get you the security updates you need. Cheers, Steve -- So live that you wouldn't be ashamed to sell the family parrot to the town gossip. pgpmmaEZXr5Va.pgp Description: PGP signature
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
On Tue, Jun 25, 2002 at 09:37:26AM -0500, kruskal wrote: > So it looks to me like priv sep is working on potato. At this point, > is it safe to open up a public server? Since the OpenSSH developers and some folks at ISS are the only people who know the nature of the problem, they're the only people who can tell you. But they're not telling anybody. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpDe2NV3dUht.pgp Description: PGP signature
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
Mark Janssen <[EMAIL PROTECTED]> writes: > On Tue, 2002-06-25 at 15:57, Kruskal wrote: > > Has anyone applied this update yet? I did so on a potato box, enabled > > priv separation in the sshd config file and restarted sshd. I saw > > that a user called sshd was created. However, when I ssh'ed in, I > > didn't see any processes owned by sshd. In fact, the ssh daemon > > process was still owned by root. > > I noticed this as well.. and decided to roll my own version, and include > a patch for setproctitle support, this to aide debugging. > > It in fact does work, but the 'sshd' process from the 'sshd' user only > exists before login. Looks like this is the way it happens under potato as well. Looking into it, I see the initial sshd sitting idle created by root. Then when I initially connect, but before I am authenticated, a child process owned by sshd is created. ps fauwx looks like: root 8159 1.0 0.6 2544 1228 ?S09:20 0:00 /usr/sbin/sshd root 8162 1.1 0.8 4380 1596 ?S09:21 0:00 \_ /usr/sbin/sshd sshd 8163 5.5 0.7 3964 1472 ?S09:21 0:00 \_ /usr/sbin/sshd Then when I give the password, that sshd owned process goes away, leaving: root 8159 0.5 0.6 2544 1228 ?S09:20 0:00 /usr/sbin/sshd root 8162 0.2 0.8 5620 1680 ?S09:21 0:00 \_ /usr/sbin/sshd user 8166 0.3 0.9 5632 1752 ?S09:21 0:00 \_ /usr/sbin/sshd user 8167 1.0 0.6 2016 1240 pts/0S09:21 0:00 \_ -bash So it looks to me like priv sep is working on potato. At this point, is it safe to open up a public server? -- --Kruskal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
On Tue, Jun 25, 2002 at 02:37:12PM +0200, Wichert Akkerman remarked: > -BEGIN PGP SIGNED MESSAGE- > > - > Debian Security Advisory DSA-134-2 [EMAIL PROTECTED] > http://www.debian.org/security/ Wichert Akkerman > June 25, 2002 > - > > > Package: ssh > Problem type : remote exploit > Debian-specific: no > > This advisory is an update to DSA-134-1: some extra information is > provided on broken or changed functionality in this new release and > packages for Debian GNU/Linux 2.2/potato are now available. [snip] > wget url > will fetch the file for you > dpkg -i file.deb > will install the referenced file. > > > Debian GNU/Linux 2.2 alias potato > - - > > Potato was released for alpha, arm, i386, m68k, powerpc and sparc > Packages for m68k are not available at this moment. [snip] > Debian GNU/Linux 3.0 alias woody > - - > > Woody will be released for alpha, arm, hppa, i386, ia64, m68k, mips, > mipsel, powerpc, s390 and sparc. Packages for m68k are not available > at this moment. [snip] Potato and Woody are both patched then. What is the recommended course of action for those running Sid? Should Sid users install the Woody patch, or is this a bad idea? Thanks for all the hard work Debian Security people! Cheers, Raymond pgpal2czmlTwx.pgp Description: PGP signature
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
I have prefered wait a real bugfixe and in waiting I have installed telnetd-ssl and block all ssh traffic in the firewalls On Tue, 2002-06-25 at 15:57, Kruskal wrote: > Wichert Akkerman <[EMAIL PROTECTED]> writes: > > > > > Debian Security Advisory DSA-134-2 [EMAIL PROTECTED] > > http://www.debian.org/security/ Wichert Akkerman > > June 25, 2002 > > > > > > > > Package: ssh > > Problem type : remote exploit > > Debian-specific: no > > Has anyone applied this update yet? I did so on a potato box, enabled > priv separation in the sshd config file and restarted sshd. I saw > that a user called sshd was created. However, when I ssh'ed in, I > didn't see any processes owned by sshd. In fact, the ssh daemon > process was still owned by root. > > Anybody have any thoughts on this? Does priv sep work in potato? > > -- > --Kruskal > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- francois bayart avence [ electro-communication ] · 217 rue saint-honoré · 75001 paris france http://www.avence.com · tel: +(33) 1-4927-9830 · fax: +(33) 1-4927-9894 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
On Tue, 2002-06-25 at 15:57, Kruskal wrote: > Has anyone applied this update yet? I did so on a potato box, enabled > priv separation in the sshd config file and restarted sshd. I saw > that a user called sshd was created. However, when I ssh'ed in, I > didn't see any processes owned by sshd. In fact, the ssh daemon > process was still owned by root. I noticed this as well.. and decided to roll my own version, and include a patch for setproctitle support, this to aide debugging. It in fact does work, but the 'sshd' process from the 'sshd' user only exists before login. If you connect to the ssh daemon it will fork off this process, if you do a ps-listing at this stage you will see it. As soon as you log in, this process will be replaced by a process running as your user account. You can also see that the 'priv' process (running as root) will be chrooted in /var/run/sshd This was/is all in woody, but I suspect potato to act the same :) -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-134-2] Unknown OpenSSH remote vulnerability
Wichert Akkerman <[EMAIL PROTECTED]> writes: > > Debian Security Advisory DSA-134-2 [EMAIL PROTECTED] > http://www.debian.org/security/ Wichert Akkerman > June 25, 2002 > > > > Package: ssh > Problem type : remote exploit > Debian-specific: no Has anyone applied this update yet? I did so on a potato box, enabled priv separation in the sshd config file and restarted sshd. I saw that a user called sshd was created. However, when I ssh'ed in, I didn't see any processes owned by sshd. In fact, the ssh daemon process was still owned by root. Anybody have any thoughts on this? Does priv sep work in potato? -- --Kruskal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
