SuSE Security Announcement: OpenSSH (SuSE-SA:2002:023)
-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: openssh Announcement-ID: SuSE-SA:2002:023 Date: Tue Jun 25 2002 Affected products: 6.4, 7.0, 7.1, 7.2, 7.3, 8.0 SuSE Linux Database Server, SuSE eMail Server III, SuSE Linux Enterprise Server, SuSE Linux Firewall on CD Vulnerability Type: unknown Severity (1-10): 9 SuSE default package: yes Content of this advisory: 1) security vulnerability resolved: unknown vulnerability in the OpenSSH daemon. problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information There's a new vulnerabilty in the OpenSSH daemon, of which we were notified yesterday. The OpenSSH/OpenBSD team has asked Linux vendors to upgrade their platforms to OpenSSH 3.3, and change the configuration to use the relatively new "Privilege Separation" code. According to their information, 3.3 does not fix the vulnerability, but using privilege separation prevents exploits. We were not given any additional information on the nature of the vulnerability. Setting PrivilegeSeparation to on causes large portions of the daemon to run in a so-called "chroot jail", i.e. in a very restricted environment. An attacker breaking this part of the SSH daemon will *not* obtain full root privilege (as he would if sshd ran without this option), but will find himself in an empty directory, inside a process running as a non privileged user (he can still do some harm this way, but it's a far cry from full root powers). The SuSE security team has prepared RPMs that upgrade OpenSSH to version 3.3p1 on all SuSE Linux platforms. Based on the information we've been given, we are unable to provide updates containing a complete fix, nor can we guarantee that the workaround using privilege separation is enough to protect you. Given these imponderabilities, we suggest to you to take additional precautions until details of the vulnerability have been published, and we have been able to assess it: - if you do not need external access to your SSH daemons, turn off the SSH service on these machine completely, or block external access at the firewall. - if you do need external access to your SSH daemons, make sure you restrict the hosts that it will talk to by setting appropriate firewall rules. If, for some reason, you cannot configure your firewall to block external SSH access, you can also restrict access through /etc/hosts.allow; the following will allow connections from hosts with IP addresses 1.2.3.4, from hosts on the clas C IP network 192.168.5.0, and from hosts in the foo.net DNS domain, while rejecting any other connections. sshd : 1.2.3.4 : allow sshd : 192.168.5.0/255.255.255.0 : allow sshd : *.foo.net : allow sshd : ALL : deny As soon as we are given the relevant details, the SuSE security team will publish a follow-up advisory, and another openssh update, as required. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. If you are running nscd (enabled by default since SuSE Linux 7.0), the name service caching daemon, shut down the daemon prior to upgrading (this works around a bug in the groupadd command): rcnscd stop Then, install the package using the following command to apply the update: rpm -Fvh openssh*.rpm After upgrading, please restart the SSH server by executing the following command as super user: rcsshd restart Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. Special notice concerning SuSE Linux 6.4 and 7.0: SuSE Linux 6.4 ceased to be supported a week or two ago. However, given the potential impact of this problem, we decided to issue update packages for 6.4 as well. These are in the process of getting built, and will show up on our FTP server soon. Users of SuSE Linux 6.4 and 7.0, please also note that crypto update packages for these platforms are always made available through ftp.suse.de only, not ftp.suse.com, due to the crypto laws that were in effect in the US at the time of the original release of the product. i386 Intel Platform SuSE-8.0 ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec1/openssh-3.3p1-6.i386.patch.rpm aa29ca8bcedf674605c69d3ebb20456c ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec1/openssh-3.3p1-6.i386.rpm 568b475b982721e62f557557c59624fb source rpm: ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/openssh-3.3p1-6.src.rpm 5a533bd017d86346986904b0c9e6c3e5 SuSE-7.3 ftp://ftp.suse.com/pub/suse/i386/update/7.3/sec1/openssh-3.3p1-6.i386.rpm 86b3182d742afba08a99bb04ae91f70f source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/openssh-3.3p1-6.src.rpm 4d017a1b4a49d0da63ca18c817961b48 SuSE-7.2 ftp://ftp.suse.com/pub/suse/i386/update/7.2/sec1/openssh-3.3p1-6.i386.rpm d559ad7d04162a32c58fa07b480be820 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/openssh-3.3p1-6.src.rpm 90a4577e90d31ab9c393269c94f4fe86 SuSE-7.1 ftp://ftp.suse.com/pub/suse/i386/update/7.1/sec1/openssh-3.3p1-6.i386.rpm 3f5999291e0959ebbc1afbd152d3b1f0 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/openssh-3.3p1-6.src.rpm 73c1b72c4616253d8292fad76ef0b41b SuSE-7.0 ftp://ftp.suse.de/pub/suse/i386/update/7.0/sec1/openssh-3.3p1-6.i386.rpm b670aa96ceaa97a33cd4b2009492e1ea source rpm: ftp://ftp.suse.de/pub/suse/i386/update/7.0/zq1/openssh-3.3p1-6.src.rpm 8f77876f90ef86a2e6fb8e23c34fbd6f Sparc Platform SuSE-7.3 ftp://ftp.suse.com/pub/suse/sparc/update/7.3/sec1/openssh-3.3p1-4.sparc.rpm d1306f869119e076bcb1693d8de837e4 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/openssh-3.3p1-4.src.rpm 6495e65b671b788cb62f8dcfd7f81f45 SuSE-7.1 ftp://ftp.suse.com/pub/suse/sparc/update/7.1/sec1/openssh-3.3p1-4.sparc.rpm ae8c8de1505ed2ac56fc5ec20041819c source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.1/zq1/openssh-3.3p1-4.src.rpm 16425d92da3c9fa9feeee0322a216b1b SuSE-7.0 ftp://ftp.suse.de/pub/suse/sparc/update/7.0/sec1/openssh-3.3p1-4.sparc.rpm 05a40abfdbd42b5465e367a187a3393c source rpm: ftp://ftp.suse.de/pub/suse/sparc/update/7.0/zq1/openssh-3.3p1-4.src.rpm bf000a597b2cc3b33517887fa50f0504 AXP Alpha Platform SuSE-7.1 ftp://ftp.suse.com/pub/suse/axp/update/7.1/sec1/openssh-3.3p1-4.alpha.rpm 478503f40c0ef3ed2d5b3ea40dd74e32 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.1/zq1/openssh-3.3p1-4.src.rpm e8b93a73622386a95497d0418d2bfa50 SuSE-7.0 ftp://ftp.suse.de/pub/suse/axp/update/7.0/sec1/openssh-3.3p1-4.alpha.rpm 3001c656fb57915c4bb5dcd5fa8de76d source rpm: ftp://ftp.suse.de/pub/suse/axp/update/7.0/zq1/openssh-3.3p1-4.src.rpm 2fd9646fa24b5298d37a79902230c826 PPC Power PC Platform SuSE-7.3 ftp://ftp.suse.com/pub/suse/ppc/update/7.3/sec1/openssh-3.3p1-4.ppc.rpm 77dd425d361dc084bad50feefdf1f94c source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/openssh-3.3p1-4.src.rpm 8a928dc956cd107ee91d72fe4b4a8bc6 SuSE-7.1 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/sec1/openssh-3.3p1-4.ppc.rpm ddbc79c387273ddd0da636c7df951c85 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/openssh-3.3p1-4.src.rpm ef9f5de04c632490fe77b96e06892f01 SuSE-7.0 ftp://ftp.suse.de/pub/suse/ppc/update/7.0/sec1/openssh-3.3p1-4.ppc.rpm 67867b11cefc77dca95aaeb130012507 source rpm: ftp://ftp.suse.de/pub/suse/ppc/update/7.0/zq1/openssh-3.3p1-4.src.rpm 76e2f4d9fb52cc5c7220f52108614542 ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - mozilla Cross-dependencies between mozilla and other packages in SuSE Linux products keep us from providing version upgrades for the mozilla packages. Fixing security bugs in our packages is usually done by adding the necessary patches to the existing version to ensure the compatibility and consistency that is expected from our products. In some cases (as with the mozilla package) the complexity of the issue does not allow to add patches any more. By consequence, security related issues in mozilla cannot be addressed. As a service to our user community, we provide packages of newer mozilla versions at ftp://ftp.suse.com/pub/projects/mozilla/. These packages have been verified to run fine; they are not located in the update directory of the distribution in question because we cannot make any claims about the compatibility with the other packages in the product. Security-aware users are encouraged to install the packages from the projects/ directory. - ghostscript RedHat released a security announcement concerning a problem in ghostscript, which could be exploited to gain privilege of the print server user. We are investigating whether SuSE Linux is affected. - kernel netfilter update we are in the process of preparing a kernel update that will include a security fix for a minor netfilter bug. - fetchmail we are in the process of releasing a security update for fetchmail that corrects a vulnerability that could be exploited by hostile mail servers. ______________________________________________________________________________ 3) standard appendix: authenticity verification, additional information - Package authenticity verification: SuSE update packages are available on many mirror ftp servers all over the world. While this service is being considered valuable and important to the free and open source software community, many users wish to be sure about the origin of the package and its content before installing the package. There are two verification methods that can be used independently from each other to prove the authenticity of a downloaded file or rpm package: 1) md5sums as provided in the (cryptographically signed) announcement. 2) using the internal gpg signatures of the rpm package. 1) execute the command md5sum <name-of-the-file.rpm> after you downloaded the file from a SuSE ftp server or its mirrors. Then, compare the resulting md5sum with the one that is listed in the announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security@suse.de), the checksums show proof of the authenticity of the package. We disrecommend to subscribe to security lists which cause the email message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig <file.rpm> to verify the signature of the package, where <file.rpm> is the filename of the rpm package that you have downloaded. Of course, package authenticity verification can only target an uninstalled rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SuSE in rpm packages for SuSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SuSE Linux distributions version 7.1 and thereafter install the key "build@suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the toplevel directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SuSE runs two security mailing lists to which any interested party may subscribe: suse-security@suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to <suse-security-subscribe@suse.com>. suse-security-announce@suse.com - SuSE's announce-only mailing list. Only SuSE's security annoucements are sent to this list. To subscribe, send an email to <suse-security-announce-subscribe@suse.com>. For general information or the frequently asked questions (faq) send mail to: <suse-security-info@suse.com> or <suse-security-faq@suse.com> respectively. ===================================================================== SuSE's security contact is <security@suse.com> or <security@suse.de>. The <security@suse.de> public key is listed below. ===================================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the cleartext signature shows proof of the authenticity of the text. SuSE Linux AG makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <security@suse.de> pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build@suse.de> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff 4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3 0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot 1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/ HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM 523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q 2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8 QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ 1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1 wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol 0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J /LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8 RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ 8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X 11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA 8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+ AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0 zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM /3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7 whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE= =LRKC - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3in Charset: noconv iQEVAwUBPRiUcney5gA9JdPZAQFEmAf9H0OsASl3qLpG/XurLiFsQ5Iapxc1Z/wj rHcAaa9IrfvsQ6t3q6y+k4nQJRsmoH4K3x3eTRJMu6z7OUJnpQV67LnjFpjo7c43 u+e47XfEtRpqH7wnA7glf7m+ABy7L1oFGnJgBv7Opj9NwwAbjjoKhibmOoJmA53A Wp1pw+gZV1p64jYhSHHlZRQ7Xa+vG4vnp15Jf8ehX2Z7wxFpQBWKA7onmsvN54Q8 ufvw5v26rnAGnZEsxWErP+c+ZT6Iz98hzopaexhKCCTlIWl/MwOVx9VGjsWg+sm/ xZbBW73lCfTkG4sJBL0bxBLDBBR7KNk3LTxB9ysxYP5fRVMXeLXM3g== =ZKKJ -----END PGP SIGNATURE-----
hi all the update with SuSE 7.1 (i386) does not work properly. ------------------- SNIP -------------------------- error: failed dependencies: libcrypto.so.0.9.6 is needed by openssh-3.3p1-6 ------------------------------------------------------- this missing file "libcrypto.so.0.9.6" is properly installed with the openssl rpm on this machine. false rpm? -- Mit freundlichen Grüssen / With kind regards Dipl.-Ing. Harald Nikolisin SOFiSTiK AG (Entwicklung)
Hello! I tried to update to openssh 3.3p1 as described in the security announcement, but just can't login. The not very meaningful message "Failed password for <username> from <ip> port ... ssh2" can be found in the logs. I'm using md5 passwords in /etc/passwd and had to edit /etc/pam.d/sshd to get the right entries back (unfortunately SuSE broke them, but maybe rpm -Uvh instead of -Fvh is guilty?). I verified that sshd is linked with libpam, and also disabled PrivilegeSeparation for testing. The only 'odd' thing on my machine is the openwall patch hiding foreign processes for users different to root. I'm using kernel 2.2.20. Here some output from sshd -d -d -d: --snip-- debug2: input_userauth_request: setting up authctxt for root debug1: Starting up PAM with username "root" debug1: PAM setting rhost to "localhost" debug2: input_userauth_request: try method none Failed none for root from 127.0.0.1 port 2423 ssh2 debug1: userauth-request for user root service ssh-connection method password debug1: attempt 1 failures 1 debug2: input_userauth_request: try method password debug1: PAM Password authentication for "root" failed[7]: Authentication failure Failed password for root from 127.0.0.1 port 2423 ssh2 --snip-- Using ssh1 (-1) doesn't help either. regards, Markus Gaugusch -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus@gaugusch.at X Against HTML Mail / \
Failed password for root from 127.0.0.1 port 2423 ssh2 Further investigation by me revealed, that the md5 passwords are "guilty". If I put a non-md5 password in /etc/passwd, login works. Here my settings from /etc/pam.d/sshd (which worked before) #%PAM-1.0 auth required /lib/security/pam_unix.so # set_secrpc auth required /lib/security/pam_nologin.so auth required /lib/security/pam_env.so account required /lib/security/pam_unix.so
On Jun 25, Markus Gaugusch <markus@gaugusch.at> wrote: password required /lib/security/pam_pwcheck.so md5 password required /lib/security/pam_unix.so md5 use_first_pass use_authtok session required /lib/security/pam_unix.so debug # trace or none session required /lib/security/pam_limits.so Any hints? regards, Markus Gaugusch -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus@gaugusch.at X Against HTML Mail / \
doesnt work on suse 7.3 either. just upgraded one box and cant login now with md5 password. but i can still login from another machine that uses dsa keys. is a pam update needed? On Tuesday 25 June 2002 12:03 pm, Markus Gaugusch wrote:
On Jun 25, Markus Gaugusch <markus@gaugusch.at> wrote:
Failed password for root from 127.0.0.1 port 2423 ssh2
Further investigation by me revealed, that the md5 passwords are "guilty". If I put a non-md5 password in /etc/passwd, login works. Here my settings from /etc/pam.d/sshd (which worked before) #%PAM-1.0 auth required /lib/security/pam_unix.so # set_secrpc auth required /lib/security/pam_nologin.so auth required /lib/security/pam_env.so account required /lib/security/pam_unix.so password required /lib/security/pam_pwcheck.so md5 password required /lib/security/pam_unix.so md5 use_first_pass use_authtok session required /lib/security/pam_unix.so debug # trace or none session required /lib/security/pam_limits.so
Any hints?
regards, Markus Gaugusch
-- Chad Whitten Network/Systems Administrator neXband Communications cwhitten@nexband.com
Chad Whitten wrote:
doesnt work on suse 7.3 either. just upgraded one box and cant login now with md5 password. but i can still login from another machine that uses dsa keys. is a pam update needed?
afaik that problem still exist: 20020401 - (stevesk) [monitor.c] PAM should work again; will *not* work with UsePrivilegeSeparation=yes. (source: ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/ChangeLog) HTH Sven
Just a little warning: frequently the OpenSSH people change defaults (not SuSE's fault) and so things stop working when you upgrade. In this case the default value of RhostsRSAAuthentication in /etc/ssh/ssh_config has changed from 'yes' to 'no'. This affects you if you wish to connect to a different machine using rhosts-style authentication. Bob ============================================================== Bob Vickers R.Vickers@cs.rhul.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhul.ac.uk/home/bobv Phone: +44 1784 443691
Hello Olaf, I installed the recommended update to openssh 3.3 on my suse 7.3 but now I can't login any more. I have the user sshd with dir /var/empty, uid 71, gid 100 and shell /bin/false in my /etc/passwd All I get is the error described by Markus Gaugusch ("Failed password for <username> from <ip> port ... ssh2") Hacking around with different gids of the user "sshd" didn't change anything nor did disabling PrivilegeSeparation ... mfg ;-) Christoph Illnar GlobalAce.net Internetservice GmbH * WorldStore eCommerce www.globalace.net www.worldstore.at www.schatzmail.com
-----Ursprüngliche Nachricht----- Von: Olaf Kirch [mailto:okir@suse.de] Gesendet: Dienstag, 25. Juni 2002 18:11 An: suse-security@suse.com Betreff: [suse-security] SuSE Security Announcement: OpenSSH (SuSE-SA:2002:023)
This message uses a character set that is not supported by the Internet Service. To view the original message content, open the attached message. If the text doesn't display correctly, save the attachment to disk, and then open it using a viewer that can display the original character set. <<message.txt>>
Hi and thanks for the quick update. On Tue, Jun 25, 2002 at 06:10:53PM +0200, Olaf Kirch wrote:
Special notice concerning SuSE Linux 6.4 and 7.0:
Users of SuSE Linux 6.4 and 7.0, please also note that crypto update packages for these platforms are always made available through ftp.suse.de only, not ftp.suse.com, due to the crypto laws that were in effect in the US at the time of the original release of the product.
Ok, sounds good, BUT: where are the files exactely ? I see nothing in ftp://ftp.suse.de/pub/suse/i386/update/6.4/sec1/ (openssh is the version from 7. march). Regards, Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland qmail projects: http://omail.omnis.ch - http://webmail.omnis.ch
Hi, just a little bug, I hope: We have set "HostbasedAuthentication no". However, when we login with a DSA key, sshd rerports "Accepted hostbased for ...". But from an "slogin -v" it seems that the ley authentication is indeed performed. But still, this sshd message is quite confusing and made my alarm bell ring. Maybe this could be fixed when SuSE plans to release another update anyway :-) Btw, slogin with password issues the correct message "Accepted password for ..." cu, Frank -- Dipl.-Inform. Frank Steiner mailto:fst@informatik.uni-kiel.de Lehrstuhl f. Programmiersprachen mailto:fsteiner@web.de CAU Kiel, Olshausenstraße 40 Phone: +49 431 880-7265, Fax: -7613 D-24098 Kiel, Germany http://www.informatik.uni-kiel.de/~fst/
On Thu, Jun 27, 2002 at 11:23:13AM +0200, Frank Steiner wrote:
just a little bug, I hope: We have set "HostbasedAuthentication no". However, when we login with a DSA key, sshd rerports "Accepted hostbased for ...". But from an "slogin -v" it seems that the ley authentication is indeed performed. But still, this sshd message is quite confusing and made my alarm bell ring. Maybe this could be fixed when SuSE plans to release another update anyway :-)
Btw, slogin with password issues the correct message "Accepted password for ..."
Yes, it turns out logging is slightly hosed in 3.3; the OpenSSH team has a fix for this in the CVS according to Markus Friedl Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably okir@suse.de | experienced what can best be described as ---------------+ ISO water torture. -- Peter Gutmann
* Olaf Kirch wrote on Tue, Jun 25, 2002 at 18:10 +0200:
Setting PrivilegeSeparation to on causes large portions of the daemon to run in a so-called "chroot jail", i.e. in a very restricted environment. An attacker breaking this part of the SSH daemon will
Seems that it does not work for me. I upgraded as described, but didn't found a chrooted or setuid=sshd process after restarting sshd. I really wonder why noone other has this problem? Did you checked that ssh runs in chroot as sshd correctly? Or did you just upgraded without verification? I think both hosts I upgraded so far are still exploitable! Detailed description: Host #1: VERSION = 7.0 openssh-3.3p1-6 -rwxr-xr-x 1 root root 754084 Jun 25 13:08 /usr/sbin/sshd SSH|root@host:~ # grep Sepa /etc/ssh/sshd_config UsePrivilegeSeparation yes SSH|root@host:~ # ps axu|grep ssh root 8275 1.2 1.3 1968 892 ? S 11:23 0:03 /usr/sbin/sshd-old -p 1243 root 8399 0.8 1.4 2052 976 ? S 11:24 0:01 /usr/sbin/sshd root 8464 6.9 2.3 2632 1556 ? S 11:27 0:01 /usr/sbin/sshd-old -p 1234 SSH|root@host:~ # grep Uid /proc/8399/status Uid: 0 0 0 0 SSH|root@host:~ # lsof|grep sshd|grep cwd sshd-old 8275 root cwd DIR 3,2 409 2 / sshd 8399 root cwd DIR 3,2 409 2 / SSH|root@host:~ # file /var/empty/ /var/lib/sshd/ /var/empty/: directory /var/lib/sshd/: directory SSH|root@host:~ # id sshd uid=71(sshd) gid=65(sshd) groups=65(sshd) and RPM replaced the binary really: -rwxr-xr-x 1 root root 308920 Jun 25 12:52 /usr/sbin/sshd user and dirs are there, but no chroot. I guess this update does not help anything. Host #2 SuSE Linux eMail Server (i386) VERSION = 7.2 openssh-3.3p1-6.i386.rpm: md5 gpg OK rpm -q openssh --> openssh-3.3p1-6 uid=71(sshd) gid=65(sshd) groups=65(sshd) # lsof |grep sshd|grep cwd sshd 23998 root cwd DIR 3,2 417 2 / sshd 24034 root cwd DIR 3,2 417 2 / sshd-old 24170 root cwd DIR 3,2 417 2 / no chroot either. Any ideas?? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Jun 27, Steffen Dettmer <steffen@dett.de> wrote:
Seems that it does not work for me. I upgraded as described, but didn't found a chrooted or setuid=sshd process after restarting sshd. How did you restart sshd? If you were logged in via ssh while restarting (rcsshd restart), it is not really restarted. Try killall sshd first and then start the new one (use a copy of sshd with different name and port while doing this).
Markus -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus@gaugusch.at X Against HTML Mail / \
Am Donnerstag den, 27. Juni 2002, um 11:48, schrieb Markus Gaugusch:
On Jun 27, Steffen Dettmer <steffen@dett.de> wrote:
Seems that it does not work for me. I upgraded as described, but didn't found a chrooted or setuid=sshd process after restarting sshd. How did you restart sshd? If you were logged in via ssh while restarting (rcsshd restart), it is not really restarted.
That's not my observation on several 7.2 systems: If you are logged in via ssh and restart ssh, then log out and do a "telnet host 22" you see the newly installed version running. //Stefan
Try killall sshd first and then start the new one (use a copy of sshd with different name and port while doing this).
Markus -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus@gaugusch.at X Against HTML Mail / \
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
* Stefan Eissing wrote on Thu, Jun 27, 2002 at 11:55 +0200:
That's not my observation on several 7.2 systems: If you are logged in via ssh and restart ssh, then log out and do a "telnet host 22" you see the newly installed version running.
I guess this is correct: telnet localhost 22 [...] SSH-1.99-OpenSSH_3.3 oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
* Markus Gaugusch wrote on Thu, Jun 27, 2002 at 11:48 +0200:
On Jun 27, Steffen Dettmer <steffen@dett.de> wrote:
Seems that it does not work for me. I upgraded as described, but didn't found a chrooted or setuid=sshd process after restarting sshd. How did you restart sshd? If you were logged in via ssh while restarting (rcsshd restart), it is not really restarted.
CooL. I knew the startproc isn't a nice thing... Even in -v it says nothing. Well, I tried rcssh, and I tried killall sshd /usr/sbin/sshd and even a /usr/sbin/sshd -f /etc/ssh/sshd_config to go for sure. I don't see any errors, only a sshd[24365]: Server listening on :: port 22.
Try killall sshd first and then start the new one (use a copy of sshd with different name and port while doing this).
Yes, this was my way. I even think, that rcsshd restart without having a copy with a different name on a different port is deadly since it seems it locks you out (and happily, after the stop, the rcsshd is killed by SIGHUP, and by that it doesn't start sshd). I verified with ps ax that no sshd process was running when I restarted it. I even did a "cmp" on sshd and the copy I made before upgrading, and both binaries differ. Any hints?? What did I wrong? And much more important: How do I make this stuff secure? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
CooL. I knew the startproc isn't a nice thing... Even in -v it says nothing.
Well, I tried rcssh, and I tried killall sshd /usr/sbin/sshd and even a /usr/sbin/sshd -f /etc/ssh/sshd_config
to go for sure. I don't see any errors, only a sshd[24365]: Server listening on :: port 22.
Try killall sshd first and then start the new one (use a copy of sshd with different name and port while doing this).
Yes, this was my way. I even think, that rcsshd restart without having a copy with a different name on a different port is deadly since it seems it locks you out (and happily, after the stop, the rcsshd is killed by SIGHUP, and by that it doesn't start sshd). I verified with ps ax that no sshd process was running when I restarted it. I even did a "cmp" on sshd and the copy I made before upgrading, and both binaries differ.
Actually, rcsshd restart should stop the daemon with the pid from /var/run/sshd.pid. Then a new daemon would start up, writing its pid to the same file. The running instances of sshd which handle active connections should not get touched. There used to be a killall to nuke running daemons, but this is hundreds of years ago. To make sure it works, I usually do the following: cp /usr/sbin/sshd /sshdd /sshdd -p 23 rm /sshdd # log on to port 23 killall sshd rcsshd start # log on to port 22 killall sshdd
Any hints?? What did I wrong? And much more important: How do I make this stuff secure?
rpm -Vv openssh will give you a hint about what has been modified.
oki,
Steffen
Roman.
Hi! On Thu, 27 Jun 2002, Roman Drahtmueller wrote:
Actually, rcsshd restart should stop the daemon with the pid from /var/run/sshd.pid. Then a new daemon would start up, writing its pid to the same file. The running instances of sshd which handle active connections should not get touched. There used to be a killall to nuke running daemons, but this is hundreds of years ago.
However, in SuSE 7.0 (and possibly other versions) there used to be the problmen that "rcsshd restart" stopped the "main" sssh daemon, but refused to restart it if there were old children still running... (I hope this was fixed in the update packages?!?)
To make sure it works, I usually do the following: cp /usr/sbin/sshd /sshdd /sshdd -p 23 rm /sshdd # log on to port 23 killall sshd rcsshd start # log on to port 22 killall sshdd
Cool.:-) I used the following: echo "rcsshd restart" | at now + 2 minutes and then logged out of all ssh sessions. Of course, that's slightly more risky than your approach... Martin
On Jun 27, Martin Köhling <mk@lw1.cc-computer.de> wrote:
echo "rcsshd restart" | at now + 2 minutes When doing such sensitive things that shouldn't be aborted, screen is very useful. If you cut your connection, the commands inside the screen still run (no HUP :).
Markus -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus@gaugusch.at X Against HTML Mail / \
* Roman Drahtmueller wrote on Thu, Jun 27, 2002 at 12:16 +0200:
Actually, rcsshd restart should stop the daemon with the pid from /var/run/sshd.pid. Then a new daemon would start up, writing its pid to the same file. The running instances of sshd which handle active connections should not get touched. There used to be a killall to nuke running daemons, but this is hundreds of years ago.
Well, but *I* did additionally a "killall" on the consolse, and there was no sshd process running before start.
To make sure it works, I usually do the following: [...] Yes, I did it very similar.
Any hints?? What did I wrong? And much more important: How do I make this stuff secure?
rpm -Vv openssh will give you a hint about what has been modified.
Here is a full list: S.5....T c /etc/ssh/sshd_config sshd_config, since I set "UsePrivilegeSeparation yes". But no chroot, no sshd user. How do I make this stuff secure? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Thu, Jun 27, 2002 at 11:39:32AM +0200, Steffen Dettmer wrote:
Seems that it does not work for me. I upgraded as described, but didn't found a chrooted or setuid=sshd process after restarting sshd.
You're getting something wrong here. The user sshd is just used during the authentication-process. http://www.citi.umich.edu/u/provos/ssh/priv.jpg shows it pretty well. In that picture previlidged == root, unprevilidged == sshd and user previlidged == as whatever user you want to login. Keep in mind, that bind to ports < 1024 root previledges are needed. I'll try to explain the priv-sep process: A with root previledges running sshd process listens on port 22. When someone tries to login via ssh, this sshd forks, chroot()s to /var/empty and changes his uid to the uid of the user sshd. At this time the forked process running as user:sshd takes care about the networktraffic that's needed for the auth-process and sends the results to the as root running process. When the authentication is done, the as root running sshd forks another child. The childs uid is changed to the uid of the user logging in. Now the as user:sshd running process is no longer needed. You can observe it by doing this: Let's say erde is our local computer and merkur the remote one. homy@erde:~ > lsof | grep -E "^sshd[ 0-9]*sshd" homy@erde:~ > As you can see, there's no process running that has the uid of the user:sshd. homy@merkur:~ > ssh erde homy@erde's password: Wait there, don't enter the password. homy@erde:~ > lsof | grep -E "^sshd[ 0-9]*sshd" sshd 3054 sshd mem REG 3,5 306256 48616 /usr/sbin/sshd sshd 3054 sshd mem REG 3,2 99756 31020 /lib/ld-2.2.5.so sshd 3054 sshd mem CHR 1,5 48632 /dev/zero [...] As you can see we're now in the authentication process and we have indeed a process that uses user:sshd's uid. erde:~ # ls -i /proc/3054/root 95975 . 46465 .. erde:~ # ls -i /var/empty 95975 . 46465 .. As you can see here, this process's / indeed is chroot()ed to /var/empty. I hope this helps a bit. Cheers, Frank Heimann -- -- -- | "The price of freedom is eternal vigilance." | | -- Thomas Jefferson | | ------------------------------------------------------------- | |"If we want to avoid zombies, we have to wait for our children"| | -- W. Richard Stevens, | | in "Advanced Programming in the UNIX Environment", p. 281 | -- -- My public key is available at http://www.unixisnot4dummies.org/homy.pgp
* Frank Heimann wrote on Thu, Jun 27, 2002 at 16:48 +0200:
On Thu, Jun 27, 2002 at 11:39:32AM +0200, Steffen Dettmer wrote: The user sshd is just used during the authentication-process. http://www.citi.umich.edu/u/provos/ssh/priv.jpg shows it pretty well.
A with root previledges running sshd process listens on port 22. When someone tries to login via ssh, this sshd forks, chroot()s to /var/empty and changes his uid to the uid of the user sshd.
Ohh I see! There isn't "an authentication process" but an authentication process for each connection, forked on demand!
I hope this helps a bit.
Yes, of course, now it's clear, thank you very much! oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Thu, 2002-06-27 at 05:39, Steffen Dettmer wrote:
Seems that it does not work for me. I upgraded as described, but didn't found a chrooted or setuid=sshd process after restarting sshd.
The chroot process only shows up when a ssh connection is requested and before a successful login. Charles -- Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)
participants (15)
-
Bob Vickers -
Chad Whitten -
Charles Philip Chan -
Christoph Illnar -
Frank Heimann -
Frank Steiner -
Harald Nikolisin -
Markus Gaugusch -
Martin Köhling -
Olaf Kirch -
Olivier M. -
Roman Drahtmueller -
Stefan Eissing -
Steffen Dettmer -
Sven 'Darkman' Michels