Library on a collision course! On the screen!

Flameeyes

16 years ago

So after almost an year, I returned working on the library collision detection that comes with ruby-elf. I now have a much more powerful system to work on, but I also have a much bigger set of samples to scan, in my tinderbox.

Beside a few issues that I’ve had to taken care of, I’ve now got a database that contains a huge amount of data to process and useful information to derive. Just to give some statistics, the script harvested 24602 ELF files, counting 2713395 symbols, of which 326399 are duplicate between objects. These statistics have already counted out all the suppressed symbols known up to now, but obviously there are more yet unknown.

To stick with statistics for now, rather than actual results, it’s interesting to know that about 1365671 C++ ABI symbols, I sincerely wonder how many of these should be hidden instead.

On a more interesting note, Samba confirms itself sub-optimal by now having yet a convenience library for its shared functions, and copying over the symbols between the various pieces of the puzzle, included six different Python modules, whose total size would probably be cut in half I guess.

Sticking with the Python side, there is one damn issue that is really upsetting me: about thirty different packages link the Python interpreter statically rather than dynamically, resulting in around 30 different copies of Python itself in the full of Portage. Nasty. The problem is that the ebuild installs the shared and static libraries in two different paths, one of which being private “config” path for Python. The packages picking that up will explicitly request it at link time, causing Python to be linked in statically rather than dynamically:

Symbol PyBaseString_Type@@ (32-bit UNIX System V ABI Intel 80386) present 30 times
  /usr/games/bin/diameter
  /usr/bin/vim
  /usr/bin/gedit
  /usr/lib/root/libPyROOT.so.5.22
  /usr/lib/python2.5/site-packages/opencv/_highgui.so
  /usr/lib/libpython2.5.so.1.0
  /usr/bin/eog
  /usr/games/lib/mcl/plugins/python.so
  /usr/sbin/bextract
  /usr/bin/zapping
  /usr/lib/python2.5/site-packages/opencv/_cv.so
  /usr/bin/gvim
  /usr/bin/gwp
  /usr/bin/cooledit
  /usr/lib/planner/plugins/libpython-plugin.so
  /usr/sbin/bacula-fd
  /usr/sbin/bacula-sd
  /usr/lib/dia/libpython_plugin.so
  /usr/lib/xchat/plugins/python.so
  /usr/lib/xchat-gnome/plugins/python.so
  /usr/sbin/bacula-dir
  /usr/lib/gnumeric/1.8.3/plugins/python-loader/python_loader.so
  /usr/games/bin/adonthell
  /usr/games/bin/kiki
  /usr/lib/libgnt.so.0.0.0
  /usr/bin/epiphany
  /usr/lib/python2.5/site-packages/_lcms.so
  /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/Inline/Python/Python.so
  /usr/lib/apache2/modules/mod_wsgi.so
  /usr/lib/apache2/modules/mod_python.so

As you can see this includes two Apache modules, and quit a few pieces of GNOME. This is quite nasty. My suggestion until this is sorted out is not to enable python USE flag unless you really really really need it. The nastiest bit is that since there has been a Python vulnerability if you didn’t rebuild these packages after the bump, you’ll have them using a vulnerable interpreter, still. Do I really have to spell out how bad that is for stuff like Apache modules?

Share this: