Re: [d-security] Re: DSA-134-1
Previously Christian Hammers wrote: Don't be too hard to him, if he'd pointed out that only default BSD is vulnerable it would not have been too hard to find the exploit before everybody had updated. He could have mentioned ssh protocol 1 wasn't vulnerable.. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: DSA-134-1
Wichert Akkerman [EMAIL PROTECTED] writes: Previously Christian Hammers wrote: Don't be too hard to him, if he'd pointed out that only default BSD is vulnerable it would not have been too hard to find the exploit before everybody had updated. He could have mentioned ssh protocol 1 wasn't vulnerable.. At the very least. I'm trying not to think how many Debian policies have been bent because of oh no! it's ssh!-factor - porting a protocol-2-enabled *new feature* down to Stable with the resultant paragraphs on `create a proto-2 keypair' and `these are untested' in the DSA causes inconvenience to folks running Stable+Secure boxes, in addition to those of us using Testing but keeping an eye on DSAs. And we're all going to have to upgrade again when 3.4 comes out properly as it is... Could I suggest that `until we're told what it is, there is no problem' be considered as an approach? ;/ ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: DSA-134-1
On Thu, Jun 27, 2002 at 09:12:41AM +0100, Tim Haynes wrote: I'm trying not to think how many Debian policies have been bent because of oh no! it's ssh!-factor - porting a protocol-2-enabled *new feature* down to Stable with the resultant paragraphs on `create a proto-2 keypair' and `these are untested' in the DSA causes inconvenience to folks running Stable+Secure boxes, in addition to those of us using Testing but keeping an eye on DSAs. And we're all going to have to upgrade again when 3.4 comes out properly as it is... Might I suggest you consider dpkg --force-downgrade smile If not you will be running around next week when our good friend Theo finds a vulnerability in 3.4...just a thought Phil pgpO3KyAGtmJz.pgp Description: PGP signature
Re: DSA-134-1
Florian Weimer [EMAIL PROTECTED] writes: Wichert Akkerman [EMAIL PROTECTED] writes: Definitely. I really wish we could do more but the complete lack of more information we have make things difficult. Backporting OpenSSH 3.3p1 to to potato is also slightly complicated by missing build dependencies, but we hope to have packages ready sometime tomorrow. Is this worth the effort if there's still a remote nobody exploit? At least that's the way understand the DSA. Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole exercise was rather pointless. Thanks, Theo. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
On Wed, 2002-06-26 at 13:23, Florian Weimer wrote: Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole exercise was rather pointless. Thanks, Theo. Worst advisory ever. -m -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: DSA-134-1
On Wed, Jun 26, 2002 at 07:23:49PM +0200, Florian Weimer wrote: Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole exercise was rather pointless. But drill inspector Theo (update and don't ask questions, soldier!), showed at least how good our new security upload architecture and how fast the security team is *g* Thanks, Theo. Don't be too hard to him, if he'd pointed out that only default BSD is vulnerable it would not have been too hard to find the exploit before everybody had updated. bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
El mar, 25-06-2002 a las 12:40, Robert van der Meulen escribió: and disclosure is only done when it doesn't affect openbsd (or the '5 years without..' line on openbsd.org). You'll love this one: One remote hole in the default install, in nearly 6 years! Great X'DD Depending on the language you see their web on, it may or may not have already changed... Luis -- Luis Gómez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
Previously Anthony DeRobertis wrote: $VENDOR says it's broken $VENDOR won't provide details $VENDOR says upgrade two minor releases $VENDOR says upgrading doesn't actually fix the problem $VENDOR says upgrading will break things Woody security update comes out before potato one. Lovely situation, isn't it? Doesn't OpenBSD have a full-disclosure policy anyway? -- Paul Haesler[EMAIL PROTECTED] ICQ: 124547085 Neutrons are wormholes. And if Blanca's dead clone was right, the Transmuters had all the degrees of freedom they could need to make Swift's neutrons unique. - Yatima, in Greg Egan's Diaspora. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
Quoting Paul Haesler ([EMAIL PROTECTED]): Doesn't OpenBSD have a full-disclosure policy anyway? It has 'listen to theo or fuck off' disclosure policy, which basically means you have to do what theo says, and no matter what you do, you'll end up with problems and bitching, and disclosure is only done when it doesn't affect openbsd (or the '5 years without..' line on openbsd.org). Greets, Robert -- ( o Linux Generation o ) ///\finger [EMAIL PROTECTED] for my GnuPG/PGP key./\\\ \V_/ By default, there is only one account (root) with no password, \_V/ as with most UNIX systems. -- the Darwin FAQ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
Wichert Akkerman [EMAIL PROTECTED] writes: Definitely. I really wish we could do more but the complete lack of more information we have make things difficult. Backporting OpenSSH 3.3p1 to to potato is also slightly complicated by missing build dependencies, but we hope to have packages ready sometime tomorrow. Is this worth the effort if there's still a remote nobody exploit? At least that's the way understand the DSA. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
Hi, Florian Weimer wrote: Is this worth the effort if there's still a remote nobody exploit? At least that's the way understand the DSA. i unterstand it as remote chrooted nobody exploit, this is much more better than a remote root-exploit. bye, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
At 15:10 Uhr +0200 25.06.2002, Ralf Dreibrodt wrote: i unterstand it as remote chrooted nobody exploit, this is much more better than a remote root-exploit. Hmm, I'm wondering if it's any better: if the attacker manages code to run in the chrooted daemon, I suspect he can also advise the part running as root to open up a new root connection? Isn't it that the separation simply protects against direct shell launch attacks? Well I'm not educated enough to know, just wondering. Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
Hi, Christian Jaeger wrote: Hmm, I'm wondering if it's any better: if the attacker manages code to run in the chrooted daemon, I suspect he can also advise the part running as root to open up a new root connection? Isn't it that the separation simply protects against direct shell launch attacks? Well I'm not educated enough to know, just wondering. just imagine: i login as root. su to ralf (man su) ralf executes any buggy programm, where someone else can insert shellcode. (e.g. chmod 777 /home/ralf -R; /home/ralf/myshellscript.sh) this shellcode is executed as user ralf, not as user root. there is no chance to execute the shellcode, which inserted any other user in /home/ralf/myshellscript.sh) as root, although i logged in as root. (if we assume that there is no bug in su) bye Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
On Tue, Jun 25, 2002 at 05:16:51PM +0200, Ralf Dreibrodt wrote: just imagine: i login as root. su to ralf (man su) ralf executes any buggy programm, where someone else can insert shellcode. (e.g. chmod 777 /home/ralf -R; /home/ralf/myshellscript.sh) this shellcode is executed as user ralf, not as user root. there is no chance to execute the shellcode, which inserted any other user in /home/ralf/myshellscript.sh) as root, although i logged in as root. (if we assume that there is no bug in su) *TECHNICALLY* every login is root. Getty runs as root and then gives up root to the authenticated user once PAM gives the okay...Does this mean the user can break back into root? If the exit their shell (Ctrl + D, or pick your choice of logout method...) then Getty immediately respawns Phil pgpqDLN836eAh.pgp Description: PGP signature
Re: DSA-134-1
On Tue, 2002-06-25 at 18:11, Phillip Hofmeister wrote: *TECHNICALLY* every login is root. Getty runs as root and then gives up root to the authenticated user once PAM gives the okay...Does this mean the user can break back into root? If the exit their shell (Ctrl + D, or pick your choice of logout method...) then Getty immediately respawns No... getty exec's a shell (or a login actually) and when this exits the inetd restarts the getty. :) -- 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: DSA-134-1
Hi, Mark Janssen wrote: On Tue, 2002-06-25 at 18:11, Phillip Hofmeister wrote: *TECHNICALLY* every login is root. Getty runs as root and then gives up root to the authenticated user once PAM gives the okay...Does this mean the user can break back into root? If the exit their shell (Ctrl + D, or pick your choice of logout method...) then Getty immediately respawns No... getty exec's a shell (or a login actually) and when this exits the inetd restarts the getty. :) inetd? you mean init ;) btw the respawn is only done, if you have the word respawn in /etc/inittab before :/sbin/getty. but getty has not to run with _all_ root-privileges, it just has to run as user root with some root-privileges. for more info about this, have a look at http://www.lids.org bye Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
also sprach Ralf Dreibrodt [EMAIL PROTECTED] [2002.06.25.1510 +0200]: i unterstand it as remote chrooted nobody exploit, this is much more better than a remote root-exploit. better in what way? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] there are two major products that come out of berkeley: lsd and unix. we don't believe this to be a coincidence. -- jeremy s. anderson pgpMIoII7mHBE.pgp Description: PGP signature
Re: DSA-134-1
Theo de Raadt said in a post to Bugtraq the exploit won't work on sshd with privilege seperation enabled, however even if it did work it'd be better to have an attacker get a chrooted shell with no privs instead of root access to the entire system. i unterstand it as remote chrooted nobody exploit, this is much more better than a remote root-exploit. better in what way? -- --SupplyEdge--- Greg Hunt 800-733-3380 x 107 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
i unterstand it as remote chrooted nobody exploit, this is much more better than a remote root-exploit. better in what way? Theo de Raadt said in a post to Bugtraq the exploit won't work on sshd with privilege seperation enabled, however even if it did work it'd be better to have an attacker get a chrooted shell with no privs instead of root access to the entire system. In which case you just need a local exploit to go with your remote exploit. makes it harder but not impossible. /James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
James Nord [EMAIL PROTECTED] writes: Theo de Raadt said in a post to Bugtraq the exploit won't work on sshd with privilege seperation enabled, however even if it did work it'd be better to have an attacker get a chrooted shell with no privs instead of root access to the entire system. In which case you just need a local exploit to go with your remote exploit. Or you don't care about the local system ressources at all and just abuse the network (like some Code Red variant did). -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
On Tue, Jun 25, 2002 at 11:58:13PM +0200, James Nord wrote: In which case you just need a local exploit to go with your remote exploit. A local exploit that can be run by a non-root user in an empty chroot. Those are considerably harder to come by than the standard local exploit. Are any known to exist at all? noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpdQ2zhSlIxZ.pgp Description: PGP signature
Re: DSA-134-1
On Tue, Jun 25, 2002 at 06:01:36PM -0400, Noah L. Meyerhans wrote: A local exploit that can be run by a non-root user in an empty chroot. Oh, and I forgot to mention that non-root user does not have write permissions on the chroot. There's really not much you can do with such an environment. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpKtOq0vKt81.pgp Description: PGP signature
Re: DSA-134-1
Noah L. Meyerhans [EMAIL PROTECTED] writes: A local exploit that can be run by a non-root user in an empty chroot. Those are considerably harder to come by than the standard local exploit. Are any known to exist at all? Have you examined all those signedness bugs in the kernel which have been fixed based on results from the checker project? :-/ -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
Yes it's still not a good thing for sometime to have a shell with no priv's but someone asked better how?, I'm pretty sure if most admins had a choice between an attacker having root access or an attacker having a chrooted shell with no privs they would choose the latter. Seeing as how there isn't a patch yet for the bug, it's this or nothing. -Greg Theo de Raadt said in a post to Bugtraq the exploit won't work on sshd with privilege seperation enabled, however even if it did work it'd be better to have an attacker get a chrooted shell with no privs instead of root access to the entire system. In which case you just need a local exploit to go with your remote exploit. makes it harder but not impossible. -- --SupplyEdge--- Greg Hunt 800-733-3380 x 107 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
At 17:16 Uhr +0200 25.06.2002, Ralf Dreibrodt wrote: this shellcode is executed as user ralf, not as user root. I'm not worried about a shell spawned by the chrooted process. Chroot and su to some undangerous user helps if that's one-way only, i.e. the process doesn't have any connection to sensitive areas anymore. But in the case of sshd, it's not one-way: as far as I understand, the process running in the chroot as 'sshd' (say process 2) user does the communication with the client, but, and that's the problem, it does have a connection with a sister process running as root (say process 1) which it tells to launch a login shell for the user requested by the client. Normally, process 2 would of course only advise process 1 to do that if the remote client correctly identifies itself/gives the password. But if a malicious client submits data that corrupts process 2, he could make it to tell process 1 to launch a login shell for root. How should process 1 find out whether process 2 has been corrupted? (Well, it would be easy if logins are username/password only: if the check for correct username/password is done by process 1, process 2 has to provide them which it can't if the cracker doesn't know them anyway. But since ssh also allows public-key based logins, and I would guess that the key check is done by process 2, it looks different. Sorry if this starts to be OT.) Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
Well I'm not an open-bsd developer nor have I looked through the privilege seperation code so I only know what I read at http://www.citi.umich.edu/u/provos/ssh/privsep.html but according to that site (linked to from openssh.com) the privileged process (process 1) forks the unprivileged child (process 2) when a connection is made, this child talks to the client and requests authentication from the parent. If the authentication is sucessfull the parent passes the child a PTY, if not there's not much the child process can do. The child itself is never able to say give me a root shell, or give me a shell for user xyz so the child becoming corrupted doesn't compromise the security of the whole system (that's the point of priv seperation). -Greg PS: the site linked to above does a much better job of explaining this this shellcode is executed as user ralf, not as user root. I'm not worried about a shell spawned by the chrooted process. Chroot and su to some undangerous user helps if that's one-way only, i.e. the process doesn't have any connection to sensitive areas anymore. But in the case of sshd, it's not one-way: as far as I understand, the process running in the chroot as 'sshd' (say process 2) user does the communication with the client, but, and that's the problem, it does have a connection with a sister process running as root (say process 1) which it tells to launch a login shell for the user requested by the client. Normally, process 2 would of course only advise process 1 to do that if the remote client correctly identifies itself/gives the password. But if a malicious client submits data that corrupts process 2, he could make it to tell process 1 to launch a login shell for root. How should process 1 find out whether process 2 has been corrupted? (Well, it would be easy if logins are username/password only: if the check for correct username/password is done by process 1, process 2 has to provide them which it can't if the cracker doesn't know them anyway. But since ssh also allows public-key based logins, and I would guess that the key check is done by process 2, it looks different. Sorry if this starts to be OT.) Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- --SupplyEdge--- Greg Hunt 800-733-3380 x 107 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
At 1:01 Uhr +0200 26.06.2002, Christian Jaeger wrote: (Well, it would be easy if logins are username/password only: if the check for correct username/password is done by process 1, process 2 has to provide them which it can't if the cracker doesn't know them anyway. But since ssh also allows public-key based logins, and I would guess that the key check is done by process 2, it looks different. Sorry if this starts to be OT.) Replying to myself: even in the case of public-key authentification the work is done in process 1. (Well of course it has to be done there since only process 1 does have access to the public keys :o) There's a link to http://www.citi.umich.edu/u/provos/ssh/privsep.html on www.openssh.org now, which also explains it a bit. (BTW I've noticed that the child process is really just a forked copy of the parent, so both processes do have the same code. (Which is not any risk in itself of course.)) Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
Previously Anthony DeRobertis wrote: $VENDOR says it's broken $VENDOR won't provide details $VENDOR says upgrade two minor releases $VENDOR says upgrading doesn't actually fix the problem $VENDOR says upgrading will break things Woody security update comes out before potato one. Lovely situation, isn't it? That makes for the weirdest DSA I can remember. Definitely. I really wish we could do more but the complete lack of more information we have make things difficult. Backporting OpenSSH 3.3p1 to to potato is also slightly complicated by missing build dependencies, but we hope to have packages ready sometime tomorrow. PS: With the Apache hole and then this, when was the last time you got any sleep, Wichert? This was my daytime, and most of the work was done by Daniel Jacobowitz. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
