Debian users: don't upgrade to glibc 2.3.4, take action

[spender]

Upgrading to glibc 2.3.4 on a Debian system will make your system nearly unusable. Due to RedHat's fundamentally flawed PT_GNU_STACK implementation, many packages have their libraries marked as needing executable stacks, when such executable stacks are not needed. I've filed bug reports with Debian, but they are not taking the issue seriously. Here's one of their replies:

> 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.


I urge everyone to contact Debian and make them take this issue seriously, otherwise your systems will soon become unusable.

-Brad

[Pesky Taco]

Lack of Pax support must be a misunderstanding.
The reason I suggest this is here are supported packages in Sarge (testing)
http://packages.debian.org/testing/admin/paxctl
http://packages.debian.org/testing/devel/paxtest

I did not find your archived bug in the following url,
http://bugs.debian.org/cgi-bin/pkgrepor ... rchive=yes
So I must trust you most likley stated "pax" when to Debian the package is
named, kernel-patch-grsecurity2.

Perhaps if you try again with the new information, they will be more helpful.
Or ask for the following maintainer "Javier Fernández-Sanguino Peña" he has been great to work with.

I would like to see this issue resolved also. As I am very intersted in applying grsecurity to my Debain Kernel.

[Pesky Taco]

WTF is mikeeusa's reply have to do with grsecurity?
If you has going to act like an asshole, at least post in the "I am an asshole" thread.

[Pesky Taco]

A good Slashdotting does seem to grab attention and realign thinking.

[Pesky Taco]

>Have the deb people contacted you back?

When I submitted problems with PAM .conf flies they did contacted me
and asked me to confirm the problems were fixed with the latest update. Hence the name I submitted previously was a Debian maintainer who I know would not just blow off security issues. I submitted the name so spender could have a direct Debian contact. Since spender has first hand knowledge of the problem and I am only reading the second hand his version of the story, I figured spender should resubmit the information. Then what ever reply he get's should be posted here. This way if it is submitted to /. then at least it has been well documented. If it is not documented well, you will have a bunch of posts that state "nothing to see here, move along". A good faith effort produces a better /.ing.

[ringwraith]

This same problem exists in slackware 10.1. I was quite amazed after I had patched the kernel, rebooted, and come to find out that the more command refuses to work. There was mentioning somewhere (i think in the redhat lists, i cannot find it now??) there is a utility to disable this? Would there be any possible way to make a work around in grsec to allow this flawed implementation to work, hopefully giving it some extra security in the process? I know thats bloat, but it could be a nice grsecurity module.

[Pesky Taco]

[/quote]Was the problem fixed?[/quote]
Yes

[nerdpunk]

libc6-2.3.5 has arrived unstable some days ago... still broken...
but there's a deb-repository with a fixed glibc and other fixed packages...
deb http://debian.linux-systeme.com unstable main
(it's from the maintainer of the 2.2 kernel series, i guess

[rs]

Please, could somebody tell us here when an official Debian fixed libc6 is available? Anybody following the issue at Debian tracker?

Thanks in advance.

[Hue-Bond]

I'm running fine with libc6-2.3.5. You can too, *but* only after chpax'ing -m all binaries . Or sticking an "M" in the subject flags for all subjects, which is about the same. Just a quick workaround while I think about switching distros...

[msw]

i use libc6 2.3.5 now, i didnt notice any problems... the system behaves as before... i activated nearly all of the PAX features.

[Melt_Down]

Is the issue fixed now in the official debian (testing) glibc package?

[kirk22]

the problem was fixed in debian's glibc 2.3.5-4, look:

http://packages.qa.debian.org/g/glibc/news/3.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321718

On Monday 08 August 2005 16:52, Daniel Jacobowitz wrote:

> > I'd suggest to rebuild all required packages (libraries) with
> > CFLAGS -Wa,--noexecstack so that assembled modules get tagged
> > as not needing executable stacks.
> >
> > I've rebuilt some packages (liblzo1, openssl, libgdbm3, libelfg0,
> > libgcrypt11 and so on) with those flags. For everyone who's
> > interested: http://debian.linux-systeme.com/
>
> Absolutely not. Either the package needs an executable stack - in
> which case this is, simply, wrong - or else it doesn't and whatever is
> causing it to be tagged as needing one should be fixed. IIRC it is
> usually a matter of annotating assembly files in some way.

well, so I've uploaded a glibc 2.3.5 package with PaX support.

ciao, Marc

[PaX Team]

the problem was fixed in debian's glibc 2.3.5-4, look:

http://packages.qa.debian.org/g/glibc/news/3.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321718

no it wasn't, that's another problem that Red Hat's careless GNU_STACK implementation caused. Marc fixed the PaX related problem in his own packages, it is not in debian officially, and judging from the discussion, it won't be.

[kirk22]

no it wasn't, that's another problem that Red Hat's careless GNU_STACK implementation caused. Marc fixed the PaX related problem in his own packages, it is not in debian officially, and judging from the discussion, it won't be.

sorry for claiming that it was fixed - i didn't follow the discussion carefully enough.

can we do anything else about it? (should we start a discussion on debian's mailinglist's? http://lists.debian.org/debian-glibc/ or http://lists.debian.org/debian-security/)

what do the glibc people think about it? (i assume this problem does not only affect debian but also everyone else using glibc 2.3.4,2.3.5,...?)