[SECURITY] [DSA 159-1] New Python packages fix insecure temporary file use
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 159-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze August 28th, 2002 http://www.debian.org/security/faq - -- Package: python Vulnerability : insecure temporary files Problem-Type : local Debian-specific: no Zack Weinberg discovered an insecure use of a temporary file in os._execvpe from os.py. It uses a predictable name which could lead execution of arbitrary code. This problem has been fixed in several versions of Python: For the current stable distribution (woody) it has been fixed in version 1.5.2-23.1 of Python 1.5, in version 2.1.3-3.1 of Python 2.1 and in version 2.2.1-4.1 of Python 2.2. For the old stable distribution (potato) this has been fixed in version 1.5.2-10potato12 for Python 1.5. For the unstable distribution (sid) this has been fixed in version 1.5.2-24 of Python 1.5, in version 2.1.3-6a of Python 2.1 and in version 2.2.1-8 of Python 2.2. Python 2.3 is not affected by this problem. We recommend that you upgrade your Python packages immediately. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Source archives: http://security.debian.org/pool/updates/main/p/python/python_1.5.2-10potato12.dsc Size/MD5 checksum: 814 d4368a244ae130c0a879dc583d74ebb6 http://security.debian.org/pool/updates/main/p/python/python_1.5.2-10potato12.diff.gz Size/MD5 checksum:85380 cef4ee264c041385d26a6e7a914f66cf http://security.debian.org/pool/updates/main/p/python/python_1.5.2.orig.tar.gz Size/MD5 checksum: 2533053 e9d677ae6d5a3efc6937627ed8a3e752 Alpha architecture: http://security.debian.org/pool/updates/main/p/python/python-base_1.5.2-10potato12_alpha.deb Size/MD5 checksum: 928612 9cbc6a1fc341c7f5668da7f14ddfd336 ARM architecture: http://security.debian.org/pool/updates/main/p/python/python-base_1.5.2-10potato12_arm.deb Size/MD5 checksum: 848442 778e22c98169028d94ba9fe3634dd113 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/p/python/python-base_1.5.2-10potato12_i386.deb Size/MD5 checksum: 825052 a2b34f89248287e5f61e1a9ae051b6ae Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/p/python/python-base_1.5.2-10potato12_m68k.deb Size/MD5 checksum: 837528 55065573b7ed3b5f19ced5bb35cc PowerPC architecture: http://security.debian.org/pool/updates/main/p/python/python-base_1.5.2-10potato12_powerpc.deb Size/MD5 checksum: 872370 6e45dfbc1694e89f4707e1803f65943a Sun Sparc architecture: http://security.debian.org/pool/updates/main/p/python/python-base_1.5.2-10potato12_sparc.deb Size/MD5 checksum: 854034 3ef80fbe6213c198d713046a4405cdff Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/p/python1.5/python1.5_1.5.2-23.1.dsc Size/MD5 checksum: 916 59cda94465a7108d34294050e141b0ba http://security.debian.org/pool/updates/main/p/python1.5/python1.5_1.5.2-23.1.diff.gz Size/MD5 checksum: 147550 0246bc4b24874e3c0f8b6c6af47b262d http://security.debian.org/pool/updates/main/p/python1.5/python1.5_1.5.2.orig.tar.gz Size/MD5 checksum: 2533570 d9ade0d7613466e0353561d277ff02fe http://security.debian.org/pool/updates/main/p/python2.1/python2.1_2.1.3-3.1.dsc Size/MD5 checksum: 1283 2193a191f73cac617edc851ce1dc0874 http://security.debian.org/pool/updates/main/p/python2.1/python2.1_2.1.3-3.1.diff.gz Size/MD5 checksum:70192 eacc3d64dd0717ecf47fb2793a6b94c2 http://security.debian.org/pool/updates/main/p/python2.1/python2.1_2.1.3.orig.tar.gz Size/MD5 checksum: 6194246 1ae739aa5824de263923df3516eeaf80 http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.1.dsc Size/MD5 checksum: 1150 029ee1aa079f8884283d57d765889d37 http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.1.diff.gz Size/MD5 checksum:91682 de92eb806eea24f0a00289a9179cce7a http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1.orig.tar.gz Size/MD5 checksum: 6536167 88aa07574673ccfaf35904253c78fc7d Alpha architecture:
Re: cryptoloop confusion
Jeff wrote: I've decided to learn how to setup an encrypted filesystem using the cryptoloop method and I'm having troubles getting my kernal source patched correctly. I've read the Loopback Encrypted Filesystem HOWTO, but it's outdated. Here are a number of patches for kernel 2.4.18 and I'm confused as to which one(s) to use. Could you try my cryptoapi packages? They're waiting to be accepted into unstable, so you can't get to them directly, but i uploaded them to my private repository as well: http://home.o2w.net/~ivo/debian/ I'm very curious to hear if these packages have the same problem. BTW, kernel-patch-int is deprecated, you should be using cryptoapi, so you should install the 'cryptoapi-core-source' and 'cryptoloop-source' packages from my site. Ivo -- tarzeau the internet is so big, and full of nothing i want
RE: cryptoloop confusion
It seems to me, you need not only the patch-int , but also the loop patch, which can be found at ftp://ftp.kernel.org/pub/linux/crypto/v2.4/testing/loop-hvr-2.4.18.0.patch You have to use it else the cryptoloop compile part fails. Why the loop patch is not included in the patch-int patch, I do not know. Vincent -Original Message- From: Jeff [mailto:[EMAIL PROTECTED] Sent: Wednesday 28 August 2002 00:38 To: debian security list Subject: cryptoloop confusion I've decided to learn how to setup an encrypted filesystem using the cryptoloop method and I'm having troubles getting my kernal source patched correctly. I've read the Loopback Encrypted Filesystem HOWTO, but it's outdated. Here are a number of patches for kernel 2.4.18 and I'm confused as to which one(s) to use. I've patched using patch-int-2.4.18.2.bz2 successfully, but my compile fails at the cryptoloop part. I've tried using the make patch-kernel ... to patch with cryptoloop-0.0.1-pre1.tar.gz and cryptoapi-0.1.0-rc1.tar.gz, both of which failed: root # cd /usr/src/cryptoloop-0.0.1-pre1 root # make patch-kernel KDIR=/usr/src/linux-2.4.18_crypt LOOP=iv cp -pf /usr/src/linux-2.4.18_crypt/Rules.make . rm -f arch/ ln -s /usr/src/linux-2.4.18_crypt/arch . rm -f include/ ln -s /usr/src/linux-2.4.18_crypt/include . make -f Makefile.modules KDIR=/usr/src/linux-2.4.18_crypt version make[1]: Entering directory `/usr/src/cryptoloop-0.0.1-pre1' make[1]: Leaving directory `/usr/src/cryptoloop-0.0.1-pre1' cd patches ./findpatch.pl /usr/src/linux-2.4.18_crypt iv patching file linux-2.4.16/drivers/block/loop.c patching file linux-2.4.16/include/linux/loop.h cp: cannot stat `/usr/src/linux-2.4.18_crypt/crypto/drivers/Config.in': No such file or directory /bin/sh: /usr/src/linux-2.4.18_crypt/crypto/drivers/Config.in: No such file or directory `cryptoloop.c' - `/usr/src/linux-2.4.18_crypt/crypto/drivers' cp: accessing `/usr/src/linux-2.4.18_crypt/crypto/drivers/Makefile': Not a directory make: *** [patch-kernel] Error 1 and... root # cd /usr/src/cryptoapi-0.1.0-rc1 root # make patch-kernel KDIR=/usr/src/linux-2.4.18_crypt LOOP=iv cp -pf /usr/src/linux-2.4.18_crypt/Rules.make . rm -f arch/ ln -s /usr/src/linux-2.4.18_crypt/arch . rm -f include/ ln -s /usr/src/linux-2.4.18_crypt/include . make -f Makefile.modules KDIR=/usr/src/linux-2.4.18_crypt version make[1]: Entering directory `/usr/src/cryptoapi-0.1.0-rc1' make[1]: Leaving directory `/usr/src/cryptoapi-0.1.0-rc1' touch check.stamp cp -R kernel/crypto /usr/src/linux-2.4.18_crypt cp: cannot overwrite non-directory `/usr/src/linux-2.4.18_crypt/crypto/drivers' with directory `kernel/crypto/drivers' make: *** [patch-kernel] Error 1 I'm googling and looking at all the docs in the patches, but I'm not finding clear answers yet. If someone can shed some light on which patch(es) I need and the order I need to apply them, and any other important pieces I'd really appreciate it. thanks, jc -- Jeff Coppock Systems Engineer Diggin' DebianAdmin and User -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mail relay attempts
Hi Dale. Dale Amon wrote: The only thing you can do is to make damn certain your box does not become part of the problem. I'll add to that: make sure you actually check your logs. I use syslog-ng to bring all essential realtime logging to a hardened server; I'll add another one to that: I started using syslogd-sql, which is a modified version of the syslog 1.4.1 that also allows logging to a MySQL database. I hope it is a step in the right direction to use advances SQL queries in order to support analyzation of logfiles. Any opinions on that from the more experiences ones on this list? :) Bye, Mike
Re: Mail relay attempts
Hi. Jones, Steven wrote: Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. As an addition to that idea: would it be possible to cause similar effects to HTTP-server worms with a modified tarpit? Maybe a modified version of the kernel httpd: whenever a worm attack drops in the response will be a normal website containing a bogus content (no 404), coming over the line character by character with a huge delay. Comments? Bye, Mike
Re: debian-security-announce-$lang@lists?
I think as a German I'm allowed to say this: No English, no security. There will always be bits and pieces available in English only. Making DSAs available in foreign languages will help amateurs without sufficient English skills to keep their systems up to date. It might even help professionals, because although I have no problem with understanding english (and even german if required) reading a email in the Dutch language is less strenuous. For professionals, required reading is debian-security (or whatever foo-security list applies to their system), BUGTRAQ, maybe full-disclosure if you can stand it ;-), and some other mailing lists. Agreed, although it's a lot of emails a day if you are on all 3 mailinglists. Ivo van Dongen [EMAIL PROTECTED]:~$ apt-cache show clue Package: clue Priority: optional
Re: [SECURITY] [DSA 159-1] New Python packages fix insecure temporary file use
Hi, after an apt-get update on my potato box, the following happens: wurm:~# apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages have been kept back python-base python-tk 0 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded. wurm:~# Why are the new python packages kept back? Ciao Siegbert
Re: [SECURITY] [DSA 159-1] New Python packages fix insecure temporary file use
Hi Matt, Ah, I missed the part where you said this was a potato system. It looks like you are installing woody security updates on a potato system. You probably have a line like this: deb http://security.debian.org/ stable/updates main in /etc/apt/sources.list. Since Debian 3.0 (woody) is now 'stable', you are getting the wrong security updates. You can either upgrade to woody (recommended), or change this line to read: deb http://security.debian.org/ potato/updates main so that you will receive updates for potato when they are available. You're right, that line pointed to stable instead of potato. Thanks a lot for your help and time. :-) Ciao Siegbert
unsubscribe
thx
Re: Mail relay attempts
On Wed, Aug 28, 2002 at 11:56:24AM +0200, Michael Renzmann wrote: Hi. Jones, Steven wrote: Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. As an addition to that idea: would it be possible to cause similar effects to HTTP-server worms with a modified tarpit? Maybe a modified version of the kernel httpd: whenever a worm attack drops in the response will be a normal website containing a bogus content (no 404), coming over the line character by character with a huge delay. Comments? I remember hearing about people doing exactly that. Maybe it was mentioned on /. or the local LUG mailing list (http://nslug.ns.ca/). -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
Permissions Required On hosts.allow ?
[hope this isn't too lame a question for this list] I decided to start locking down permissions on sensitive files on a recently installed Woody box, and discovered that when I changed the permissions on hosts.allow (and hosts.deny) to 640 then I could no longer Telnet into the box from the permitted IP address (never mind denied addresses). /var/log/daemon.log had messages in it to the effect that tcpd couldn't read hosts.allow, so was denying the connection. So I've opened perms up to 644 again, but this seems the wrong thing to do. I realise I was only gaining a minor layer of security-thru-obscurity, but every little helps - surely we don't want this file to be world-readable ? I note from inetd.conf that in.telnetd runs as uid.gid telnetd.telnetd, whereas hosts.allow has uid.gid root.root, which I guess is the cause of this. Can I change this around a bit to achieve my goal - maybe make a new group called foo (say) and give that gid to in.telnetd and hosts.allow ... ? [ BTW: I *do* use SSH for all network access - I only have 127.0.0.1 listed for in.telnetd in hosts.allow, to allow myself to telnet 0 - sometimes I like to start a new session like that, and ssh takes so much longer to start up a session ... ] TIA, Nick Boyce Bristol, UK -- The universe is entering maintenance mode in 2 minutes. Please logout. -- Your administrator
Re: Permissions Required On hosts.allow ?
Nick, I found that SSHd was being unreasonably slow in authorising logins.. Found the problem to be that SSH was doing DNS lookups on IP's. So I setup an internal reverse DNS for my local lan, and shebang, it's almost instant now. Jason - Original Message - From: Nick Boyce To: debian-security@lists.debian.org Sent: Thursday, August 29, 2002 11:51 AM Subject: Permissions Required On hosts.allow ? [hope this isn't too lame a question for this list] I decided to start locking down permissions on sensitive files on a recently installed Woody box, and discovered that when I changed the permissions on hosts.allow (and hosts.deny) to 640 then I could no longer Telnet into the box from the permitted IP address (never mind denied addresses). /var/log/daemon.log had messages in it to the effect that tcpd couldn't read hosts.allow, so was denying the connection. So I've opened perms up to 644 again, but this seems the wrong thing to do. I realise I was only gaining a minor layer of security-thru-obscurity, but every little helps - surely we don't want this file to be world-readable ? I note from inetd.conf that in.telnetd runs as uid.gid telnetd.telnetd, whereas hosts.allow has uid.gid root.root, which I guess is the cause of this. Can I change this around a bit to achieve my goal - maybe make a new group called foo (say) and give that gid to in.telnetd and hosts.allow ... ? [ BTW: I *do* use SSH for all network access - I only have 127.0.0.1 listed for in.telnetd in hosts.allow, to allow myself to telnet 0 - sometimes I like to start a new session like that, and ssh takes so much longer to start up a session ... ] TIA, Nick Boyce Bristol, UK -- The universe is entering maintenance mode in 2 minutes. Please logout. -- Your administrator
Re: Permissions Required On hosts.allow ?
On Thu, 29 Aug 2002, Jason Clarke wrote:
# Found the problem to be that SSH was doing DNS lookups on IP's.
#
# So I setup an internal reverse DNS for my local lan, and shebang, it's
# almost instant now.
use -u0 on the sshd option
Cheers,
Indra Kusuma
--
,''`. Indra{@,.}Kusuma.OR.ID - [personal - Debian/GNU Linux - IPv6]
: :' : 0x4D829E49 - 187D 8C98 FB76 E1A8 5558 853A 4795 4FC1 4D82 9E49
`. `'
`-
