October 2004 - openSUSE Security - openSUSE Mailing Lists

SUSE Security Announcement: xpdf, gpdf, kpdf, pdftohtml, cups (SUSE-SA:2004:039)
by Thomas Biege 26 Oct '04

26 Oct '04

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SUSE Security Announcement Package: xpdf, gpdf, kdegraphics3-pdf, pdftohtml, cups Announcement-ID: SUSE-SA:2004:039 Date: Tuesday, Oct 26th 2004 10:30 MEST Affected products: 8.1, 8.2, 9.0, 9.1, 9.2 SUSE Linux Enterprise Server 8, 9 SUSE Linux Desktop 1.0 Vulnerability Type: remote system compromise Severity (1-10): 5 SUSE default package: yes Cross References: CAN-2004-0888 CAN-2004-0889 Content of this advisory: 1) security vulnerability resolved: - integer overflows - arithmetic errors problem description 2) solution/workaround 3) special instructions and notes 4) package location and checksums 5) pending vulnerabilities, solutions, workarounds: - freeradius denial of service problems - mpg123 - squid 6) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion Xpdf is a widely used fast PDF file viewer. Various other PDF viewer and PDF conversion tools use xpdf code to accomplish their tasks. Chris Evans found several integer overflows and arithmetic errors. Additionally Sebastian Krahmer from the SuSE Security-Team found similar bugs in xpdf 3. These bugs can be exploited by tricking an user to open a malformated PDF file. As a result the PDF viewer can be crashed or may be even code can be executed. 2) solution/workaround Due to the wide usage of xpdf-based code we do not recommend switching to another PDF viewer as a workaround. You have to install the updates. 3) special instructions and notes Please restart all running instances of xpdf, gpdf, kpdf, pdftohtml, cups after updating successfully. 4) package location and checksums Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command "rpm -Fhv file.rpm" to apply the update. Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. Cups packages and all 9.2 packages will be available later. x86 Platform: SUSE Linux 9.1: ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/pdftohtml-0.36-112.3.i… f17866987c9099ed8b0395d184adfffc ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/xpdf-3.00-64.21.i586.r… d648d6e96013cc339dd424041f8bc973 ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/gpdf-0.112.1-26.3.i586… 16864a7b7652a3183f9f8cac034cf70e ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kdegraphics3-pdf-3.2.1… 8f09aa7927d9cdcfc52ab06e520b2441 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/pdftohtml-0.36-112.3.i… 2d3da1271fc9e072186fca6aa1de8c5c ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/xpdf-3.00-64.21.i586.p… 093d0aaa7f4fbe24afc722057cbe334e ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/gpdf-0.112.1-26.3.i586… 3af8141ddfbdf558afdf4f2f8f94a9f8 ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kdegraphics3-pdf-3.2.1… 0d765c907e89a91186e03d8c8de87857 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/pdftohtml-0.36-112.3.sr… d4892578f2d84c1bdbc36b0df9341607 ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/xpdf-3.00-64.21.src.rpm d4c06775143e5e6fec7bc544d248daee ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/gpdf-0.112.1-26.3.src.r… cfda8ff6f352e1bc4f827a3118521b25 ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/kdegraphics3-3.2.1-67.6… bb4d96dd72f0ee94315afd7b4c81e16b SUSE Linux 9.0: ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/pdftohtml-0.36-118.i58… dc822cef09e27e169acd94cda1fb622a ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/xpdf-2.02pl1-141.i586.… c99912bc5656546b028a8c4fe0473a75 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/pdftohtml-0.36-118.i58… 58b8a44ae02482d19c73959bfd85e85e ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/xpdf-2.02pl1-141.i586.… 8055fbed4ac1e664706701e3b7d3e1bc source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/pdftohtml-0.36-118.src.… 35e37ded2db7d772d854748e606f42d0 ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/xpdf-2.02pl1-141.src.rpm d42fe2976009b8ab44d6c166caf0840c SUSE Linux 8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/xpdf-2.01-137.i586.rpm e198f2fc43f1f455676a9dc1ee42af5e patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/xpdf-2.01-137.i586.pat… acb5181c10c7b365cca71ae307b11553 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/xpdf-2.01-137.src.rpm aada3bee6ac1517f50468777c49d8d91 SUSE Linux 8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/xpdf-1.01-255.i586.rpm c0d7beba46d02e1090e9b6c7795a10c3 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/xpdf-1.01-255.i586.pat… ac395b4518a4c83d2af7805f35626a22 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/xpdf-1.01-255.src.rpm 5ec84289ef8ca520e78cc80360d05665 x86-64 Platform: SUSE Linux 9.1: ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/pdftohtml-0.36-112… 2b0b08249164043db0e3a5b080b03f1d ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/xpdf-3.00-64.21.x8… c10bbbb43b8af6bc4da4922ce2afaede ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/gpdf-0.112.1-26.3.… 7021ae8a2e9bc809240c8e953ef74fab ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/kdegraphics3-pdf-3… 94200c51e06e9f31bc13139ea66c1626 patch rpm(s): ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/pdftohtml-0.36-112… e0d057eeb94492d62be6794dfde196c9 ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/xpdf-3.00-64.21.x8… ae9382a68c4d424cdee65324208f9e84 ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/gpdf-0.112.1-26.3.… 33a0a7fd7b0758175f465f8f1fa6ce36 ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/kdegraphics3-pdf-3… c4629d75d822cf47b243cf34bd8cbacb source rpm(s): ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/pdftohtml-0.36-112.3.… f2acee920bd51b347e072463edc8f6bc ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/xpdf-3.00-64.21.src.r… 5b5c9c5d9aa1ddff06f56f83cf0365d9 ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/gpdf-0.112.1-26.3.src… 2e2b8e6903b724462f30c07db1e76755 ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/kdegraphics3-3.2.1-67… e6988ea49a337ebd49f42d15afdeb188 SUSE Linux 9.0: ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/pdftohtml-0.36-118… 942676168c21ac7253637dd3312e35d1 ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/xpdf-2.02pl1-141.x… 7a5076aec7aae7e6e05bf8d0f6b5e523 patch rpm(s): ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/pdftohtml-0.36-118… b14da314a640e3afd3e72f417937c461 ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/xpdf-2.02pl1-141.x… fd4047d3c5392d63040e576effb32df5 source rpm(s): ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/pdftohtml-0.36-118.sr… 5300f04533ee5b490e1f7de0a29fd705 ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/xpdf-2.02pl1-141.src.… dd9b695199beaea8122037705eb1a581 ______________________________________________________________________________ 5) pending vulnerabilities in SUSE Distributions and Workarounds: - freeradius Several bugs that can be abused to remotely crash freeradius have been discovered (CAN-2004-0938, CAN-2004-0960, CAN-2004-0961). New packages will be available soon. - mpg123 A buffer overflow in mpg123 has been discovered. New packages will be available soon. - squid A bug in the ASN.1 parser of the SNMP module has been fixed which would have allowed an attacker to crash squid (CAN-2004-0918). Updates will be available soon. ______________________________________________________________________________ 6) 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(a)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 un-installed 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(a)suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the top-level 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(a)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(a)suse.com>. suse-security-announce(a)suse.com - SUSE's announce-only mailing list. Only SUSE's security announcements are sent to this list. To subscribe, send an email to <suse-security-announce-subscribe(a)suse.com>. For general information or the frequently asked questions (faq) send mail to: <suse-security-info(a)suse.com> or <suse-security-faq(a)suse.com> respectively. ===================================================================== SUSE's security contact is <security(a)suse.com> or <security(a)suse.de>. The <security(a)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 clear-text 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(a)suse.de> pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build(a)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: GnuPG v1.2.2 (GNU/Linux) iQEVAwUBQX4pgXey5gA9JdPZAQHb0wf+P6dH8VFUyh7nVV8xd6tb/ccBFtpMOaCa Wq1i0754TcOpk6RKpVpzNEjB2bSh51aWvRykVEguQdo1MlpNZdlE5Zc/T38S+B3U H2hzK9o2d9FAUxHFEpjSRRQxFdDEP7Hx3JV/OnVIqZfycVij0MaTSN6j9c7GSUZP SQ97CdbMTgRe25lL2k1FofNaYpDKyng/yF78pxD8dI79abbupcJo7BokPtZ6yEGZ AL2PT3OhyYX3HJphNJ+4wcRIS71IWhB54kA0igB1Qp83ltROgbz1rr9OgUwf3fDi zvYGxNX4Eu0rxiaU6U81z+m5dScUoNMSM8CK+uZK/dn3iSHHNzjaLA== =j7Hh -----END PGP SIGNATURE-----

1 0

egress filtering?
by Janne Karhunen 26 Oct '04

26 Oct '04

Hi, Any chances SUSEFirewall2 could be setup to do egress filtering? I'd only like to allow outgoing traffic to certain ports - so is there an easy way, or do i have to set up custom rules? -- // Janne

2 2

yay. the bots have the list again.
by Mathias Homann 25 Oct '04

25 Oct '04

one post to the list, three automated replies from bots or MTAs. great. IMO its time that suse starts some serious thinking about how subscriptions to lists could be checked. bye, MH -- Die unaufgeforderte Zusendung einer Werbemail an Privatleute verstößt gegen §1 UWG und 823 I BGB (Beschluß des LG Berlin vom 2.8.1998 Az: 16 O 201/98). Jede kommerzielle Nutzung der übermittelten persönlichen Daten sowie deren Weitergabe an Dritte ist ausdrücklich untersagt! gpg key fingerprint: 5F64 4C92 9B77 DE37 D184 C5F9 B013 44E7 27BD 763C

10 28

Protocol SSH1
by Mauro Teani 25 Oct '04

25 Oct '04

Protocol SSH1 is safe? I mean, if many users have access to a remote server on wich works a ssh server upgraded to the last patch, and i do it by mean of a ssh1 client (teraterm for example) may i be sure that the connection is safe or i must change to SSH2 protocol? Which type of attack may i expect as well than buffer-overflow? thanks in advance Teani Mauro Teani(a)osratoscana.it Tel. 0583 424700 Fax 0583 424750 http://www.osratoscana.it Il testo e gli eventuali documenti trasmessi contengono informazioni riservate al destinatario indicato. La seguente e-mail è confidenziale e la sua riservatezza è tutelata legalmente dal Decreto Legislativo 196 del 30/06/2003 (Codice di tutela della privacy). La lettura, copia o altro uso non autorizzato o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere, immediatamente, alla sua distruzione.

7 8

How to secure Suse rescue distro ?
by Robert Rozman 24 Oct '04

24 Oct '04

Hi, I intend to use Asterisk pbx with minimal Suse install. I'd also like to create installation CDROM and later also live CD. I've heard from quite some people that they use Asterisk with ssh+Suse rescue system as minimal Suse installation. I wonder how secure can that be out of the box, and what steps should I do to secure it ? Are there any scripts that would help me to do it ? Thanks in advance and sorry for newbie questions, Regards, Robert.

1 0

limiting sftp users to specific dir
by Hugo 24 Oct '04

24 Oct '04

Hello! I finally changed my servers from Windows to Linux (SuSE 9.1). In windows I used to have F-Secure SSH-server (student licence) and I had set it up so that I could access via SFTP all the system (I also had SSH access), but others only their own directory. And what more, the SFTP directories were defined as d:\sftp\%username%. Very clean system with no problems for the users. Bear with me as I probably do not know how to ask this in a simple way and I do not know the right terms... I'll try to explain what I would like to do (almost the same as in Windows): With SuSE I had SSH server up and running very fast. So now I have different types of users: 1) Me: local user, remote with SSH and X + SCP/SFTP (unlimited) 2) Family: local users, remote with SFTP limited to users home dir (or some empty dir under it) 3) Remote family: only remote SFTP limited to some empty dir somewhere (not necessarily under home dir) The current situation with SuSE defaults is that if I create a user and use WinSCP to access the server with that user, they can see just about every file there including other users home dirs. Not good. (I thought be default Linux was more secure...) Also, just the complexity of all the stuff that is in the users home dir would confuse many users. They just need to see one empty dir where to transfer files from and to. For those that log in locally, this dir should be under the home dir, like Documents. And the 3rd type of users should only have access to one dir that is completely empty except for their own files. First question: Can this be done? (Please don't tell me I have to go back to windows server... ) Second: how? Sorry for not being more exact in defining the problem. Hopefully you got the idea. I'm not new to computers and I'm quite happy to edit config files... except that this time I didn't find what to edit (sshd_conf doesn't seem to have options for limiting users like this). -- HG

6 12

ssh/telnet Question
by Don Parris 24 Oct '04

24 Oct '04

I've just read an article about using ssh/telnet. The article suggested setting a Linux box in front of a mainframe, thus allowing users to telnet to the mainframe _after_ securely connecting to the Linux box via ssh. The Linux Security Admin Guide also suggests not installing (or deleting) services you know you won't be using to prevent attackers from using them to access your system. So, other than using a Linux box as a front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.? Based on the SAG, I could eliminate telnet, etc., as I cannot think of any reason to use those services in my LAN (which has no mainframe). SUSE installs these services by default (at least as of 8.0), so I'm thinking about removing them, unless someone can offer good reasons to retain them. My LAN consists of 6 SUSE 8.0 boxes and currently has no connection to the outside world (though that may come at a later date). I want to be sure I thoroughly understand security issues and that I am implementing the best practices for my LAN _before_ I think about connecting it to the outside world. Thanks in advance for your input. Don -- DC Parris http://matheteuo.org/ http://chaddb.sourceforge.net/ "Free software is like God's love - you can share it with anyone anytime anywhere."

8 12

Re: [suse-security] limiting sftp users to specific dir
by Hugo 23 Oct '04

23 Oct '04

Hi! On Fri, 22 Oct 2004 14:34:09 -0500, James M. Patton - Contractor <mpatton(a)sc.army.mil> wrote: > > Quite complicated process, but I think I can follow that... except > > that it's not really what I want either. First of all, the user would > > have lot's of strange dirs and files in their new home dir. It also > > has the same problem that the shell needs to be changed, so what > > happens when they login locally? > > I would suggest reading the fine manual (RTFM) on this process. It is only > difficult for those who probably don't have the mental capacity to > administer a Linux system anyway - which since you're at least trying to do > I would assume that you may. I think that was quite insulting comment! I did read the manual, and that's what I commented on. See, in Windows I used to SSH server from SSH.com. There was a simple list (actually in GUI, but that doesn't matter) where I listed those users that were to be limited to their own directories. On another line, I specified that the dir is d:\sftp\%username% for instance. Comparing that, well yes I do think it is complicated. But that is not the same thing as saying that I didn't understand any of it! I'm trying to not to make any predictions about your mental capacity! I first answered all your points, but it cam clear to me that you are just picking up a fight here. The "evil empire" kind of gives you away... I thought here would be civilized people on this list that have good enough self esteem that another OS can be mentioned. (I would like to hear though why something that is designed from ground up as friendly desktop OS would mean it's not safe? I think Mac OS X is called being friendly...?) And sorry for questioning Linux security. I guess your answer for why SuSE 9.1 by default lets all users see others files, would be that: that's Linux if you are stupid then it's your own fault. And that is just the thing that I'm trying to avoid (i.e. by not knowing enough and leaving some thing open that is for some odd reason left open in the first place.) So, sorry for not knowing the right term! And sorry to ask about it too! Chroot just didn't come to my mind when looking at dictionary to find the right terms! I read the manual, but it didn't answer quite a few of my questions, like what does that (chrooting SSH) mean for the user who also logins locally? But never mind, I'll try to find some Linux "pros" that can help me (and doesn't attack me immediately if I do not understand everything from a manual or FAQ) - you obviously do not know or didn't even read my problem description. -- HG

1 0

RE: [suse-security] limiting sftp users to specific dir
by James M. Patton - Contractor 22 Oct '04

22 Oct '04

Hello, > > If you want to use the openssh server, you'll need to patch it. For > > more information, see: > > > > http://chrootssh.sourceforge.net/index.php > Quite complicated process, but I think I can follow that... except > that it's not really what I want either. First of all, the user would > have lot's of strange dirs and files in their new home dir. It also > has the same problem that the shell needs to be changed, so what > happens when they login locally? I would suggest reading the fine manual (RTFM) on this process. It is only difficult for those who probably don't have the mental capacity to administer a Linux system anyway - which since you're at least trying to do I would assume that you may. Secondly, as the documentation on the site I sent you has you set things up, the /bin /usr and other required directories are one level below the users' actual home directories, so the would not have "lot's" of strange dirs and files in their new home directory. Thirdly, as the Fine Manual says, you can statically compile any shell to work within this structure - so you could have bash, tcsh and others available for users to use. Finally, I would strongly suggest to you that you become familiar with http://www.google.com/linux if you're thinking about running Linux. Pros are likely to help you a little, but if you're not willing to even read the documentation on the links they send you, you will quickly find that you get ignored in general. There are already many great resources on the net - and google can help you find them easily. The links I sent you were from going to google and typing "chroot sftp" - and they were on the first page of the results. Also, on your security comment - I don't even how to reply to such an asinine comment. Only those who obviously do not know what they are talking about would even think that a system which was designed from the ground up as a user friendly desktop OS would be more secure than a tried and true UNIX-like variant. Just look at the CERT notifications for the past year - the numbers tell the truth. When a OS vendor embeds their own browser into my operating system and does not allow me to completely remove it from the system, then has many, many security problems with said browser, I would say that that operating system is very insecure. Not to mention that out of the box the user of the system is essentially running said browser as root! What a joke! Good luck with your attempts with learning about Linux. You can think I am a jerk for what I've said about RTFM, but if you take it to heart and actually try to find and learn things on your own, you will be much better off whether you stick with Linux or decide to go back to purchasing your software from the evil empire. BTW: All comments I make are my own, and do not reflect the opinion of my employer. -----Original Message----- From: Hugo [mailto:hg.list@gmail.com] Sent: Friday, October 22, 2004 11:17 AM To: suse-security Subject: Re: [suse-security] limiting sftp users to specific dir Hi! On Thu, 21 Oct 2004 10:23:31 -0500, James M. Patton - Contractor <mpatton(a)sc.army.mil> wrote: > One way would be to use the commercially available SSH server. For more > information, see: > > http://www.derkeiler.com/Mailing-Lists/securityfocus/focus-linux/2001-11/000 > 1.html Ah, this is exactly what I'm looking for - except that it's not free... even though they sound like it could just be downloaded from SSH.com... And this really can not be done with the OpenSSH that comes with SuSE 9.1? Another thing that bothers is that the shell needs to be set to something else... how would this affect the users that also login from the console (they should not be chrooted then, only when accessing the computer with SFTP)? > If you want to use the openssh server, you'll need to patch it. For more > information, see: > > http://chrootssh.sourceforge.net/index.php Quite complicated process, but I think I can follow that... except that it's not really what I want either. First of all, the user would have lot's of strange dirs and files in their new home dir. It also has the same problem that the shell needs to be changed, so what happens when they login locally? -- HG -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help(a)suse.com Security-related bug reports go to security(a)suse.de, not here

1 0

RE: [suse-security] limiting sftp users to specific dir
by James M. Patton - Contractor 22 Oct '04

22 Oct '04

One way would be to use the commercially available SSH server. For more information, see: http://www.derkeiler.com/Mailing-Lists/securityfocus/focus-linux/2001-11/000 1.html If you want to use the openssh server, you'll need to patch it. For more information, see: http://chrootssh.sourceforge.net/index.php For more information. Mike Patton USASMDC - Simulation Center Systems Analyst Madison Research Corporation (MRC) Phone: (256) 955-3706 Email: mike.patton(a)sc.army.mil This email capability is supported by Department of Defense systems and is subject to monitoring. Please refrain from using this address for non-Government purposes. -----Original Message----- From: Hugo [mailto:hg.list@gmail.com] Sent: Thursday, October 21, 2004 10:09 AM To: suse-security Subject: [suse-security] limiting sftp users to specific dir Hello! I finally changed my servers from Windows to Linux (SuSE 9.1). In windows I used to have F-Secure SSH-server (student licence) and I had set it up so that I could access via SFTP all the system (I also had SSH access), but others only their own directory. And what more, the SFTP directories were defined as d:\sftp\%username%. Very clean system with no problems for the users. Bear with me as I probably do not know how to ask this in a simple way and I do not know the right terms... I'll try to explain what I would like to do (almost the same as in Windows): With SuSE I had SSH server up and running very fast. So now I have different types of users: 1) Me: local user, remote with SSH and X + SCP/SFTP (unlimited) 2) Family: local users, remote with SFTP limited to users home dir (or some empty dir under it) 3) Remote family: only remote SFTP limited to some empty dir somewhere (not necessarily under home dir) The current situation with SuSE defaults is that if I create a user and use WinSCP to access the server with that user, they can see just about every file there including other users home dirs. Not good. (I thought be default Linux was more secure...) Also, just the complexity of all the stuff that is in the users home dir would confuse many users. They just need to see one empty dir where to transfer files from and to. For those that log in locally, this dir should be under the home dir, like Documents. And the 3rd type of users should only have access to one dir that is completely empty except for their own files. First question: Can this be done? (Please don't tell me I have to go back to windows server... ) Second: how? Sorry for not being more exact in defining the problem. Hopefully you got the idea. I'm not new to computers and I'm quite happy to edit config files... except that this time I didn't find what to edit (sshd_conf doesn't seem to have options for limiting users like this). -- HG -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help(a)suse.com Security-related bug reports go to security(a)suse.de, not here

2 1