Monthly Archives: October 2010

Another glibc multilib update

Posted on by

Barely a week has passed, and we have yet another local root hole in glibc that needed patching. The Slackware ChangeLog said it like this:

a/glibc-solibs-2.12.1-x86_64-3.txz: Rebuilt.
Patched “The GNU C library dynamic linker will dlopen arbitrary DSOs
during setuid loads.” This security issue allows a local attacker to
gain root by specifying an unsafe DSO in the library search path to be
used with a setuid binary in LD_AUDIT mode.
Bug found by Tavis Ormandy (with thanks to Ben Hawkes and Julien Tinnes).
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3856
http://seclists.org/fulldisclosure/2010/Oct/344
(* Security fix *)

Of course, I was out of town for a few days when this happened, so it took a little longer to build updated multilib versions for glibc.

But… they are available now for your 64-bit Slackware 13.0, 13.1 and -current. Grab them here: http://slackware.com/~alien/multilib/. If you need guidance, read the README or better even, check out the Wiki page on Slackware multilib.

I hope this is the last hole for a while, it sucks having to rebuild all of this.

Mirrors: http://taper.alienbase.nl/mirrors/people/alien/multilib/ and http://slackware.org.uk/people/alien/multilib/.

Eric

New multilib glibc packages fix local root hole

Posted on by

New glibc packages for Slackware arrived on the mirrors last night. They close a serious local root hole. From the ChangeLog:

Patched “dynamic linker expands $ORIGIN in setuid library search path”.
This security issue allows a local attacker to gain root if they can create
a hard link to a setuid root binary.  Thanks to Tavis Ormandy.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3847
http://seclists.org/fulldisclosure/2010/Oct/257
(* Security fix *)

I have already created new multilib versions of the updated glibc packages for Slackware64-current, get them here: http://slackware.com/~alien/multilib/current/ or mirrored here: http://taper.alienbase.nl/mirrors/people/alien/multilib/current/ and here: http://slackware.org.uk/people/alien/multilib/current/.

When I return from work, I will also create I have also created updates to my multilib glibc packages for Slackware64 13.0 and 13.1. Stay posted, I will write a note in the comments section of this article.

Eric

Slackware gcc multilib packages rebuilt

Posted on by

Pat Volkerding rebuilt the gcc 4.5.1 packages for Slackware-current, adding support for LTO (Link Time Optimization). Apparently that feature was requested a lot.

Consequently I have rebuilt my multilib versions of the gcc-4.5.1 packages for Slackware64-current; get them at http://slackware.com/~alien/multilib/current/ (mirror site: http://taper.alienbase.nl/mirrors/people/alien/multilib/current/).

Eric

Compositing hard lock in KDE 4.5

Posted on by

People have written about their computer locking up with KDE 4.5.x in Slackware.

These locks seem to be caused by the open source video drivers that are part of X.Org. These drivers incorrectly advertise some OpenGL capabilities when the KDE compositing manager queries them. As a result, the KDE window manager tries to enable non-working functionality in “3d desktop effects” which results in a hard lock of X.Org.

There was some talk about this when I first released KDE 4.5.1 packages, see the comments section of http://alien.slackbook.org/blog/kde-4-5-1-i-took-the-plunge/ and some developer talk can be found here: http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma-in-kde-workspaces-4-5/

Today I installed Slackware-current on an “old” ThinkPad T41 with an onboard Radeon RV250 (Mobility FireGL 9000) graphics chip. I experienced the hard lock there for the first time.

This is what I did to get KDE running (after forcedly shutting down the machine by pressing the OFF button for 8 seconds…): edit the KDE Window Manager configuration file:

~/.kde/share/config/kwinrc

In that file, look up the section called “[Compositing]” and then add these lines (perhaps in your case you have to modify, not add lines):

DisableChecks=true
Enabled=false

That first line disables the functionality checks so that if you enable “3d effects” manually you have a good chance of it actually going to work because KDE is not going to query your graphics drivers and just assumes it’ll work. As a result you will see an error about not being able to use the “blur effect” which is exactly where the query would result in incorrect data – the error message is not fatal though.

The second line disables the “3d effects” entirely, allowing KDE to start properly.

Eric

New multilib packages for 64-bit Slackware-current

Posted on by

As you may have noticed already, there are interesting updates in the Slackware ChangeLog.txt !

A new kernel, and new glibc plus gcc packages means there has to be an updated set of multilib packages too or else you bunch of hybrid lovers would be left out in the cold.

Well actually there is an update to my multilib packages too! . The http://slackware.com/~alien/multilib/current/ is a new directory with goodies for your consumption.

For installation/upgrade instructions see the multilib README or even better, read my Wiki article at http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib (which has not yet been updated with package versions for slackware64-current, but that will change soon).

In the slackware64-compat32 subdirectory I added the set of packages which have been generated by the massconvert32.sh script, i.e. that directory contains all the support libraries you need (along with my gcc/glibc and compat32-tools packages) to turn your Slackware64-current into a multilib system.

Good luck! Eric

PS:

Fast mirror at http://taper.alienbase.nl/mirrors/people/alien/multilib/current/

Rsync access offered through rsync://taper.alienbase.nl/mirrors/people/alien/multilib/current/