August 1999 - openSUSE Security - openSUSE Mailing Lists

SuSE Security Announcement
by Thomas Biege 19 Aug '99

19 Aug '99

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: i4l (xmonisdn) Date: Wed Aug 18 10:39:00 CEST 1999 Affected: all Linux distributions using xmonisdn in conjunction with old libc ______________________________________________________________________________ A security hole was discovered in the package mentioned above. Please update as soon as possible or disable the service if you are using this software on your SuSE Linux installation(s). Other Linux distributions or operating systems might be affected as well, please contact your vendor for information about this issue. Please note, that that we provide this information on as "as-is" basis only. There is no warranty whatsoever and no liability for any direct, indirect or incidental damage arising from this information or the installation of the update package. ______________________________________________________________________________ 1. Problem Description xmonisdn which is part of the i4l package is installed setuid root by default. To control and display the status of the ISDN network connections xmonisdn uses external programs, which are executed by the system() systemcall, without taking care of a safe environment. The problem arises by old libc, that don't overwrite the IFS environment variable. 2. Impact By manipulating the IFS (or PATH) environment variable an attacker is able to execute his own programs with root privileges. 3. Solution A temporary fix: /bin/chmod u-s /usr/bin/xmonisdn Install the updated package, as soon as it is available from our ftp server. ______________________________________________________________________________ Webpage for patches: http://www.suse.de/patches/index.html or try the following web pages for a list of mirrors: http://www.suse.de/ftp.html http://www.suse.com/ftp_new.html ______________________________________________________________________________ SuSE has got two free security mailing list services to which any interested party may subscribe: suse-security(a)suse.com - unmoderated and for general/linux/SuSE security discussions. All SuSE security announcements are send to this list. 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 majordomo(a)suse.com with the text subscribe suse-security or subscribe suse-security-announce in the body of the message. Or just issue a echo subscribe suse-security | mail majordomo(a)suse.com or echo subscribe suse-security-announce | mail majordomo(a)suse.com ______________________________________________________________________________ If you want to report *NEW* security bugs in the SuSE Linux Distribution please send an email to security(a)suse.de or call our support line. You may use pgp with the public key below to ensure confidentiality. ______________________________________________________________________________ This information is provided freely to everyone interested and may be redistributed provided that it is not altered in any way. Type Bits/KeyID Date User ID pub 2048/3D25D3D9 1999/03/06 SuSE Security Team <security(a)suse.de> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh 1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+ cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7 tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63 Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+ x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0 Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2 saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o L0oixF12Cg== =pIeS - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBN7uws3ey5gA9JdPZAQEkwQf7B6KwgbKBW1oNYgugAB+IuNKPyezZ9dQ4 VUj70nw/Q+RtazX2JFwQ6BoN9gFdlBJ0GJ3xvTdtXybJx4TgOuqROO5iiPJe5R1r ZObBcZzuFuCyNlbhLLoL/O1AA+sWd1HtsP6n3S3R0w5a2Dz3RArc5IkYtgCmJngB LVLLU6cctPKYZ/80fmr1vrgl6NYEwrwHDI2Ag/yidzV+iXvG0i4Q4oebgqEqrwDB EWOZY2+TSTX4+MyAVzNV72DtvV+YU8zjR8wrwAge8gF3SaUp4qWjD2JyVK27WYZm Blv2HM3+L5BDTtQ9b0L7ropy7h1Xo9y6KGxKaGMZO2U5dZoFKelm5Q== =9z0b -----END PGP SIGNATURE-----

1 0

SuSE Security Announcement
by Thomas Biege 19 Aug '99

19 Aug '99

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: samba 2.0.5 (and previous versions) Date: Tue Aug 17 07:03:33 CEST 1999 Affected: all Linux systems using samba <= 2.0.5 ______________________________________________________________________________ Some security holes were discovered in the package mentioned above. Please update as soon as possible or disable the service if you are using this software on your SuSE Linux installation(s). Other Linux distributions or operating systems might be affected as well, please contact your vendor for information about this issue. Please note, that that we provide this information on as "as-is" basis only. There is no warranty whatsoever and no liability for any direct, indirect or incidental damage arising from this information or the installation of the update package. ______________________________________________________________________________ 1. Problem Description a) A setuid root installed smbmnt could lead to a security breach due to a race condition. b) The NetBIOS name server nmbd is vulnerable to a denial-of-service attack. c) The message service of the SMB-/CIFS-server has got a buffer overflow. 2. Impact a) Users could mount arbitrary points in the filesystem, if smbmnt is setuid root. (smbmnt isn't installed setuid by default) b) If the DoS attack was triggered, the nmbd daemon uses up CPU resources. c) The buffer overflow is only exploitable, if the "message command" option is set in the smb.conf file. (these option isn't set by default) 3. Solution Install the updated package, which is available from our ftp server sine some weeks. ______________________________________________________________________________ Here is the md5 checksum of the fixed package, please verify these before installing the new package: 7cef0cbfcc8ca05b9cb96159bae80e6a samba.rpm b2c1f3cf4562f98dbe3b2074e8c66ded samba-2.0.5a-3.src.rpm ______________________________________________________________________________ You will find the update on our ftp-Server: ftp.suse.com/pub/suse/i386/update/6.1/n1/samba.rpm (i386, glibc) ftp.suse.com/pub/suse/i386/update/6.1/n1/samba-2.0.5a-0.src.rpm Webpage for patches: http://www.suse.de/patches/index.html or try the following web pages for a list of mirrors: http://www.suse.de/ftp.html http://www.suse.com/ftp_new.html ______________________________________________________________________________ SuSE has got two free security mailing list services to which any interested party may subscribe: suse-security(a)suse.com - unmoderated and for general/linux/SuSE security discussions. All SuSE security announcements are send to this list. 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 majordomo(a)suse.com with the text subscribe suse-security or subscribe suse-security-announce in the body of the message. Or just issue a echo subscribe suse-security | mail majordomo(a)suse.com or echo subscribe suse-security-announce | mail majordomo(a)suse.com ______________________________________________________________________________ If you want to report *NEW* security bugs in the SuSE Linux Distribution please send an email to security(a)suse.de or call our support line. You may use pgp with the public key below to ensure confidentiality. ______________________________________________________________________________ This information is provided freely to everyone interested and may be redistributed provided that it is not altered in any way. Type Bits/KeyID Date User ID pub 2048/3D25D3D9 1999/03/06 SuSE Security Team <security(a)suse.de> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh 1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+ cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7 tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63 Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+ x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0 Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2 saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o L0oixF12Cg== =pIeS - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBN7utM3ey5gA9JdPZAQEwZQgAmHxEJeSwHzoM+1b9crwc+j1qJwxlUQhC KKW+bajws06rToda1L2j/Yu07Oju4sl4YU7frKjCLfkBms+ZWQ+mQY8zc6/X8XAw 4FLbyIKYn2NM2DJH5OO+BcuR0OH1F8JzSAZkFiDXzxc4Cef7/Tm+WNuMsyRd458+ GWAdiUo1p4qcM0iO0DTQHoi0TFsgxsgxmbROUZrYk5CIJtt3pGc/BXBJrZpt/SnJ TnKOBH2y4N3Kl17rmwba57Tffyze9MB9vmVcLA+rb3gIUhrjvoRq6XETIDdc0IQV Lo/tNRce2/cO0LNsy72wRK44Gaxe+h2zarVBwQVTtnBwvonyxqgGew== =RZoH -----END PGP SIGNATURE-----

1 0

What's this /var/log/warn entry?
by Jan Theofel 18 Aug '99

18 Aug '99

Hello! In my /var/log/warn I found the following five lines: Aug 12 16:42:15 www /sbin/mingetty[5016]: tty1: read: Success Aug 12 16:42:16 www /sbin/mingetty[5018]: tty1: read: Success Aug 12 16:42:16 www /sbin/mingetty[5019]: tty1: read: Success Aug 12 16:42:16 www /sbin/mingetty[5025]: tty1: read: Success Aug 12 16:42:17 www /sbin/mingetty[5027]: tty1: read: Success What do they mean? Thanks, Jan -- Jan Theofel -- admin(a)rst-consulting.de -- www.rst-consulting.de rst Unternehmensberatungs- und Handelsgesellschaft mbH Bahnhofstrasse 35 * 71272 Renningen * GERMANY Phone.: +49-7159-800-450 Fax: +49-7159-800-451

1 0

FW: DOS against SuSE's identd
by Freudenberger Joerg 18 Aug '99

18 Aug '99

Hallo There are two "RTFM" answers in Bugtraq today. I crosspost these. Please have a detailled look on both. The second message has an interesting conclusion. Jörg Freudenberger -----Original Message----- From: Danton Nunes [mailto:danton@INEXO.COM.BR] Sent: Tuesday, August 17, 1999 3:20 AM To: BUGTRAQ(a)SECURITYFOCUS.COM Subject: Re: DOS against SuSE's identd Hendrik says: > The inetd.conf starts the identd with the options -w -t120 > -e. > This means that one identd process waits 120 seconds after > answering the first request to answer later request. No. accordint to inetd's man page: The -t<seconds> option is used to specify the timeout limit. This is the number of seconds a server started with the -w flag will wait for new connections before terminat- ing. The server is automatically restarted by inetd when- ever a new connection is requested if it has terminated. A suitable value for this is 120 (2 minutes), if used. It defaults to no timeout (i.e. will wait forever, or until a fatal condition occurs in the server). this does not mean that the server does nothing until <seconds> elapse. it listen to requests and serves them. if there is no request during the <seconds> period it dies. Many inetd-spawned servers do like this (e.g. xtacacsd). if something is going wrong it is not related to the -t120 flag. Maybe inetd does not know there is an identd on duty and spawns another copy. > Lets say we start 100 requests in a short period. > Due to the fact that it takes time to answer one request > more identd's will be started each eating up about 900kb > memory and waiting 120 seconds before terminating. > I tested this behaviour on different machines with different > hardware (RAM, Swap, NIC). > Each machine becomes unusable after some seconds. > This bug is in _every_ SuSE Version at least since 4.4. this bug (if the bug is the way inetd is invoked) is in almost every /etc/inetd.conf in the Unix galaxy, not specific to SuSE Linux. -- Danton Nunes | Consultoria e Serviços de Acesso à Internet InterNexo Ltda. | http://www.inexo.com.br/ mailto:danton@inexo.com.br S.J.Campos,BRASIL | PGP: 02 D1 E2 DF 21 EC 48 69 3F D5 4D 1B 5D 73 F4 B5 -----Original Message----- From: Alan Brown [mailto:alan@MANAWATU.GEN.NZ] Sent: Dienstag, 17. August 1999 04:24 To: BUGTRAQ(a)SECURITYFOCUS.COM Subject: Re: DOS against SuSE's identd On Sat, 14 Aug 1999, Hendrik Scholz wrote: > The inetd.conf starts the identd with the options -w -t120 > -e. > This means that one identd process waits 120 seconds after > answering the first request to answer later request. No, it means that the identd is persistent and will shut down after 120 seconds of idle time. What ends up happening is that a master identd process spawns a child for each request and you're running into a basic FD-based DoS attack. AB

1 0

Re: [suse-security] Oddball log entry...
by Scott McEachern 18 Aug '99

18 Aug '99

Moonshi Mohsenruddin wrote: > Do an ipchains listing. That should show you _IF_ you might have errors in > your rules. I checked the ipchains with -L, listing all rules. I can't see anything wrong there, and there are no errors. The packet seems to error out when hitting eth1 (outside world NIC), not while going thru the firewall. Addendum to my previous list: I received another bogus packet error a few minutes after sending my original mail, so I analyzed the times between these packets. In the first two series, a second packet was sent 4 minutes after the first, but not the third series. From the first packet of one series to the first packet of the next series resulted in time differences of roughly (h:m) 1:21 2:15 2:31 2:33. (The last packet, after my post, came in at 21:37.) With this, I figured the next packet might come in anywhere from 23:52 to 00:10. It's now 01:06, and nothing. In short, I can't find any particular pattern. I can't relate it to bandwidth use, as today is the first I've seen the packets, but over the weekend I surfed steadily and received none. Damn. I just wondered if they coincided with when I sent emails, so I checked my sent mail times. No correlation at all. Think Alan Cox would get mad if I asked him what they meant? He could probably read that stuff like English.... ;-) > > > -----Original Message----- > > From: scottm(a)smtp11.bellglobal.com > > [mailto:scottm@smtp11.bellglobal.com]On Behalf Of Scott McEachern > > Sent: Wednesday, August 18, 1999 10:31 AM > > To: suse-security(a)suse.com > > Subject: [suse-security] Oddball log entry... > > > > > > Hey folks! Two days ago I set up a firewall box (SuSE 6.1, 2.2.10, > > ipchains, masquerading) connected to my offline intranet. I have > > another NIC in this box using a DHCP-supplied IP addy from my provider. > > This second NIC is to a semi=permanent xDSL connection. > > I have IP_ALWAYS_DEFRAG enabled in the kernel, along with all the > > masquerading stuff, firewall stuff, etc. > > I do not run inetd, and all my ports are blocked except those > > required for HTTP and DHCPClient. I do not run X. Basically, the box > > is pretty tight. I can only get into the firewall via SSH from my LAN. > > I do not route any outside service requests into the intranet. There > > are no accounts on the firewall other than the root account. It is used > > for nothing more than a firewall/masquerade box. > > Attached are the relevant entries from my /var/log/messages > > regarding "bogus packet size." Eth1 is my connection to the net, from > > which the packets are coming. Eth0 (not listed) is my NIC to my > > intranet. > > Has anyone seen this kind of thing before?!? I'm wondering if this > > is some type of attack on the masquerading defragment bug. > > Note the receipt times of the packets. Almost all of them are from > > around 14:20 and 16:33. > > I've never seen anything like this. Is this an attack or natural > > phenomenon? I have had the same DHCP assigned public IP address for a > > couple days now (both xDSL modem and firewall online), so someone port > > scanning should be able to find me. > > Also, I found nothing else out of the ordinary in the logs. Just my > > cron jobs and every 30 minutes the DHCP stuff. > > Suggestions?!? > > > > -- > > mailto:scott.mceachern@sympatico.ca > > > > On the side of the software box, in the "System requirements section", > > it said "Requires Windows 95 or better." So I installed Linux. > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.0.2i > > iQA/AwUBN7nFUGefe0TVuy5lEQImmQCeLGdUAIl10WuMHM35+c6Lqk9sXCUAn0NP > 3r71a/UjzCGReWkx6c1s3lKR > =QkC2 > -----END PGP SIGNATURE----- -- mailto:scott.mceachern@sympatico.ca On the side of the software box, in the "System requirements section", it said "Requires Windows 95 or better." So I installed Linux.

1 0

Oddball log entry...
by Scott McEachern 18 Aug '99

18 Aug '99

Hey folks! Two days ago I set up a firewall box (SuSE 6.1, 2.2.10, ipchains, masquerading) connected to my offline intranet. I have another NIC in this box using a DHCP-supplied IP addy from my provider. This second NIC is to a semi=permanent xDSL connection. I have IP_ALWAYS_DEFRAG enabled in the kernel, along with all the masquerading stuff, firewall stuff, etc. I do not run inetd, and all my ports are blocked except those required for HTTP and DHCPClient. I do not run X. Basically, the box is pretty tight. I can only get into the firewall via SSH from my LAN. I do not route any outside service requests into the intranet. There are no accounts on the firewall other than the root account. It is used for nothing more than a firewall/masquerade box. Attached are the relevant entries from my /var/log/messages regarding "bogus packet size." Eth1 is my connection to the net, from which the packets are coming. Eth0 (not listed) is my NIC to my intranet. Has anyone seen this kind of thing before?!? I'm wondering if this is some type of attack on the masquerading defragment bug. Note the receipt times of the packets. Almost all of them are from around 14:20 and 16:33. I've never seen anything like this. Is this an attack or natural phenomenon? I have had the same DHCP assigned public IP address for a couple days now (both xDSL modem and firewall online), so someone port scanning should be able to find me. Also, I found nothing else out of the ordinary in the logs. Just my cron jobs and every 30 minutes the DHCP stuff. Suggestions?!? -- mailto:scott.mceachern@sympatico.ca On the side of the software box, in the "System requirements section", it said "Requires Windows 95 or better." So I installed Linux. Aug 17 12:57:06 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x7a. Aug 17 14:18:09 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x55. Aug 17 14:18:09 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x56. Aug 17 14:18:11 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x57. Aug 17 14:18:15 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x58. Aug 17 14:22:50 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x60. Aug 17 14:55:33 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x68. Aug 17 16:33:09 firewall kernel: eth1: bogus packet size: 7, status=0x21 nxpg=0x4d. Aug 17 16:33:09 firewall kernel: eth1: bogus packet size: 7, status=0x21 nxpg=0x4e. Aug 17 16:33:09 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x4f. Aug 17 16:33:09 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x50. Aug 17 16:33:09 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x51. Aug 17 16:33:09 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x52. Aug 17 16:33:14 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x53. Aug 17 16:33:19 firewall kernel: eth1: bogus packet size: 7, status=0x21 nxpg=0x54. Aug 17 16:33:20 firewall kernel: eth1: bogus packet size: 7, status=0x21 nxpg=0x55. Aug 17 16:33:20 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x56. Aug 17 16:33:20 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x57. Aug 17 16:33:20 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x58. Aug 17 16:33:21 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x59. Aug 17 16:33:21 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x5a. Aug 17 16:33:25 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x5b. Aug 17 16:37:54 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x76. Aug 17 16:37:55 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x77. Aug 17 19:04:24 firewall kernel: eth1: bogus packet size: 6, status=0x1 nxpg=0x4f. Aug 17 19:04:25 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x50. Aug 17 19:04:25 firewall kernel: eth1: bogus packet size: 7, status=0x1 nxpg=0x51. Aug 17 19:04:26 firewall kernel: eth1: bogus packet size: 6, status=0x21 nxpg=0x52. Aug 17 19:04:31 firewall kernel: eth1: bogus packet size: 7, status=0x21 nxpg=0x53. Aug 17 19:04:32 firewall kernel: eth1: bogus packet size: 7, status=0x21 nxpg=0x54. Aug 17 19:04:43 firewall kernel: eth1: bogus packet size: 7, status=0x21 nxpg=0x55.

2 4

Skript Kiddies
by Mark Lutz 18 Aug '99

18 Aug '99

Wau Holland mentioned Lance Spitzner's articel "Know Your Enemy - The attack of the Script Kiddie" in <news:de.comp.security> Message-ID: <slrn7rj8sj.3ui.wau(a)minos.trend.jena.thur.de> Spitzner's papers are well worth reading and can be found at <http://www.enteract.com/~lspitz/enemy.html>. They are up-to-date and provide links to exploits, log demons, recovery sites, you name it. One article also describes how he is being root compromised. Here a short description: "This article, the first of a three part series, does just that, it discusses the tools and methodology used by one of the most common and universal threats, the Script Kiddie. The second paper focuses on how you can detect these attempts, identify what tools they are using and what vulnerabilities they are looking for. The third paper focuses on what happens once they gain root. Specifically, how they cover their tracks and what they do next." I admit the information is not SuSE Linux specific but will be interesting reading for most of us. -- Mark Lutz Accept German and English

1 0

Fwd: DOS against SuSE's identd
by Chrissy LeMaire 17 Aug '99

17 Aug '99

This was forwarded to me by a friend.. i dont know if it was ever addressed on this list.. but here yall go. ----- From: Hendrik Scholz <hendrik(a)SCHOLZ.NET> Subject: DOS against SuSE's identd X-To: bugtraq(a)securityfocus.com To: BUGTRAQ(a)SECURITYFOCUS.COM Hi! The inetd.conf starts the identd with the options -w -t120 -e. This means that one identd process waits 120 seconds after answering the first request to answer later request. Lets say we start 100 requests in a short period. Due to the fact that it takes time to answer one request more identd's will be started each eating up about 900kb memory and waiting 120 seconds before terminating. I tested this behaviour on different machines with different hardware (RAM, Swap, NIC). Each machine becomes unusable after some seconds. This bug is in _every_ SuSE Version at least since 4.4. SuSE seems not to be interested in this bug becaus they did not answer any of my mails. CU, Hendrik ----- End forwarded message -----

7 7

RE: [suse-security] Fwd: DOS against SuSE's identd
by Shinton, Daniel J. 17 Aug '99

17 Aug '99

>> SuSE seems not to be interested in this bug becaus they did not >> answer any of my mails. > >Now THIS is a HUGE security problem. SuSE what's going on? This is NOT a huge security problem. There are several identd packages out there and some of those are susceptible to DoS attacks as well. You can either change the timeout, switch to a more secure identd, or just don't use identd at all. I'm sure SuSE will address this issue in future releases. Also, we shouldn't jump to conclusions about SuSE not answering his email, the post on Bugtraq seems to have an anti-SuSE tone to it. -Dan

3 2

NFS Security question
by F. Steiner 17 Aug '99

17 Aug '99

Hi, we just considered the following problem: Assume that a file system (let's say home directories of users) is exported from a server to some other computers (like in every university for instance). Now one comes with his laptop to the university, plugs one computer off, gives his laptop the ip of the unplugged computer and creates a user on his laptop that exists in the university domain with the identical name and id. Now the file system is exported to his laptop, too, because it has an ip from a university computer, and then the faker should be able to read and write the home directory of the user which he created, because NFS does not check the passwords but only the user id. We tried that and it did work. This is indeed a huge problem, because it looks like we cannot prevent any student from doing this, i.e. installing a user for instance with name and id of a professor, and then having access to the professors home directory. Has anyone any idea how to prevent this??? Can NFS be told to check passwords during mounting? For example, rlogin would not work in the situation constructed above because it would realize the user having two different passwords. But can NFS be told to do that? Thx for any help! Best, Frank -- Frank Steiner mailto:steiner@informatik.rwth-aachen.de http://www-i2.informatik.rwth-aachen.de/steiner/

10 9