the openssh exploit
Does anyone know if the openssh exploit that 3.3 is supposed to not fix, but do damage control for, is it still exploitable if you have set your /etc/hosts.deny to deny all hosts, and then /etc/hosts.allow to only allow from trusted ips. In other words, if a malicious ssh request comes from an ip that is already denied via tcp_wrapper support in ssh, will it still be able to exploit OpenSSH 3.3? I'm not on the list, so cc me please. -- Paul Baker They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: open ssh exploit - user not getting created
I was a little hasty in my first reply. It is a noted bug (http://bugzilla.mindrot.org/show_bug.cgi?id=285) Disabling compression will solve the problem on 2.2.x kernels. (Compression no) Hope that helps you. On Mon, 2002-06-24 at 20:49, buggz wrote: Does 3.3 work w/ 2.20 kernels ? Jun 23 10:11:38 buggz1 sshd[9598]: fatal: mmap(65536): Invalid argument I get that everytime I try connecting. -- -- Ed June -o) /\ buggz at america dot net _\_v Linux: An open choice for free people worldwide. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the openssh exploit
On Mon, 24 Jun 2002 23:00:46 -0500 Paul Baker [EMAIL PROTECTED] wrote: In other words, if a malicious ssh request comes from an ip that is already denied via tcp_wrapper support in ssh, will it still be able to exploit OpenSSH 3.3? We have no way of being sure, since the nature of the exploit and the specifics aren't being told. However, supposedly, you need to be able to talk to the sshd in order to exploit it. So if nothing (or nothing malicious) can open a connection, you're fine. -- \ David B. Harris, Systems administrator | http://www.terrabox.com / / [EMAIL PROTECTED], [EMAIL PROTECTED] | http://eelf.ddts.net \ \==/ / Clan Barclay motto: Aut agere, aut mori. (Either action, or death.) \ pgpINoqw3g2tj.pgp Description: PGP signature
Re: the openssh exploit
On Monday, June 24, 2002, at 11:20 PM, David B Harris wrote: We have no way of being sure, since the nature of the exploit and the specifics aren't being told. However, supposedly, you need to be able to talk to the sshd in order to exploit it. So if nothing (or nothing malicious) can open a connection, you're fine. Does the tcp_wrapper use in openssh work that way? It's not like ssh is running from inetd first being passed through tcpd. I'm just using the builtin tcpwrapper support of openssh, so I would guess that that means technically, sshd is handling the request long enough to at least see what ip it is coming from. May be time to modify my firewall rules. argh! Of course maybe that won't even help. Of course we don't know because openbsd is keeping a tight lip, but potentially maybe someone could craft a malicious packet that appears to come from one of the trusted ips?? -- Paul Baker They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the openssh exploit
On Mon, 24 Jun 2002 23:39:04 -0500 Paul Baker [EMAIL PROTECTED] wrote: Does the tcp_wrapper use in openssh work that way? It's not like ssh is running from inetd first being passed through tcpd. I'm just using the builtin tcpwrapper support of openssh, so I would guess that that means technically, sshd is handling the request long enough to at least see what ip it is coming from. May be time to modify my firewall rules. argh! Of course maybe that won't even help. Of course we don't know because openbsd is keeping a tight lip, but potentially maybe someone could craft a malicious packet that appears to come from one of the trusted ips?? I honestly couldn't tell you. If it's sane, you're fine. TCP_WRAPPERS are supposed to be the first thing that's checked, and given what we know of the nature of the exploit, it seems like the code involved is further on. I could be wrong, though. :) -- \ David B. Harris, Systems administrator | http://www.terrabox.com / / [EMAIL PROTECTED], [EMAIL PROTECTED] | http://eelf.ddts.net \ \==/ / Clan Barclay motto: Aut agere, aut mori. (Either action, or death.) \ pgpLUEH8f2y23.pgp Description: PGP signature
Re: the openssh exploit
On Tuesday, June 25, 2002, at 12:39 , Paul Baker wrote: but potentially maybe someone could craft a malicious packet that appears to come from one of the trusted ips?? SSH uses TCP, not UDP. In order for the kernel to pass any data to OpenSSH, the following must happen: REMOTE sends LOCAL a SYN w/ a ID number LOCAL sends REMOTE SYN|ACK w/ REMOTE ID number and another ID REMOTE sends ACK w/ LOCAL ID number Only at the third packet is any data passed. So, there is no way spoof an IP address with TCP unless: 1) You are able to observe traffic passing between LOCAL and the machine who's IP you just stole 2) Source routing + trusting IP on a source-routed packet 3) Guessable initial sequence number on LOCAL. Linux (at least anything recent) does not have this problem. Note that to do (1), you must insure that the real machine does not send a RST in response to the SYN|ACK. Ways to do this are numerous; DoS attacks come to mind. [ Also, btw, you could probably get ssh to run from inetd. Just the key generation overhead would kill you. ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the openssh exploit
On Tuesday, June 25, 2002, at 12:00 , Paul Baker wrote: Does anyone know if the openssh exploit that 3.3 is supposed to not fix, but do damage control for, is it still exploitable if you have set your /etc/hosts.deny to deny all hosts, and then /etc/hosts.allow to only allow from trusted ips. A good guess would be 'no', because then most OpenSSH code is not invoked. However, we can't be sure, because (at least according to the DSA) OpenBSD has released no details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: open ssh exploit - user not getting created
Previously Sean McAvoy wrote: I was a little hasty in my first reply. It is a noted bug (http://bugzilla.mindrot.org/show_bug.cgi?id=285) Disabling compression will solve the problem on 2.2.x kernels. (Compression no) Actually our package contains a patch from Solar Designer to make privsep work on 2.2 kernels. It might still be broken on 2.0 kernels though, but I have no concrete information on that. 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: [SECURITY] [DSA-134-1] OpenSSH remote vulnerability
Hi, Phillip Hofmeister wrote: Sowhat does this mean for us running potato on internet servers? Does this effect the daemon or the client? this is the information markus friedl send to bugtraq and it is perhaps the same, the debian-team got?!? Date: Mon, 24 Jun 2002 15:00:10 -0600 From: Theo de Raadt [EMAIL PROTECTED] Subject: Upcoming OpenSSH vulnerability To: bugtraq@securityfocus.com Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: misc@openbsd.org There is an upcoming OpenSSH vulnerability that we're working on with ISS. Details will be published early next week. However, I can say that when OpenSSH's sshd(8) is running with priv seperation, the bug cannot be exploited. OpenSSH 3.3p was released a few days ago, with various improvements but in particular, it significantly improves the Linux and Solaris support for priv sep. However, it is not yet perfect. Compression is disabled on some systems, and the many varieties of PAM are causing major headaches. However, everyone should update to OpenSSH 3.3 immediately, and enable priv seperation in their ssh daemons, by setting this in your /etc/ssh/sshd_config file: UsePrivilegeSeparation yes Depending on what your system is, privsep may break some ssh functionality. However, with privsep turned on, you are immune from at least one remote hole. Understand? 3.3 does not contain a fix for this upcoming bug. If priv seperation does not work on your operating system, you need to work with your vendor so that we get patches to make it work on your system. Our developers are swamped enough without trying to support the myriad of PAM and other issues which exist in various systems. You must call on your vendors to help us. Basically, OpenSSH sshd(8) is something like 27000 lines of code. A lot of that runs as root. But when UsePrivilegeSeparation is enabled, the daemon splits into two parts. A part containing about 2500 lines of code remains as root, and the rest of the code is shoved into a chroot-jail without any privs. This makes the daemon less vulnerable to attack. We've been trying to warn vendors about 3.3 and the need for privsep, but they really have not heeded our call for assistance. They have basically ignored us. Some, like Alan Cox, even went further stating that privsep was not being worked on because Nobody provided any info which proves the problem, and many people dont trust you theo and suggested I might be feeding everyone a trojan (I think I'll publish that letter -- it is just so funny). HP's representative was downright rude, but that is OK because Compaq is retiring him. Except for Solar Designer, I think none of them has helped the OpenSSH portable developers make privsep work better on their systems. Apparently Solar Designer is the only person who understands the need for this stuff. So, if vendors would JUMP and get it working better, and send us patches IMMEDIATELY, we can perhaps make a 3.3.1p release on Friday which supports these systems better. So send patches by Thursday night please. Then on Tuesday or Wednesday the complete bug report with patches (and exploits soon after I am sure) will hit BUGTRAQ. Let me repeat: even if the bug exists in a privsep'd sshd, it is not exploitable. Clearly we cannot yet publish what the bug is, or provide anyone with the real patch, but we can try to get maximum deployement of privsep, and therefore make it hurt less when the problem is published. So please push your vendor to get us maximally working privsep patches as soon as possible! We've given most vendors since Friday last week until Thursday to get privsep working well for you so that when the announcement comes out next week their customers are immunized. That is nearly a full week (but they have already wasted a weekend and a Monday). Really I think this is the best we can hope to do (this thing will eventually leak, at which point the details will be published). Customers can judge their vendors by how they respond to this issue. OpenBSD and NetBSD users should also update to OpenSSH 3.3 right away. On OpenBSD privsep works flawlessly, and I have reports that is also true on NetBSD. All other systems appear to have minor or major weaknesses when this code is running. (securityfocus postmaster; please post this through immediately, since i have bcc'd over 30 other places..) -- 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: open ssh exploit - user not getting created
Weee ! That works ! Cool, many tanx ! On 25 Jun 2002, Sean McAvoy wrote: I was a little hasty in my first reply. It is a noted bug (http://bugzilla.mindrot.org/show_bug.cgi?id=285) Disabling compression will solve the problem on 2.2.x kernels. (Compression no) Hope that helps you. On Mon, 2002-06-24 at 20:49, buggz wrote: Does 3.3 work w/ 2.20 kernels ? Jun 23 10:11:38 buggz1 sshd[9598]: fatal: mmap(65536): Invalid argument I get that everytime I try connecting. -- -- Ed June -o) /\ buggz at america dot net _\_v Linux: An open choice for free people worldwide. -- 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]
ssh and password authentication
Hi, I have read several times, including on this list, that password authentication with ssh does not send the password in clear text (it is sent in the encrypted tunnel). This is confirmed by the ssh(1) man page: If other authentication methods fail, ssh prompts the user for a password. The password is sent to the remote host for checking; however, since all communications are encrypted, the password cannot be seen by someone listening on the network. But the default sshd_config in the openssh-3.0.2p1 package has a comment indicating the contrary: , | # To disable tunneled clear text passwords, change to no here! | PasswordAuthentication yes ` and according to that comment, the default setting would be insecure... I don't believe it, but the comment seems to be a real bug (and an upstream one, since it also appears in the .orig.tar.gz). Any thoughts? Thanks. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh and password authentication
On Tue, 2002-06-25 at 15:35, Florent Rougon wrote: But the default sshd_config in the openssh-3.0.2p1 package has a comment indicating the contrary: , | # To disable tunneled clear text passwords, change to no here! | PasswordAuthentication yes ` and according to that comment, the default setting would be insecure... Nope... it's just the way you read it... It's a tunnelled clear-text password, meaning the 'clear-text' password is transmitted trough the tunnel. The tunnel is encrypted. It just means that the password will be visible to roots on both ends of the tunnel, but not to anyone in between. So it's quite safe ;) -- 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: ssh and password authentication
On Tue, Jun 25, 2002 at 03:35:19PM +0200, Florent Rougon wrote: Hi, I have read several times, including on this list, that password authentication with ssh does not send the password in clear text (it is sent in the encrypted tunnel). This is confirmed by the ssh(1) man page: If other authentication methods fail, ssh prompts the user for a password. The password is sent to the remote host for checking; however, since all communications are encrypted, the password cannot be seen by someone listening on the network. But the default sshd_config in the openssh-3.0.2p1 package has a comment indicating the contrary: , | # To disable tunneled clear text passwords, change to no here! | PasswordAuthentication yes ` and according to that comment, the default setting would be insecure... The keyword is tunneled clear text - i.e. it *is* clear text. But it's inside the ssh tunnel (which happens to be encrypted). I don't believe it, but the comment seems to be a real bug (and an upstream one, since it also appears in the .orig.tar.gz). I agree the way it is phrased in /etc/ssh/sshd_config is slighly confusing though; perhaps a wishlist bug is in order? -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com Today's fortune: The moon may be smaller than Earth, but it's further away. pgp0GP3UOoejD.pgp Description: PGP signature
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]
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
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, 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: 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: [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
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
[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 e [EMAIL PROTECTED] pgp 0x8bb5c71e -- 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: the openssh exploit
On Tue, Jun 25, 2002 at 02:40:19AM -0400, Anthony DeRobertis wrote: Note that to do (1), you must insure that the real machine does not send a RST in response to the SYN|ACK. Ways to do this are numerous; DoS attacks come to mind. Or just use an unused IP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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: [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: the openssh exploit
On Tuesday, June 25, 2002, at 11:14 AM, Phillip Hofmeister wrote: On Tue, Jun 25, 2002 at 02:40:19AM -0400, Anthony DeRobertis wrote: Note that to do (1), you must insure that the real machine does not send a RST in response to the SYN|ACK. Ways to do this are numerous; DoS attacks come to mind. Or just use an unused IP He was talking about spoofing ips that I am allowing access for in my firewall. All the ips I'm allowing are for existing machines, so an unused IP would be one that is not allowed through the firewall already. -- Paul Baker They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -- 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: 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: [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: 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]
(no subject)
Unable to log onto secure sites. Followed http://pandor etc directions Got an index of / ~kitamd/morzilla without the ability to download apt-get update or apt-get install mozilla What can you suggest? Franky
Re: (no subject)
On Tue, Jun 25, 2002 at 17:14:49 -0400, [EMAIL PROTECTED] wrote: Unable to log onto secure sites. Followed http://pandor etc directions Got an index of / ~kitamd/morzilla without the ability to download apt-get update or apt-get install mozilla What can you suggest? Some suggestions: - Don't use HTML in email - When asking for help with problems on a mailing list, try to clearly formulate, in proper English, what you're trying to do, what the systems responses are (use e.g. script(1) to capture relevant messages exactly and in detail) and what you expected them to be. - Mozilla is a regular package in both woody and sid, so there's no need to refer to kitame's dir on pandora. - apt-cache show mozilla-psm apt-get install mozilla-psm HTH, Ray -- The proper place for a CAPSLOCK key is in a different hemisphere from you. Tom Christiansen in Interface Zen, http://slashdot.org/article.pl?sid=99/11/30/0954216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (no subject)
On Tue, Jun 25, 2002 at 05:14:49PM -0400, [EMAIL PROTECTED] wrote: Unable to log onto secure sites. Followed http://pandor etc directions Got an index of / ~kitamd/morzilla without the ability to download apt-get update or apt-get install mozilla What can you suggest? apt-get install mozilla-psm Nailed me, too. :-) KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] Personal Homepage: http://www.skyjammer.com/~pronovic/ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin, Historical Review of Pennsylvania, 1759 pgpflYb8FJJGb.pgp Description: PGP signature
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]
security.debian.org is down
The subject says it all... I'm in Spain, is it happening everywhere or is it just the phone company folks messing again with the DSL? Regards, Pope -- 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: security.debian.org is down
The subject says it all... I'm in Spain, is it happening everywhere or is it just the phone company folks messing again with the DSL? No, it seems to be a world wide problem. I'm in Hong Kong and it is the same to me: Err ftp://security.debian.org woody/updates/main Packages Could not connect to security.debian.org:21 (130.89.175.34), connection timed out Best regards Jonas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security.debian.org is down
Jonas == Jonas Weismüller [EMAIL PROTECTED] writes: The subject says it all... I'm in Spain, is it happening everywhere or is it just the phone company folks messing again with the DSL? Jonas No, it seems to be a world wide problem. I'm in Hong Kong and it Jonas is the same to me: Jonas Err ftp://security.debian.org woody/updates/main Packages Could Jonas not connect to security.debian.org:21 (130.89.175.34), connection Jonas timed out I can ping it, and I just did an apt-get update which connected fine. Maybe it just came back up. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgpgqfFSD5nJt.pgp Description: PGP signature
