ldconfig makes system loader /lib/ld-linux.so.2 to be linked to 3rd party loaders in /lib directory

Bug #915995 reported by Venkatesh on 2012-01-13
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
eglibc (Debian)
Fix Released
Unknown
eglibc (Ubuntu)
Undecided
Unassigned

Bug Description

Package: libc-bin
Version: 2.13-0ubuntu13
Severity: Critical
Source: eglibc
Architecture: i386
System having installed with some 3rd party loaders (ld-<name>.so.x) in /lib directory. With these loaders present if we run ldconfig, its removing the system loader symbolic link ld-linux.so.2 in /lib directory from /lib/i286-linux-gnu/ld-2.13.so and creating the symbolic link to one of the 3rd party loaders(in my case link to ld-nails.so.2) present in /lib directory. As ldconfig not link to proper system loader, system gets unusable and system crashes if we reboot.
Captured the strace logs for "ldconfig".
4470 15:25:20 close(4) = 0
4470 15:25:20 stat64("/lib/libhistory.so.6", {st_mode=S_IFREG|0644, st_size=30060, ...}) = 0
4470 15:25:20 stat64("/lib/libatm.so.1", {st_mode=S_IFREG|0644, st_size=34452, ...}) = 0
4470 15:25:20 getdents64(3, /* 0 entries */, 32768) = 0
4470 15:25:20 close(3) = 0
4470 15:25:20 stat64("/lib/libcrypto.so.0.9.8", {st_mode=S_IFREG|0644, st_size=1341364, ...}) = 0
4470 15:25:20 stat64("/lib/libcrypto.so.0.9.8", {st_mode=S_IFREG|0644, st_size=1341364, ...}) = 0
4470 15:25:20 stat64("/lib/libatm.so.1", {st_mode=S_IFREG|0644, st_size=34452, ...}) = 0
4470 15:25:20 stat64("/lib/libatm.so.1.0.0", {st_mode=S_IFREG|0644, st_size=34452, ...}) = 0
4470 15:25:20 stat64("/lib/libnih-dbus.so.1", {st_mode=S_IFREG|0644, st_size=29984, ...}) = 0
4470 15:25:20 stat64("/lib/libnih-dbus.so.1.0.0", {st_mode=S_IFREG|0644, st_size=29984, ...}) = 0
4470 15:25:20 stat64("/lib/libhistory.so.6", {st_mode=S_IFREG|0644, st_size=30060, ...}) = 0
4470 15:25:20 stat64("/lib/libhistory.so.6.2", {st_mode=S_IFREG|0644, st_size=30060, ...}) = 0
4470 15:25:20 stat64("/lib/libdevmapper.so.1.02.1", {st_mode=S_IFREG|0644, st_size=137308, ...}) = 0
4470 15:25:20 stat64("/lib/libdevmapper.so.1.02.1", {st_mode=S_IFREG|0644, st_size=137308, ...}) = 0
4470 15:25:20 stat64("/lib/libproc-3.2.8.so", {st_mode=S_IFREG|0644, st_size=59108, ...}) = 0
4470 15:25:20 stat64("/lib/libproc-3.2.8.so", {st_mode=S_IFREG|0644, st_size=59108, ...}) = 0
4470 15:25:20 stat64("/lib/libfuse.so.2", {st_mode=S_IFREG|0644, st_size=158272, ...}) = 0
4470 15:25:20 stat64("/lib/libfuse.so.2.8.4", {st_mode=S_IFREG|0644, st_size=158272, ...}) = 0
4470 15:25:20 stat64("/lib/libxtables.so.5", {st_mode=S_IFREG|0644, st_size=26104, ...}) = 0
4470 15:25:20 stat64("/lib/libxtables.so.5.0.0", {st_mode=S_IFREG|0644, st_size=26104, ...}) = 0
4470 15:25:20 stat64("/lib/libssl.so.0.9.8", {st_mode=S_IFREG|0644, st_size=294696, ...}) = 0
4470 15:25:20 stat64("/lib/libssl.so.0.9.8", {st_mode=S_IFREG|0644, st_size=294696, ...}) = 0
4470 15:25:20 stat64("/lib/libipq_pic.so.0", {st_mode=S_IFREG|0644, st_size=9688, ...}) = 0
4470 15:25:20 stat64("/lib/libipq_pic.so.0.0.0", {st_mode=S_IFREG|0644, st_size=9688, ...}) = 0
4470 15:25:20 stat64("/lib/libparted.so.0", {st_mode=S_IFREG|0644, st_size=425316, ...}) = 0
4470 15:25:20 stat64("/lib/libparted.so.0.0.1", {st_mode=S_IFREG|0644, st_size=425316, ...}) = 0
4470 15:25:20 stat64("/lib/libiptc.so.0", {st_mode=S_IFREG|0644, st_size=5212, ...}) = 0
4470 15:25:20 stat64("/lib/libiptc.so.0.0.0", {st_mode=S_IFREG|0644, st_size=5212, ...}) = 0
4470 15:25:20 stat64("/lib/libiw.so.30", {st_mode=S_IFREG|0644, st_size=30120, ...}) = 0
4470 15:25:20 stat64("/lib/libiw.so.30", {st_mode=S_IFREG|0644, st_size=30120, ...}) = 0
4470 15:25:20 stat64("/lib/ld-linux.so.2", {st_mode=S_IFREG|0755, st_size=117960, ...}) = 0
4470 15:25:20 stat64("/lib/ld-nails.so.2", {st_mode=S_IFREG|0750, st_size=124720, ...}) = 0
4470 15:25:20 lstat64("/lib/ld-linux.so.2", {st_mode=S_IFLNK|0777, st_size=25, ...}) = 0
4470 15:25:20 unlink("/lib/ld-linux.so.2") = 0
4470 15:25:20 symlink("ld-nails.so.2", "/lib/ld-linux.so.2") = 0
This issue reproduce only on Ubuntu 11.04. As ldconfig is creating symbolic link causing the system unusable. Want to know why ldconfig is linking to 3rd party loaders instead of system loader ld-2.13.so and appreciate if you could provide the workaround for this issue.

Brian Murray (brian-murray) wrote :

This bug was also reported in the Debian bug tracker (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655711) and some more details were posted there:

"Yes, I am doing some test/check with different ubuntu versions and this
issue observed or encountered only on Ubuntu 11.04. Also not been seeing
this on earlier versions and recent Ubuntu 11.10.

Yes, you are right that the SONAME of our loader ld-<name>.so.2 loader is
pointing to system loader ld-linux.so.2.
The output of "readelf" is below:

root@ubuntuserver1104:~# readelf -d /lib/ld-<name>.so.2 | grep SONAME
 0x0000000e (SONAME) Library soname: [ld-linux.so.2]

Its curious to know that, why this is only happening on Ubuntu 11.04? Any
specific dependent with ldconfig? and not observed on other ubuntu
versions even though the soname encoded is same as ld-linux.so.2."

tags: added: natty
Changed in eglibc (Debian):
status: Unknown → Fix Released
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in eglibc (Ubuntu):
status: New → Confirmed

I am also experiencing this same issue, on Ubuntu 11.04. We have installed McAfee which has their own link loader, and that destabilises the entire OS. Can we get a fix for this as our systems are fragile due to this issue?
/lib/ld-linux.so.2 is linked like

/lib/ld-linux.so.2 -> i386-linux-gnu/ld-linux.so.2
 and in turn i386-linux-gnu/ld-linux.so.2 is linked as

/lib/i386-linux-gnu/ld-linux.so.2 -> ld-2.13.so

this is broken and get linked with McAfee loader whenever we install package using dpkg. Appreciate urgent solution on this !

I have same issue on Ubuntu 11.04 with McAfee. When Installing packages System get unstable

Hi Team,
 Can we get this issue resolved? I am unable to have a McAfee on Ubuntu 11.04 as it destabilises the operating system with third party loader. Tried with providing aliases to dpkg and apt-get but still unattended upgrades destabilises the OS through third party loader.

  Appreciate urgent help on this!

Cheers!
Rasika Karunathilaka.

dasith vimarshana (dasithedu) wrote :

i have encountered the same issue.
:(

Vinod Gayan Perera (vingayan) wrote :

Hi I have faced with the same isse with ubuntu 11.04 with McAfee

Adam Conrad (adconrad) wrote :

ldconfig is doing exactly what it was designed to do, which is to link SONAMEs to libraries providing that SONAME in the same directory. This is more a case of "don't do that, then" than a bug in glibc.

Since there was much asking about why this only happens in recent versions of Ubuntu, it's because the real linker (ld-2.1x.so) used to live in /lib until we moved to multiarch so, due to SHEER LUCK because of sort order, it was scanned first, and subsequent providers of the SONAME were ignored. Now that it lives in a different directory, third party linkers in /lib that provide the incorrect SONAME get picked up and symlinked. The solution here is really to not provide the same SONAME as the system linker, but a quick workaround for those affected could also be to move the offending third-party binary to the multi-arch path instead.

Changed in eglibc (Ubuntu):
status: Confirmed → Invalid
Ishan A B Ambanwela (ishanaba) wrote :

I could fix it in this way

http://ishanaba.com/blog/2013/02/how-did-i-fix-ubuntu-mcafee-issue/

may be not the best way

Duane Rezac (duane-rezac-ctr) wrote :

Here is something I have discoverd with this bug. The problem is caused by ldconfig following a symbolic link that points to a symbolic link. man ldconfig indicates that ldconfig should ignore symbolic links. We are running the McAfee Epo Ageent and LinuxShield. (we are also running the McAfee product on Redhat 5-enterprise, and this problem does not occur.)

In /lib, ld-nails.so.2 and ld-mfert.so.2 are both symboic links that point to a ld-linux.so.2 in McAfees /lib, ld-linux.so.2 in the mcafee libs are symbolic links to a mcafee lib. For Example. ld-mfert.so.2 in /lib points to /opt/McAfee/runtime/2.0/lib/ld-linux.so.2 which is a symbolic link to /opt/McAfee/runtime/2.0/lib/ld-2.5.so

Output of ldconfig -N -X -v shows that ldconfig is linking ld-linux.so.2 to /lib/ld-nails.so.2 or /llib/d-mfert.so.2.

ldconfig is following the symbolic link in /lib, and since the McAfee files contain the SONAME ld-linux.so.2, it links them to /lib
It appears that ldconfig is resolving the links, as the ld-linux.so.2 that it links in /lib fromo the MacAfee file (in this case ld-mfert.so.2) will point to /opt/McAfee/runtime/2.0/lib/ld-2.5.so

Note: once your system has been corrupted, an easy fix is to boot with a live cd, mount the root file system (for example, to /mnt/fubarroot) then use copy -P to copy /lib/ld-linux.so.2 from the live cd to your mounted root file system's /lib (copy -P /lib/ld-linux.so.2 /mnt/fubarroot/lib ) - reboot and all is well until ldconfig gets run again. The best workarount I have seen is to shut down nails and cma, remove the links, run updates, re-create the McAfee Links, restart cma and nails.

Scripts I use:

mcoff
#!/bin/sh
# keep McAfee from stepping on /lib/ld-linux.so.2
# turn off McAfee and unlink libs in /lib
/etc/init.d/nails stop
/etc/init.d/cma stop
rm /lib/ld-mfert.so.2
rm /lib/ld-nails.so.2
echo McAfee Agent and VSE Disabled

mcon
#!/bin/sh
# keep McAfee from stepping on /lib/ld-linux.so.2
# re-enable links and restart McAfee

ln -s /opt/McAfee/runtime/2.0/lib/ld-linux.so.2 /lib/ld-mfert.so.2
ln -s /opt/NAI/LinuxShield/lib/ld-linux.so.2 /lib/ld-nails.so.2
/etc/init.d/cma start
/etc/init.d/nails start
echo McAfee Agent and VSE enabled

Same issue in Ubuntu 10.04.4 (latest updates).

Some information from McAfee: https://kc.mcafee.com/corporate/index?page=content&id=KB75925&actp=LIST

My workaround for Ubuntu 10.04.4:
$ sudo ln -s /lib32/ld-linux.so.2 /lib/ld-~fix-linux.so.2

@Adam: thank you for the detailed explanation. Now it seems as this is a McAfee bug, however they don't agree https://kc.mcafee.com/corporate/index?page=content&id=KB75925&actp=LIST

> My workaround for Ubuntu 10.04.4:
> $ sudo ln -s /lib32/ld-linux.so.2 /lib/ld-~fix-linux.so.2
This works for Ubuntu 12.04.2 also, however make sure libc6-i386 is installed before you create a link (this is true for both 10.04 and 12.04). Otherwise ldconfig is going to remove the link.

For 32-bit system the link has to be slightly different:
$ sudo ln -s /lib/i386-linux-gnu/ld-linux.so.2 /lib/ld-~fix-linux.so.2

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eglibc - 2.19-0ubuntu2

---------------
eglibc (2.19-0ubuntu2) trusty; urgency=medium

  * Merge with unreleased 2.19 from Debian experimental, fixing some bugs:
    - debian/patches/any/local-no-malloc-backtrace.diff: Lower the default
      for MALLOC_CHECK_ to 1, and add it to the list of insecure variables
      that can't be set for suid binaries. This allows us to not backtrace
      malloc failures by default (Closes: #739913, LP: #1266492) and skips
      backtrace for suid binaries where an attacker calling into a corrupt
      malloc internal data structure with malloc could lead to Bad Things.
    - Make ldconfig stop operating on the linker entirely, so our packaged
      symlinks take precedence and hack the postinst to skip ldconfig when
      we detect a broken setup that the old ldconfig mangles (LP: #915995)
 -- Adam Conrad <email address hidden> Sun, 23 Feb 2014 22:39:18 -0700

Changed in eglibc (Ubuntu):
status: Invalid → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.