Detecting fake library versions
wblock at wonkity.com
Thu Jun 17 17:08:08 UTC 2010
On Thu, 17 Jun 2010, Matthew Seaman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 17/06/2010 16:04:20, Warren Block wrote:
>>> This is not generally true for shlibs installed from ports, mostly due
>>> to the prevalence of linuxisms like ABI version numbers that aren't
>>> simple integers. Even so, applying a little intelligent scrutiny to the
>>> list of results will help you sort out any spurious linkage.
>> Could you expand on this part?
>> find reports 83 links in /usr/local/lib. But only the fake libintl.so.8
>> is linked to a port-created library but not recorded as part of the
>> gettext package.
> Right. In /usr/local/lib on one machine I happen to have the following:
> % find /usr/local/lib -name '*.so.*' -type l -ls | cut -c 89-
> /usr/local/lib/libicuio.so.38 -> libicuio.so.38.1
> /usr/local/lib/libutempter.so.0 -> libutempter.so.1.1.5
> /usr/local/lib/libicuuc.so.38 -> libicuuc.so.38.1
> /usr/local/lib/libicule.so.38 -> libicule.so.38.1
> /usr/local/lib/libXaw.so.7 -> libXaw7.so.7
> /usr/local/lib/libdb-4.8.so.0 -> db48/libdb-4.8.so.0
> /usr/local/lib/libdb_cxx-4.8.so.0 -> db48/libdb_cxx-4.8.so.0
> /usr/local/lib/libgs.so.8 -> libgs.so.8.71
> /usr/local/lib/libXau.so.0 -> /usr/local/lib/libXau.so.6
> /usr/local/lib/libicutu.so.38 -> libicutu.so.38.1
> /usr/local/lib/libXaw.so.6 -> libXaw6.so.6
> /usr/local/lib/libiculx.so.38 -> libiculx.so.38.1
> /usr/local/lib/libicui18n.so.38 -> libicui18n.so.38.1
> /usr/local/lib/liblua-5.1.so.1 -> lua51/liblua-5.1.so.1
> /usr/local/lib/libicudata.so.38 -> libicudata.so.38.1
> You can see several different patterns here.
> Primus: like libdb-4.8.so.0 or liblua-5.1.so.1 --- the shlib is
> installed into a sub-dir of /usr/local/lib and linked back into the main
> directory. This is generally used when there are several different
> versions of the particular library available in ports.
> Secondus: like libXaw.so.6, libXaw.so.7 -- for some reason, the file is
> installed with the ABI version as part of the basename of the file and
> the link just provides the expected name.
> Tertius: like libicuio.so.38 and pretty much all the rest. *BSD uses
> .38 as the ABI version number, whereas linux seems to prefer .38.1 --
> occasionally this sort of thing is the result of developers being
> unclear on the concept of an ABI version number, and just using their
> main code version number.
> These are all perfectly normal and as installed from ports -- a little
> work with 'pkg_which' and 'pkg_info -g' will demonstrate that.
That is essentially what the original Ruby script did, slowly, but
quicker than doing it by hand.
> On the other hand, if I'd seen:
> /usr/local/lib/libintl.so.8 -> libintl.so.9
> where there is a shlib with the standard ABI version pattern as expected
> under *BSD, but it's a link to another shlib with a *different* major
> version number, then it's pretty clear someone has been bodging things.
> Clear enough?
For an interactive method, yes. I'm trying to find something for the
people who thought it was a link-and-forget solution instead of a
I just took the approach that a port library with a link that isn't
part of the port is suspicious.
A much faster yet questionable Ruby version is here:
-Warren Block * Rapid City, South Dakota USA
More information about the freebsd-questions