Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
Thanks for the many replies. Just for the record, I thought I'd type out what I had to go through to get everything to work: 1) At first, didn't realize I needed to uncomment the word prompt in lilo.conf (though I figured this one out before posting to the group). 2) The reason I received the error about being unable to mount root FS was because I didn't realize the following line was missing from the vmlinux.old stanza in lilo.conf: initrd=/initrd.img.old. I added this line to lilo, ran lilo at the prompt, rebooted, and was able to boot off of the original 2.4.18. So, now that I was back connected to the internet, I was able to use apt-get to get the new 2.4.18-1 package. Thank you again! I appreciate it. djr Peter Cordes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, Apr 15, 2004 at 09:33:32PM +0200, David R wrote: Yes, any ideas how to fix this? I'm a newbie, so a bit new to Linux. When I installed this 2.4.18 package, it blew up my network card, so I am unable to get the new, fixed package. I thought about using apt-get remove to get rid of the patched kernel, but somehow this seemed ungood to me, so I tried booting from LinuxOLD, which points to the original (as far as I can tell) vmlinuz-2.4.18-686. However, when I try this, I get the following error: Kernel Panic: VFS: Unable to mount root FS on 03:01 I'm guessing that the wrong initrd is getting loaded for the kernel that's booting. Check your /boot/grub/menu.lst (or /etc/lilo.conf), and the symlinks in /boot for initrd-old.img (or whatever it's called). What do I do? Do I use apt-get remove to get rid of the patched kernel? Do I do something else? Probably better to get a working kernel booted before you remove anything. If you have any kernel .debs that used to work, you could try installing one with dpkg -i. This might end up downgrading a kernel package you have installed, but just removing things won't help. (Debian's package scripts usually leave the /boot symlinks broken when I remove a kernel package, even if it was totally obsolete and the links weren't pointing to any files from that package...) Your best bet is to look at the symlinks yourself, and get them pointing to the right place. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.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 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
On Wed, Apr 14, 2004 at 05:20:49PM +0200, Martin Schulze wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 481-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze April 14th, 2004http://www.debian.org/security/faq - -- Package: kernel-image-2.4.17-ia64 Vulnerability : several vulnerabilities Problem-Type : local Debian-specific: no CVE ID : CAN-2004-0003 CAN-2004-0010 CAN-2004-0109 CAN-2004-0177 CAN-2004-0178 Several serious problems have been discovered in the Linux kernel. This update takes care of Linux 2.4.17 for the IA-64 architecture. The Common Vulnerabilities and Exposures project identifies the following problems that will be fixed with this update: CAN-2004-0003 A vulnerability has been discovered in the R128 drive in the Linux kernel which could potentially lead an attacker to gain unauthorised privileges. Alan Cox and Thomas Biege developed a correction for this CAN-2004-0010 Arjan van de Ven discovered a stack-based buffer overflow in the ncp_lookup function for ncpfs in the Linux kernel, which could lead an attacker to gain unauthorised privileges. Petr Vandrovec developed a correction for this. CAN-2004-0109 zen-parse discovered a buffer overflow vulnerability in the ISO9660 filesystem component of Linux kernel which could be abused by an attacker to gain unauthorised root access. Sebastian Krahmer and Ernie Petrides developed a correction for this. CAN-2004-0177 Solar Designer discovered an information leak in the ext3 code of Linux. In a worst case an attacker could read sensitive data such as cryptographic keys which would otherwise never hit disk media. Theodore Ts'o developed a correction for this. CAN-2004-0178 Andreas Kies discovered a denial of service condition in the Sound Blaster driver in Linux. He also developed a correction for this. These problems will also be fixed by upstream in Linux 2.4.26 and future versions of 2.6. For the stable distribution (woody) these problems have been fixed in version 011226.17 for Linux 2.4.17. For the unstable distribution (sid) these problems have been fixed in version 2.4.25-5 for Linux 2.4.25 and in version 2.6.5-1 for Linux 2.6.5. We recommend that you upgrade your kernel packages immediately, either with a Debian provided kernel or with a self compiled one. Upgrade Instructions - 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 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-ia64_011226.17.dsc Size/MD5 checksum: 736 2f8bdbd5d82c972dee55ae3eb3051ebf http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-ia64_011226.17.tar.gz Size/MD5 checksum: 25407685 a4f251ad4275ee197e3f5b3aa76c45c9 Architecture independent components: http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-source-2.4.17-ia64_011226.17_all.deb Size/MD5 checksum: 24730726 c6133857bb4423ecec496517f212da70 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-headers-2.4.17-ia64_011226.17_ia64.deb Size/MD5 checksum: 3635930 ee77880f4ae85e0850115788e0bc18e6 http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-itanium_011226.17_ia64.deb Size/MD5 checksum: 7020714 942615101e2eb34833f53fa6eb7713d2 http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-itanium-smp_011226.17_ia64.deb Size/MD5 checksum: 7169180 04d65a0c0eae8b01488383ada809a936 http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-mckinley_011226.17_ia64.deb Size/MD5 checksum: 7011536 5388a3be55dfe67c54355d6974f26400 http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-mckinley-smp_011226.17_ia64.deb Size/MD5 checksum: 7161438 7fca8b5dbaf833e15810acde2ad678de These files will probably be moved into the stable distribution on its next
Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 16 April 2004 08.20, David R wrote: 1) At first, didn't realize I needed to uncomment the word prompt in lilo.conf (though I figured this one out before posting to the group). You can just hold down the shift or control key when booting, this gets you the lilo prompt in any case (I always have prompt disabled, no need to delay the boot in the normal case, and on a desktop booting is a frequent enough occasion to make it worth the effort) - -- vbi - -- The content of this message may or may not reflect the opinion of me, my employer, my girlfriend, my cat or anybody else, regardless of the fact whether such an employer, girlfriend, cat, or anybody else exists. I (or my employer, girlfriend, cat or whoever) disclaim any legal obligations resulting from the above message. You, as the reader of this message, may or may not have the permission to redistribute this message as a whole or in parts, verbatim or in modified form, or to distribute any message at all. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAkB/jYlgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6WVYAn3Cn69vQpDLFfFZyrqRpq6La 5OJJAJwKtXk3jTpHUcwd81IPhJJzSLU8nQ== =34lV -END PGP SIGNATURE-
apache segmentation fault
Hello all, there seems to be a new apache vulnerability. Following error messages occure many times in my error.log: ... [Fri Apr 16 13:16:33 2004] [error] [client 212.118.85.143] request failed: URI too long [Fri Apr 16 13:52:39 2004] [notice] child pid 31788 exit signal Segmentation fault (11) ... Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2 mod_ssl/2.8.9 OpenSSL/0.9.6g mod_jk/1.1.0 System is woody with all security updates applied. Any hints or tips how to track down the attack? Regards, Robert -- Robert Velter [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apache segmentation fault
Robert Velter a dit : Hello all, there seems to be a new apache vulnerability. Following error messages occure many times in my error.log: [...] System is woody with all security updates applied. Any hints or tips how to track down the attack? A good start might be : LogLevel debug in your httpd.conf Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug #243954: DoS on Linux kernel 2.4 and 2.6 using sigqueue overflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I am bringing this issue before you for discussion and guidance. There is a security issue described in the mentioned bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243954 Please review the bug and contribute if you have any suggestions. If you contribute please be sure to CC the Bug report. At question here is where should this bug be directed? The kernel pseudo package or glibc (linuxthreads). Credits: Thanks to Matt Zimmerman and Herbert Xu for contributing already. Thanks, - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAgB5lS3Jybf3L5MQRAl1RAJ4yEiGhMo6n6k4AcwgoS3Uuo/UD/gCeJRcC Ema8ICrUs2l1uLQtfgrxJjk= =dOC/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug #243954: DoS on Linux kernel 2.4 and 2.6 using sigqueue overflow
For convenience, below is the original issue as it was posted on
BugTraq...
Bugtraq Post
From: Nikita V. Youshchenko [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Possible DoS on Linux kernel 2.4 and 2.6 using sigqueue
overflow.
Date: Mon, 12 Apr 2004 06:06:04 -0400
User-Agent: KMail/1.5.4
Hello.
We faced a bug (?) in Linux kernel causing different misbehaviours on
our
server. After exploration, it seems that we found some security
implications of this issue.
When a process exits, it's parent is notified by SIGCHLD, and finished
child is kept in process table in zombie state until parent process
(or
init, if parent is already ended) handles child exit.
Similary, with linuxthreads, when a thread exits, another thread in the
same process is notified by signal 33 (SIGRT_1), and exitted thread
exists
in the process table in zombie state until the exit is handled.
When a signal that notifies about exit is generated by the kernel,
kernel
code allocates a struct sigqueue object. This object keeps information
about the signal until the signal is delivered.
Only a limited number of such objects may be allocated at a time.
There is some code in the kernel that still allows signals with numbers
less than 32 to be delivered when struct sigqueue object can't be
allocated. However, for signal 33 signal generation routine just returns
-EAGAIN in this case.
As the result, process is not notified about thread exits, and ended
thread
is left in zombie state.
Details are at
http://www.ussg.iu.edu/hypermail/linux/kernel/0404.0/0208.html
For long-living processes that create short-living threads (such as
mysqld), this causes process table overflow in several minutes.
struct sigqueue overflow may be easily caused from userspace, if a
process blocks a signal and then receives a large number of such
signals.
The following sample code does that:
#include signal.h
#include unistd.h
#include stdlib.h
int main()
{
sigset_t set;
int i;
pid_t pid;
sigemptyset(set);
sigaddset(set, 40);
sigprocmask(SIG_BLOCK, set, 0);
pid = getpid();
for (i = 0; i 1024; i++)
kill(pid, 40);
while (1)
sleep(1);
}
So if a user runs such code (or just runs a buggy program that blocks a
signal and then receives 1000 such signals - which happens here), this
will cause a DoS againt anything running on the same system that uses
linuxthreads, including daemons running as root.
On systems that use NPTL (such as Linux 2.6 kernel) there is no 'thread
zombie' problem, because in NPTL another notification mechanism is used.
However, DoS is still possible (and really happens - in form of daemon
crashes), because when it is not possible to allocatre a struct
sigqueue
object, kernel behaviour in signal-passing changes, causing random hangs
and segfaults in different programs.
/Bugtraq Post
--
Phillip Hofmeister
PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import
suid
Hello! Everybody knows that files with a suid bit set can be dangerous. Well, i was asking myself today why exactly linux uses the suid bit files?! Could someone please explain that to me? Example: ~$ ls -lah /var/spool/cron/crontabs/user -rw---1 root user 408 Apr 16 Ok, the suid is set for the crontab binary because you have to edit the root owned file. But why is it owned by root in the first place? Cheers, Mario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: suid
On Fri, Apr 16, 2004 at 11:02:56PM +0100, Mario Ohnewald wrote: Everybody knows that files with a suid bit set can be dangerous. Everybody knows that almost everything is dangerous. Well, i was asking myself today why exactly linux uses the suid bit files?! Could someone please explain that to me? It's fairly simple, a file is setuid so that the user that invokes the binary can gain the permissions of the binaries owner. This is necessary in a lot of common cases. For example to change a password a user (typically) must update the entry in the file /etc/shadow, problem is that users cannot view or edit this file themselves. This means that the passwd program must be setuid(root) or setgid(shadow) to modify it on the users behalf, after carefully sanitizing the inputs. Example: ~$ ls -lah /var/spool/cron/crontabs/user -rw---1 root user 408 Apr 16 Ok, the suid is set for the crontab binary because you have to edit the root owned file. But why is it owned by root in the first place? So that other users may not view it, in much the same way as the /etc/shadow example I presented above. Besides there aren't *too* many setuid/setgid files included in Debian, sure less would be great, but it's not the case that there are hundreds. Please see the following URL for a partially accurate listing and compare it against the other operating systems listed: http://shellcode.org/Setuid/debian.html (I have pending lists to updload covering HPUX, Tru64 and NetBSD). Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: suid
Hello, Everybody knows that files with a suid bit set can be dangerous. yes :) sgids too :) Well, i was asking myself today why exactly linux uses the suid bit files?! because binaries are executed with almost the same rights as the user-owner-of-file [effective UID] Could someone please explain that to me? Example: ~$ ls -lah /var/spool/cron/crontabs/user -rw---1 root user 408 Apr 16 where are you have any suid ? I dont see any. Ok, the suid is set for the crontab binary because you have to edit the root owned file. # ls -l `which crontab ` -rwsr-xr-x1 root root22460 Oct 1 2001 /usr/bin/crontab yes, because only in this condition normal user can set crontab rules. man: /usr/bin/crontab crontab needs to be suid root to edit crontab files in /usr/spool/cron/crontabs and to signal() cron. If you disable suid for crontab binary this will be like that: $ crontab -l seteuid: Operation not permitted I am thinking about changing directory from /var/spool to another but ... signals. I don't know. Maybe sombody know ? Everybody are agree with me ? But why is it owned by root in the first place? I dont know, maybe root-owned [setuided] binary crontab set it ? And why ? because - when - user will be able to write to this file - he will be able to write to partition where /var/spool/cron/crontabs/ is mounted. -- Pozdrawiam, Marcin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: suid
In article [EMAIL PROTECTED] you wrote: -rwsr-xr-x1 root root22460 Oct 1 2001 /usr/bin/crontab yes, because only in this condition normal user can set crontab rules. this deends on the cron used. The cron in qustion needs to restrict the access to the spool directory because it is shared. One could change the owner of the crontab file, but then it is hard to atomically replace the file without write access to the spool dir. The best solution is to have the crontab in a user owned directory. It is not a good idea to change this without having a close look at the cron code in question. It might be much better to use another cron flavor. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
apache - not upgrading correctly ...
Hello, apache 1.3.26 after last upgrades I have lots of: # lsof | grep DEL apache-ss 28184root memDEL0,4 229382 /SYSV ... It is normal ? I dont think so... but how to solve this problem ? I am not exactly understand what is going on with DEL flag. Could anybody tell me ? man lsof: TYPE is the type of the node associated with the file - e.g., GDIR, GREG, VDIR, VREG, etc. ... ``DEL'' for a Linux map file that has been deleted; but what that is mean for security ? Program have loaded library to its memory, after that this file [library] has been modified ? So apache is still buggy ? BTW: FD is the File Descriptor number of the file or: mem memory-mapped file; so: process copied this file into memory ? But why when I restart whole apache the same message is present ? -- Greetings, and thanks for any help, Marcin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BF kernels
On 15/04/04 22:19, Joshua Goodall wrote: On Thu, 15 Apr 2004 07:56 pm, Tim Nicholas wrote: If I recall correctly it is assumed that users will not run on the boot floppy kernels after the initial system installation. They are expected to install a more appropriate kernel after finishing the install. As such there will be no patch for the boot floppy kernel. I disagree with the generalisation. Let me tell you two little tales. 1. A few weeks ago I was building a new cluster of our servers. We [snip] The specifics of DSA479 notwithstanding; either of these would motivate me to agree with Michelle that bootfloppies should be updated, too. I couldn't agree more. -- Tim Nicholas || Cilix Email: [EMAIL PROTECTED]||Wellington, New Zealand http://tim.nicholas.net.nz/ || Cell/SMS: +64 21 337 204
Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
Thanks for the many replies. Just for the record, I thought I'd type out what I had to go through to get everything to work: 1) At first, didn't realize I needed to uncomment the word prompt in lilo.conf (though I figured this one out before posting to the group). 2) The reason I received the error about being unable to mount root FS was because I didn't realize the following line was missing from the vmlinux.old stanza in lilo.conf: initrd=/initrd.img.old. I added this line to lilo, ran lilo at the prompt, rebooted, and was able to boot off of the original 2.4.18. So, now that I was back connected to the internet, I was able to use apt-get to get the new 2.4.18-1 package. Thank you again! I appreciate it. djr Peter Cordes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, Apr 15, 2004 at 09:33:32PM +0200, David R wrote: Yes, any ideas how to fix this? I'm a newbie, so a bit new to Linux. When I installed this 2.4.18 package, it blew up my network card, so I am unable to get the new, fixed package. I thought about using apt-get remove to get rid of the patched kernel, but somehow this seemed ungood to me, so I tried booting from LinuxOLD, which points to the original (as far as I can tell) vmlinuz-2.4.18-686. However, when I try this, I get the following error: Kernel Panic: VFS: Unable to mount root FS on 03:01 I'm guessing that the wrong initrd is getting loaded for the kernel that's booting. Check your /boot/grub/menu.lst (or /etc/lilo.conf), and the symlinks in /boot for initrd-old.img (or whatever it's called). What do I do? Do I use apt-get remove to get rid of the patched kernel? Do I do something else? Probably better to get a working kernel booted before you remove anything. If you have any kernel .debs that used to work, you could try installing one with dpkg -i. This might end up downgrading a kernel package you have installed, but just removing things won't help. (Debian's package scripts usually leave the /boot symlinks broken when I remove a kernel package, even if it was totally obsolete and the links weren't pointing to any files from that package...) Your best bet is to look at the symlinks yourself, and get them pointing to the right place. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.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 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
On Wed, Apr 14, 2004 at 05:20:49PM +0200, Martin Schulze wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 481-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze April 14th, 2004http://www.debian.org/security/faq - -- Package: kernel-image-2.4.17-ia64 Vulnerability : several vulnerabilities Problem-Type : local Debian-specific: no CVE ID : CAN-2004-0003 CAN-2004-0010 CAN-2004-0109 CAN-2004-0177 CAN-2004-0178 Several serious problems have been discovered in the Linux kernel. This update takes care of Linux 2.4.17 for the IA-64 architecture. The Common Vulnerabilities and Exposures project identifies the following problems that will be fixed with this update: CAN-2004-0003 A vulnerability has been discovered in the R128 drive in the Linux kernel which could potentially lead an attacker to gain unauthorised privileges. Alan Cox and Thomas Biege developed a correction for this CAN-2004-0010 Arjan van de Ven discovered a stack-based buffer overflow in the ncp_lookup function for ncpfs in the Linux kernel, which could lead an attacker to gain unauthorised privileges. Petr Vandrovec developed a correction for this. CAN-2004-0109 zen-parse discovered a buffer overflow vulnerability in the ISO9660 filesystem component of Linux kernel which could be abused by an attacker to gain unauthorised root access. Sebastian Krahmer and Ernie Petrides developed a correction for this. CAN-2004-0177 Solar Designer discovered an information leak in the ext3 code of Linux. In a worst case an attacker could read sensitive data such as cryptographic keys which would otherwise never hit disk media. Theodore Ts'o developed a correction for this. CAN-2004-0178 Andreas Kies discovered a denial of service condition in the Sound Blaster driver in Linux. He also developed a correction for this. These problems will also be fixed by upstream in Linux 2.4.26 and future versions of 2.6. For the stable distribution (woody) these problems have been fixed in version 011226.17 for Linux 2.4.17. For the unstable distribution (sid) these problems have been fixed in version 2.4.25-5 for Linux 2.4.25 and in version 2.6.5-1 for Linux 2.6.5. We recommend that you upgrade your kernel packages immediately, either with a Debian provided kernel or with a self compiled one. Upgrade Instructions - 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 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-ia64_011226.17.dsc Size/MD5 checksum: 736 2f8bdbd5d82c972dee55ae3eb3051ebf http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-ia64_011226.17.tar.gz Size/MD5 checksum: 25407685 a4f251ad4275ee197e3f5b3aa76c45c9 Architecture independent components: http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-source-2.4.17-ia64_011226.17_all.deb Size/MD5 checksum: 24730726 c6133857bb4423ecec496517f212da70 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-headers-2.4.17-ia64_011226.17_ia64.deb Size/MD5 checksum: 3635930 ee77880f4ae85e0850115788e0bc18e6 http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-itanium_011226.17_ia64.deb Size/MD5 checksum: 7020714 942615101e2eb34833f53fa6eb7713d2 http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-itanium-smp_011226.17_ia64.deb Size/MD5 checksum: 7169180 04d65a0c0eae8b01488383ada809a936 http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-mckinley_011226.17_ia64.deb Size/MD5 checksum: 7011536 5388a3be55dfe67c54355d6974f26400 http://security.debian.org/pool/updates/main/k/kernel-image-2.4.17-ia64/kernel-image-2.4.17-mckinley-smp_011226.17_ia64.deb Size/MD5 checksum: 7161438 7fca8b5dbaf833e15810acde2ad678de These files will probably be moved into the stable distribution on its next
Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 16 April 2004 08.20, David R wrote: 1) At first, didn't realize I needed to uncomment the word prompt in lilo.conf (though I figured this one out before posting to the group). You can just hold down the shift or control key when booting, this gets you the lilo prompt in any case (I always have prompt disabled, no need to delay the boot in the normal case, and on a desktop booting is a frequent enough occasion to make it worth the effort) - -- vbi - -- The content of this message may or may not reflect the opinion of me, my employer, my girlfriend, my cat or anybody else, regardless of the fact whether such an employer, girlfriend, cat, or anybody else exists. I (or my employer, girlfriend, cat or whoever) disclaim any legal obligations resulting from the above message. You, as the reader of this message, may or may not have the permission to redistribute this message as a whole or in parts, verbatim or in modified form, or to distribute any message at all. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAkB/jYlgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6WVYAn3Cn69vQpDLFfFZyrqRpq6La 5OJJAJwKtXk3jTpHUcwd81IPhJJzSLU8nQ== =34lV -END PGP SIGNATURE-
apache segmentation fault
Hello all, there seems to be a new apache vulnerability. Following error messages occure many times in my error.log: ... [Fri Apr 16 13:16:33 2004] [error] [client 212.118.85.143] request failed: URI too long [Fri Apr 16 13:52:39 2004] [notice] child pid 31788 exit signal Segmentation fault (11) ... Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2 mod_ssl/2.8.9 OpenSSL/0.9.6g mod_jk/1.1.0 System is woody with all security updates applied. Any hints or tips how to track down the attack? Regards, Robert -- Robert Velter [EMAIL PROTECTED]
Re: apache segmentation fault
Robert Velter a dit : Hello all, there seems to be a new apache vulnerability. Following error messages occure many times in my error.log: [...] System is woody with all security updates applied. Any hints or tips how to track down the attack? A good start might be : LogLevel debug in your httpd.conf Vincent
Bug #243954: DoS on Linux kernel 2.4 and 2.6 using sigqueue overflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I am bringing this issue before you for discussion and guidance. There is a security issue described in the mentioned bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243954 Please review the bug and contribute if you have any suggestions. If you contribute please be sure to CC the Bug report. At question here is where should this bug be directed? The kernel pseudo package or glibc (linuxthreads). Credits: Thanks to Matt Zimmerman and Herbert Xu for contributing already. Thanks, - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAgB5lS3Jybf3L5MQRAl1RAJ4yEiGhMo6n6k4AcwgoS3Uuo/UD/gCeJRcC Ema8ICrUs2l1uLQtfgrxJjk= =dOC/ -END PGP SIGNATURE-
Re: Bug #243954: DoS on Linux kernel 2.4 and 2.6 using sigqueue overflow
For convenience, below is the original issue as it was posted on
BugTraq...
Bugtraq Post
From: Nikita V. Youshchenko [EMAIL PROTECTED]
To: bugtraq@securityfocus.com
Subject: Possible DoS on Linux kernel 2.4 and 2.6 using sigqueue
overflow.
Date: Mon, 12 Apr 2004 06:06:04 -0400
User-Agent: KMail/1.5.4
Hello.
We faced a bug (?) in Linux kernel causing different misbehaviours on
our
server. After exploration, it seems that we found some security
implications of this issue.
When a process exits, it's parent is notified by SIGCHLD, and finished
child is kept in process table in zombie state until parent process
(or
init, if parent is already ended) handles child exit.
Similary, with linuxthreads, when a thread exits, another thread in the
same process is notified by signal 33 (SIGRT_1), and exitted thread
exists
in the process table in zombie state until the exit is handled.
When a signal that notifies about exit is generated by the kernel,
kernel
code allocates a struct sigqueue object. This object keeps information
about the signal until the signal is delivered.
Only a limited number of such objects may be allocated at a time.
There is some code in the kernel that still allows signals with numbers
less than 32 to be delivered when struct sigqueue object can't be
allocated. However, for signal 33 signal generation routine just returns
-EAGAIN in this case.
As the result, process is not notified about thread exits, and ended
thread
is left in zombie state.
Details are at
http://www.ussg.iu.edu/hypermail/linux/kernel/0404.0/0208.html
For long-living processes that create short-living threads (such as
mysqld), this causes process table overflow in several minutes.
struct sigqueue overflow may be easily caused from userspace, if a
process blocks a signal and then receives a large number of such
signals.
The following sample code does that:
#include signal.h
#include unistd.h
#include stdlib.h
int main()
{
sigset_t set;
int i;
pid_t pid;
sigemptyset(set);
sigaddset(set, 40);
sigprocmask(SIG_BLOCK, set, 0);
pid = getpid();
for (i = 0; i 1024; i++)
kill(pid, 40);
while (1)
sleep(1);
}
So if a user runs such code (or just runs a buggy program that blocks a
signal and then receives 1000 such signals - which happens here), this
will cause a DoS againt anything running on the same system that uses
linuxthreads, including daemons running as root.
On systems that use NPTL (such as Linux 2.6 kernel) there is no 'thread
zombie' problem, because in NPTL another notification mechanism is used.
However, DoS is still possible (and really happens - in form of daemon
crashes), because when it is not possible to allocatre a struct
sigqueue
object, kernel behaviour in signal-passing changes, causing random hangs
and segfaults in different programs.
/Bugtraq Post
--
Phillip Hofmeister
PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import
suid
Hello! Everybody knows that files with a suid bit set can be dangerous. Well, i was asking myself today why exactly linux uses the suid bit files?! Could someone please explain that to me? Example: ~$ ls -lah /var/spool/cron/crontabs/user -rw---1 root user 408 Apr 16 Ok, the suid is set for the crontab binary because you have to edit the root owned file. But why is it owned by root in the first place? Cheers, Mario
Re: suid
On Fri, Apr 16, 2004 at 11:02:56PM +0100, Mario Ohnewald wrote: Everybody knows that files with a suid bit set can be dangerous. Everybody knows that almost everything is dangerous. Well, i was asking myself today why exactly linux uses the suid bit files?! Could someone please explain that to me? It's fairly simple, a file is setuid so that the user that invokes the binary can gain the permissions of the binaries owner. This is necessary in a lot of common cases. For example to change a password a user (typically) must update the entry in the file /etc/shadow, problem is that users cannot view or edit this file themselves. This means that the passwd program must be setuid(root) or setgid(shadow) to modify it on the users behalf, after carefully sanitizing the inputs. Example: ~$ ls -lah /var/spool/cron/crontabs/user -rw---1 root user 408 Apr 16 Ok, the suid is set for the crontab binary because you have to edit the root owned file. But why is it owned by root in the first place? So that other users may not view it, in much the same way as the /etc/shadow example I presented above. Besides there aren't *too* many setuid/setgid files included in Debian, sure less would be great, but it's not the case that there are hundreds. Please see the following URL for a partially accurate listing and compare it against the other operating systems listed: http://shellcode.org/Setuid/debian.html (I have pending lists to updload covering HPUX, Tru64 and NetBSD). Steve --
Re: suid
Hello, Everybody knows that files with a suid bit set can be dangerous. yes :) sgids too :) Well, i was asking myself today why exactly linux uses the suid bit files?! because binaries are executed with almost the same rights as the user-owner-of-file [effective UID] Could someone please explain that to me? Example: ~$ ls -lah /var/spool/cron/crontabs/user -rw---1 root user 408 Apr 16 where are you have any suid ? I dont see any. Ok, the suid is set for the crontab binary because you have to edit the root owned file. # ls -l `which crontab ` -rwsr-xr-x1 root root22460 Oct 1 2001 /usr/bin/crontab yes, because only in this condition normal user can set crontab rules. man: /usr/bin/crontab crontab needs to be suid root to edit crontab files in /usr/spool/cron/crontabs and to signal() cron. If you disable suid for crontab binary this will be like that: $ crontab -l seteuid: Operation not permitted I am thinking about changing directory from /var/spool to another but ... signals. I don't know. Maybe sombody know ? Everybody are agree with me ? But why is it owned by root in the first place? I dont know, maybe root-owned [setuided] binary crontab set it ? And why ? because - when - user will be able to write to this file - he will be able to write to partition where /var/spool/cron/crontabs/ is mounted. -- Pozdrawiam, Marcin.
Re: suid
In article [EMAIL PROTECTED] you wrote: -rwsr-xr-x1 root root22460 Oct 1 2001 /usr/bin/crontab yes, because only in this condition normal user can set crontab rules. this deends on the cron used. The cron in qustion needs to restrict the access to the spool directory because it is shared. One could change the owner of the crontab file, but then it is hard to atomically replace the file without write access to the spool dir. The best solution is to have the crontab in a user owned directory. It is not a good idea to change this without having a close look at the cron code in question. It might be much better to use another cron flavor. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/
