July 2002 - openSUSE Security - openSUSE Mailing Lists

RE: [suse-security] TCP port 113
by Herbrechter, Marc 16 Jul '02

16 Jul '02

oliver.z wrote: > could anyone explain me why I get different results when I > doing nmap -sS <ip> > from a remote site to my system and when I do nmap -sS > localhost on my system? You are running a packet filter, so you should know. > From remote site I get results with a closed tcp port 113, > with nmap with localhost not. "Not" what? "Not" closed, "not" opened? What does ´netstat -ltnp´ say? > And of course, why respond the system to tcp port 113, even > if inetd is not startet? Port 113 is the identd. It is not fired up by inetd in most cases.

1 0

how to check if sshd update was succesful?
by Dominik Schwald 16 Jul '02

16 Jul '02

Hi, i updated the sshd on a SuSE 7.2 i386 Machine by installing openssh-2.9.9p2-103.i386.rpm and restarting sshd with echo "rcsshd stop; rcsshd start"|at now + 3 minutes as discribed in SuSE-SA:2002:024. Now i'd like to verify that i got the 'patched version' of sshd running. How can i do that? Thanks, dominik

4 5

RE: [suse-security] Password Encryption
by Alan Rouse 15 Jul '02

15 Jul '02

Tobias wrote: >> Larger salt would be better... 4096 probably is not a large enough >> factor nowadays. LDAP uses 8 to 16 bytes of salt. > >Hmm, you mean it'd be worthwhile to do the math up there? There's no expensive (ie. large integer) math required. You just create a large enough random salt and append it to the password before hashing (which involves simple bit operations, not complicated math). The result is that you will be hashing a slightly larger string. For that little bit of effort by the good guy, we've increased the bad guy's effort by 2^128 (for 16 random 8-bit bytes of salt). A pretty good tradeoff! >Thanks for clearing up some of the misconceptions I may have caused, BTW. >:-) No problem. I get an education every time I read this list, and I'm glad to contribute a tiny morsel in return ;->

1 0

Re: [suse-security] mount sambashare with non-root-user
by Scott Courtney 15 Jul '02

15 Jul '02

On Monday 15 July 2002 05:32 am, Reckhard, Tobias wrote: > Hi > > You wrote: > > BTW, non-root mounts do not have to have the mount point > > owned by the user, > > nor do they have to be in the user's home directory. I do > > user-level mounts > > on my system all the time with neither of these constraints. > > This is entirely true. However, it seems that (at least some versions of) > smbmount enforces this strange behaviour. The mount command doesn't care > about ownership, but smbmount does.. For whatever reason.. Very interesting. I didn't know about this, and I thank you for the enlightenment. I'am taking the liberty of copying this to the list because I'll bet I'm not the only one who didn't know that smbmount's security behavior doesn't exactly mimic a regular mount. Thanks! Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them courtney(a)4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/courtney.pubkey

1 0

SuSE Security Announcement: Resolver (SuSE-SA:2002:026)
by Olaf Kirch 15 Jul '02

15 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: bind, glibc Announcement-ID: SuSE-SA:2002:026 Date: Tue Jul 09 2002 Affected products: 7.0, 7.1, 7.2, 7.3, 8.0 SuSE Linux Enterprise Server for S/390, SuSE Linux Database Server, SuSE eMail Server III, SuSE Linux Enterprise Server, SuSE Linux Firewall on CD Vulnerability Type: buffer overflow Severity (1-10): 3 SuSE default package: yes Cross References: CERT CA-2002-19; CVE CAN-2002-0651 Content of this advisory: 1) security vulnerability resolved: buffer overflow in dig, host, and nslookup utilities. 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 A vulnerability has been discovered in some resolver library functions. The affected code goes back to the resolver library shipped as part of BIND4; code derived from it has been included in later BIND releases as well as the GNU libc. The bug itself is a buffer overflow that can be triggered if a DNS server sends multiple CNAME records in a DNS response. This bug has been fixed for the gethostbyXXX class of functions in GNU libc in 1999. Unfortunately, there is similar code in the getnetbyXXX functions in recent glibc implementations, and the code is enabled by default. However, these functions are used by very few applications only, such as ifconfig and ifuser, which makes exploits less likely. We will make updated glibc packages available as they have gone through our build system, but without separate announcements. Until glibc patches are available, we recommend that you disable DNS lookups of network names in nsswitch.conf. Simply replace the line containing the tag "networks:" with this line: networks: files In the unlikely event that you've configured any name to network mapping via DNS, make sure you copy this information to /etc/networks. The resolver bug is also present in the libbind library included in BIND. This library is used by utilities from the bindutil package. We are therefore providing security updates for bind8 that address this vulnerability. As communicated previously (1), the SuSE security team is not providing fixes for BIND4 anymore. The bind9 packages shipped by SuSE are not vulnerable. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Apply the updata packages (bindutil, bind8) package using rpm -Fvh bind*.rpm If you are running the BIND name server, you should restart the name server process by issuing rcnamed restart Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. References: (1) http://www.suse.de/de/support/security/adv004_ssh.html ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - There is a format string bug in the "nn" news reader that can be exploited by a malicious NNTP server to execute arbitrary commands within the client user's account. We will be releasing updated packages. ______________________________________________________________________________ 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(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 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(a)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(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 annoucements 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 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(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.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQEVAwUBPSyDnney5gA9JdPZAQFmswf8DjL+C4M3TP+iySk7sPqR7znMEO1+Zu5v SA64ygjQthQUfJAX3LSWndmb7WEZyRvxeH7eOwqftv3o6846c1NdEQfnrJrtv4Ah c6mPXBnYbY0J3fR9yoz8DdvsOQ/OcOIfzUjNiC5arxEyoD+LbS6bjtNorUio5s/P q6otWJt+vkVhYHEyZJeA+4T1mrXs1dpGXUh1+k4kytfQ5d3w1Sv2QE5wahB0d0xD zUXGtGEWTSaO5r3OF3W6zY7pC2hpVTXPrNsgX+WsUFZhl6hgdEhkMAQl7H7doNVy Ofxp9XrHrDhwEvGKBALMJ8LmjdR0ES+NOs0qGTJTpjQCTuuG8TiOkw== =e3AP -----END PGP SIGNATURE-----

7 9

RE: [suse-security] bind upgrade on 7.1
by Reckhard, Tobias 15 Jul '02

15 Jul '02

[...] > bind and could not do nslookup. changed ip in [...] What do you mean, when you say that you "could not do nslookup."? Tobias

1 0

APACHE: apache-1.3.20-66.i386.rpm
by Fabrizio Di Meo 15 Jul '02

15 Jul '02

Hi there, I'm using SuSE 7.3 and I patched the Apache web server to 1.3.20-66 while www.apache.org reports 1.3.26 as new bugs fix release. Is this new release available for SuSE 7.3? Also using YOU (yast2) the most recent patch is always the 1.3.20-66.... what's wrong? Thank you. Fabrizio --------------------------------- Scarica il nuovo Yahoo! Messenger: con webcam, nuove faccine e tante altre novità!

4 5

Re: [suse-security] Samba and SuSE Firewall 2
by Philippe Vogel 13 Jul '02

13 Jul '02

>But with the new SuSE Firewall 2 I unable to get this to work. When >I set FW_SERVICE_SAMBA, Samba works perfectly for the internal network, but >from the outside, it is possible to get the Netbios name. When I disable >FW_SERVICE_SAMBA, everything is secure, but computers from the internal >network do not work with Samba anymore. I also haven't protected the new >firewall against the internal network. >Is it possible to get Samba to work like it did with the old Firewall, from >outside nothing, from inside everything? Change /sbin/SuSEfirewall2 Go to line after: ######################### # Special SAMBA support # ######################### Change existing entries to this: test "$FW_SERVICE_SAMBA" = yes && { $LAA $IPTABLES -A INPUT -j LOG ${LOG}" fp=NI a=ACCEPT " -p udp --dport 137:138 -s $LOCALNET_1 # Samba for local Net only $IPTABLES -A INPUT -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -p udp --dport 137:138 -s $LOCALNET_1 # Samba for local Net only } Add LOCALNET_1"123.123.123.0/24" to allow net 123.123.123.0/24 Access to local Samba Server! Philippe P.S.: I added some rules for blocking as well, this is a feature I miss in SuSEfirewall1/2 as well!

3 4

[suse-security] SuSEfirewall2, DMZ, sendmail and lotus - resend with config files
by Werner Schalk 13 Jul '02

13 Jul '02

Hi all, I have a problem with susefirewall2 and I hope somebody could help me. You can find the config files on a site of my friend: www.wolfgarten.com/fw/ suse-security(a)suse.com seems to filter attachments I did attach them to the mail I send yesterday of course! I have a leased line (2mbit, dedicated ip) to the net, a dmz and a local lan with a lotus server. I would like to receive mails from the internet for my domain which should come in and be forwarded to the smtp server in the dmz which will forward them to the lotus server. So here's a graph for that: inet | | server1, 3 network devices eth0: 192.168.100.1 (link to LAN) eth1: 192.168.50.1 (link to DMZ) eth2: 193.X.Y.Z (link to net) | | |-------------------server2, 1 networkcard (192.168.50.2) | running mail service (sendmail) | and apache web server | | | server 3, 2 network devices | eth0: 10.0.49.10 (link to LAN) | eth1: 192.168.100.2 (link to server1) | V in the lan: lotus server Currently mails come in and are forwarded to a sendmail server which is running on the server2 (dmz). From there they should be forwarded to server3 and finally to the lotus server (and vice versa). I tried to configure susefirewall2 in the way that connecting to port 25 on server1 forwards automatically to the dmz one or if it comes from the dmz to the server3 (and from there to the lotus server). But when I try to connect to 192.168.100.1 (port 25) from the server 3 and to 192.168.50.1 from the dmz I get the error messages "connection refused" although I opened the ports and did some redirect rules. Maybe somebody could have a look at my attached config file I currently have absolut no clue what might be the reason for this misconfiguration. Bye + thanks a lot, Werner

2 2

SuSE daily security: af_packet
by M. Neubert 12 Jul '02

12 Jul '02

Hello, can anyone explain me this event in SuSE daily security output: ---cut--- OLD: /var/lib/secchk/security-report-daily Fri Jul 12 00:00:06 2002 NEW: /var/lib/secchk/security-report-daily.new Sat Jul 13 00:00:05 2002 * Changes (+: new entries, -: removed entries): + af_packet ---cut--- I have found only the same question, but no answer. http://lists.suse.com/archive/suse-security/2001-Nov/0188.html I don't have any critical entry arround this time above in my logfiles. Thanks & Regards Mario

1 0