Re: Detecting fake library versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/06/2010 01:59:04, Warren Block wrote: On Wed, 16 Jun 2010, Warren Block wrote: ln -s libintl.so.9 libintl.so.8 has been misused a lot lately. Are there any programs that will detect these links and remind the user that they have a new library masquerading as an old one? A quick hack in Ruby to address this: http://www.wonkity.com/~wblock/fakelib/fakelib.rb It's not particularly fast or elegant. On the other hand, it's short and does detect the link above. Trying much too hard there. This command is all you need: find /usr/lib /lib -name '*.so.*' -type l Any file named libfoo.so.N in the base system should be a regular file: any symbolic links indicate shlib abuse. 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. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwZ0BwACgkQ8Mjk52CukIxoXACfUoEVRHvj7Lc/mjjpwp2WLPnt 0kEAn3IrKC+vPIw0NRduPL/ZFtrJP3rQ =Dwna -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Detecting fake library versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/06/2010 08:34:52, Matthew Seaman wrote: On 17/06/2010 01:59:04, Warren Block wrote: On Wed, 16 Jun 2010, Warren Block wrote: ln -s libintl.so.9 libintl.so.8 has been misused a lot lately. Are there any programs that will detect these links and remind the user that they have a new library masquerading as an old one? A quick hack in Ruby to address this: http://www.wonkity.com/~wblock/fakelib/fakelib.rb It's not particularly fast or elegant. On the other hand, it's short and does detect the link above. Trying much too hard there. This command is all you need: find /usr/lib /lib -name '*.so.*' -type l Any file named libfoo.so.N in the base system should be a regular file: any symbolic links indicate shlib abuse. 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. But what about hard links? I hear you ask. Simple: find /usr/lib /lib -name '*.so.*' -links +2 Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwZ0TkACgkQ8Mjk52CukIzpZwCgkwa7oyhwq6To0s08eAYT+flO PnIAn3XG7Fs+TOLPP00k8z/kfP0ZhOKd =3I0Z -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Detecting fake library versions
On Thursday 17 June 2010 09:39:37 Matthew Seaman wrote: But what about hard links? I hear you ask. Simple: find /usr/lib /lib -name '*.so.*' -links +2 +1 surely? + modifier in find(1) means ``more than'', not ``at least''. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Detecting fake library versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/06/2010 09:16:33, Jonathan McKeown wrote: On Thursday 17 June 2010 09:39:37 Matthew Seaman wrote: But what about hard links? I hear you ask. Simple: find /usr/lib /lib -name '*.so.*' -links +2 +1 surely? + modifier in find(1) means ``more than'', not ``at least''. Ooops. Yes. +1 on that. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwZ4skACgkQ8Mjk52CukIzX4gCdFOZQRpbh3xE+5ALWkWZHMjdK EhwAnRPrQxSAljmhckuE7eo+gYS/FMLL =YcL7 -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Detecting fake library versions
On Thu, 17 Jun 2010, Matthew Seaman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/06/2010 01:59:04, Warren Block wrote: On Wed, 16 Jun 2010, Warren Block wrote: ln -s libintl.so.9 libintl.so.8 has been misused a lot lately. Are there any programs that will detect these links and remind the user that they have a new library masquerading as an old one? A quick hack in Ruby to address this: http://www.wonkity.com/~wblock/fakelib/fakelib.rb It's not particularly fast or elegant. On the other hand, it's short and does detect the link above. Trying much too hard there. This command is all you need: find /usr/lib /lib -name '*.so.*' -type l Any file named libfoo.so.N in the base system should be a regular file: any symbolic links indicate shlib abuse. 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. -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Detecting fake library versions
-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. 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? Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwaQRkACgkQ8Mjk52CukIz9igCeP5ZObIL6KZoobcNk+1wMcvzC 9QUAnRnYAQENJiAtfMCZTtekeqPvvbrO =BMLp -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Detecting fake library versions
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 temporary workaround. 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: http://www.wonkity.com/~wblock/fakelib/fastfakelib -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Detecting fake library versions
ln -s libintl.so.9 libintl.so.8 has been misused a lot lately. Are there any programs that will detect these links and remind the user that they have a new library masquerading as an old one? -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Detecting fake library versions
On Wed, 16 Jun 2010, Warren Block wrote: ln -s libintl.so.9 libintl.so.8 has been misused a lot lately. Are there any programs that will detect these links and remind the user that they have a new library masquerading as an old one? A quick hack in Ruby to address this: http://www.wonkity.com/~wblock/fakelib/fakelib.rb It's not particularly fast or elegant. On the other hand, it's short and does detect the link above. -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
