Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
On Mon, Sep 05, 2005 at 12:59:05AM +0200, Zoran Dzelajlija wrote: debian/patches/902_glibc-2.3.5-pt_pax-1.dpatch This adds some ELF-flags to elf.h. debian/patches/903_glibc-2.3.5-dl_execstack_PaX-2.dpatch This effectively removes any sanity check for executable stack. Bastian -- Spock: We suffered 23 casualties in that attack, Captain. signature.asc Description: Digital signature
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
Quoting GOTO Masanori ([EMAIL PROTECTED]): How did you fix your package? These patches for PaX were applied: debian/patches/902_glibc-2.3.5-pt_pax-1.dpatch debian/patches/903_glibc-2.3.5-dl_execstack_PaX-2.dpatch available in the diff at http://debian.linux-systeme.com/dists/unstable/main/source/glibc_2.3.5-7.diff.gz The second patch seems relevant, but I don't know if it would break Exec-shield (which, as I understand it, PT_GNU_STACK was added to support) or anything else. I'll try rebuilding glibc with just that and see if it helps. For complete PaX support, including the PT_PAX_FLAGS ELF header, it seems a binutils patch is also needed. Regards, Zoran -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
At Wed, 17 Aug 2005 03:06:12 +0200, Zoran Dzelajlija wrote: Well, for one thing, upgrading libc6 triggers the breakage on unrelated, already installed packages - and there's a lot of those linked to eg. libssl-0.9.7.so. BTW. looks like there are some patches which mitigate this issue, see eg. the libc6 build in this third-party repository: deb http://debian.linux-systeme.com unstable main (I haven't taken a good look at the diff, but the changelog says * Add PaX support. How did you fix your package? It seems reasonable to include some global workaround until all these broken library packages get fixed, since the breakage appears to have wide effects on the affected systems. Since there is a workaround in glibc available, maybe it's better to leave a copy of the bug here, perhaps for you to examine the patch and see if it would be a good idea to apply it? I think it's decided by the trade-off between workaround and the correct fix. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
Quoting GOTO Masanori ([EMAIL PROTECTED]): At Thu, 24 Mar 2005 10:38:20 -0500, Daniel Jacobowitz wrote: Is there someone else that is more concerned with fixing problems than being an asshole that I can talk to about this problem? If you aren't interested in being civil, I'm certainly not interested in helping you. You haven't given a convincing reason for glibc to change, only for the applications to be fixed. Have you filed bugs on the affected libraries? I also wonder why this bug is submitted into glibc package. Well, for one thing, upgrading libc6 triggers the breakage on unrelated, already installed packages - and there's a lot of those linked to eg. libssl-0.9.7.so. BTW. looks like there are some patches which mitigate this issue, see eg. the libc6 build in this third-party repository: deb http://debian.linux-systeme.com unstable main (I haven't taken a good look at the diff, but the changelog says * Add PaX support. which is what I need. ;-) If it's not glibc bug, this report does not make any sense - because maintainers of such problematic library merely read this list. If you don't think it's glibc bug, could you reassign it to the appropriate packages? If you don't know how to reassign bugs, please let me know. It seems reasonable to include some global workaround until all these broken library packages get fixed, since the breakage appears to have wide effects on the affected systems. Since there is a workaround in glibc available, maybe it's better to leave a copy of the bug here, perhaps for you to examine the patch and see if it would be a good idea to apply it? Apart from that, your suggestion is to (duplicate and) reassign to libacl1, libssl0.9.7 etc? I know things are expected to break in unstable, however I'm puzzled that this issue is still opened after 5 months. Regards, Zoran -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
Please reply to the bug, not directly to me. I don't see the point of working around the PaX check in glibc. The libraries aren't real likely to work if they really require executable stacks. File bugs on them, not on glibc. What do you propose be done then until all the apps in this list (and more) are fixed: https://www.redhat.com/archives/fedora-devel-list/2005-March/msg00459.html I don't know how Debian handles large issues like this, but this is something every package maintainer needs to be aware of quickly. If Debian doesn't act soon, they'll be releasing many advisories of this type: http://www.linuxcompatible.org/story41890.html and be getting many complaints from PaX users because their system is now unusable. -Brad signature.asc Description: Digital signature
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
On Thu, Mar 24, 2005 at 08:04:14AM -0500, Brad Spengler wrote: Please reply to the bug, not directly to me. I don't see the point of working around the PaX check in glibc. The libraries aren't real likely to work if they really require executable stacks. File bugs on them, not on glibc. What do you propose be done then until all the apps in this list (and more) are fixed: https://www.redhat.com/archives/fedora-devel-list/2005-March/msg00459.html That's not much of a list; I'm not overly concerned. I don't know how Debian handles large issues like this, but this is something every package maintainer needs to be aware of quickly. If Debian doesn't act soon, they'll be releasing many advisories of this type: http://www.linuxcompatible.org/story41890.html and be getting many complaints from PaX users because their system is now unusable. Guess what? Debian does not support PaX. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
https://www.redhat.com/archives/fedora-devel-list/2005-March/msg00459.html That's not much of a list; I'm not overly concerned. I don't know how Debian handles large issues like this, but this is something every package maintainer needs to be aware of quickly. If Debian doesn't act soon, they'll be releasing many advisories of this type: http://www.linuxcompatible.org/story41890.html and be getting many complaints from PaX users because their system is now unusable. Guess what? Debian does not support PaX. Guess what? It does. It also supports exec-shield. chpax - user-space utility to control PaX flags gradm - Administration program for the GrSecurity ACL system gradm2 - Administration program for the grsecurity2 RBAC based ACL system kernel-patch-2.4-grsecurity - grsecurity kernel patch - 2.4.x security patch kernel-patch-grsecurity2 - grsecurity kernel patch - new major upstream version paxctl - user-space utility to control PaX flags - new major upstream version paxtest - Test suite for the PaX kernel patch kernel-patch-adamantix - Kernel patches introduced in Adamantix kernel-patch-exec-shield - Protection against stack smashing and other attacks. Is there someone else that is more concerned with fixing problems than being an asshole that I can talk to about this problem? -Brad signature.asc Description: Digital signature
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
On Thu, Mar 24, 2005 at 09:44:26AM -0500, Brad Spengler wrote: https://www.redhat.com/archives/fedora-devel-list/2005-March/msg00459.html That's not much of a list; I'm not overly concerned. I don't know how Debian handles large issues like this, but this is something every package maintainer needs to be aware of quickly. If Debian doesn't act soon, they'll be releasing many advisories of this type: http://www.linuxcompatible.org/story41890.html and be getting many complaints from PaX users because their system is now unusable. Guess what? Debian does not support PaX. Debian includes PaX, which is not necessarily the same thing. Is there someone else that is more concerned with fixing problems than being an asshole that I can talk to about this problem? If you aren't interested in being civil, I'm certainly not interested in helping you. You haven't given a convincing reason for glibc to change, only for the applications to be fixed. Have you filed bugs on the affected libraries? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
At Thu, 24 Mar 2005 10:38:20 -0500, Daniel Jacobowitz wrote: Is there someone else that is more concerned with fixing problems than being an asshole that I can talk to about this problem? If you aren't interested in being civil, I'm certainly not interested in helping you. You haven't given a convincing reason for glibc to change, only for the applications to be fixed. Have you filed bugs on the affected libraries? I also wonder why this bug is submitted into glibc package. If it's not glibc bug, this report does not make any sense - because maintainers of such problematic library merely read this list. If you don't think it's glibc bug, could you reassign it to the appropriate packages? If you don't know how to reassign bugs, please let me know. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
Package: libc6 Version: 2.3.4-1 Severity: important libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1, making them request an executable stack when none is needed. This severely breaks a PaX system and effectively backdoors most applications on systems using exec-shield. Here's the relevant readelf -e output for libacl. It would be wise for debian to check all packages for these same kinds of problems now to avoid causing lots of problems later when glibc 2.3.4 goes into unstable. Since this problem causes security features to be silently disabled in the case of exec-shield, it is a security issue in addition to a large usability problem in the case of PaX. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSizFlg Align LOAD 0x00 0x 0x 0x051b6 0x051b6 R E 0x1000 LOAD 0x0051b8 0x61b8 0x61b8 0x001dc 0x001fc RW 0x1000 DYNAMIC0x0051cc 0x61cc 0x61cc 0x000e0 0x000e0 RW 0x4 STACK 0x00 0x 0x 0x0 0x0 RWE 0x4 -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11.5-grsec Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
On Wed, Mar 23, 2005 at 06:10:44PM -0500, Brad Spengler wrote: Package: libc6 Version: 2.3.4-1 Severity: important libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1, making them request an executable stack when none is needed. This severely breaks a PaX system and effectively backdoors most applications on systems using exec-shield. Here's the relevant readelf -e output for libacl. It would be wise for debian to check all packages for these same kinds of problems now to avoid causing lots of problems later when glibc 2.3.4 goes into unstable. Since this problem causes security features to be silently disabled in the case of exec-shield, it is a security issue in addition to a large usability problem in the case of PaX. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSizFlg Align LOAD 0x00 0x 0x 0x051b6 0x051b6 R E 0x1000 LOAD 0x0051b8 0x61b8 0x61b8 0x001dc 0x001fc RW 0x1000 DYNAMIC0x0051cc 0x61cc 0x61cc 0x000e0 0x000e0 RW 0x4 STACK 0x00 0x 0x 0x0 0x0 RWE 0x4 Why is this a bug in glibc 2.3.4? Why is it even related to glibc 2.3.4? Those libraries are not part of glibc. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
