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:
(* 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.
Pingback: New multilib glibc packages. - security fix from Alien.
Updated multilib glibc ackages for Slackware64 13.1 are available now.
Packages for Slackware64 13.0 are compiling at the moment.
Updated multilib glibc packages for Slackware64 13.0 are available now as well. Everyone should be safe in a multilib environment again 😉
Thanks Eric for keeping even current up to date with multilib 🙂
Are the packages in http://connie.slackware.com/~alien/multilib/13.1/slackware64-compat32/ also updated? They are all dated in May 2010.
I will not update those compat32 packages. They are created from the original 32-bit Slackware packages, and using convertpkg-compat32 you can easily create any package you need out of the published patches for Slackware 13.1.
once you seem to have a good communication with the Slack community, maybe you could report them that there is a bug on libboost 1.4.2 with gcc 4.5.1:
Once I updated it to libboost 1.4.4, using the original SlackBuild script, it just worked perfectly.
Thanks for the updated packages, again.
Those of you who use VirtualBox will find that it won’t start as a normal user – this is due to a compiled in rpath of $ORIGIN, which the patched glibc prevents. I *think* the vbox folks have update the current .run file if you’re using the binary builds, but I don’t know about the -ose version yet. If nothing else, you can take the approach that I used and fix the rpath using the chrpath utility: http://connie.slackware.com/~rworkman/chrpath/
Note that you’re limited to seven characters for the new rpath, so “/opt/VirtualBox” isn’t an option – I chose to do this:
for i in /opt/VirtualBox/*.so ; do
chrpath -r “/VBOX” $i ;
mount –bind /opt/VirtualBox /VBOX
Maybe I am missing something, but over here it appears that glibc* are blacklisted by convertpkg-compat32:-
# convertpkg-compat32 -i glibc-2.11.1-i486-4_slack13.1.txz -d compat32/
Package glibc is blacklisted by ‘glibc.*’, aborting.
Probing in convertpkg-compat32:-
# Blacklist of packages not to use this script on (these *have* to be compiled
# on a 64bit box):
Please disregard my previous post.
I figured it out.
I just verified there is a new .run for VirtualBox (66896) that fixes the issues. Thanks for the heads up 🙂
Multilib repository is now mirrored on Asian’s Server:
i’ve got the same problem chris was having earlier, cannot convert glibc and others due to blacklist
And why do you think the glibc and gcc packages are on that blacklist? (Hint: what packages did you also upgrade that are not called “compat32”?)
Warning: there is yet another update to glibc. Slackware packages became available yesterday, my multilib versions are available as of now (see my more recent blog post).