If you installed Glibc 2.2 on a 6.4 system..you have probably broke a lot of the system that was compiled to run software on a different version of glibc. glibc is backward compatible but not forward..so if they are looking for libs that are newer version then they were compiled against then they will most likely error. You should just build a new drive w/ a newer version of SuSE on it..transfer your configs and data to the new system and do a latenight cut over. * engelbert.gruber@ssg.co.at (engelbert.gruber@ssg.co.at) [020224 23:28]: ->On Mon, 25 Feb 2002, Ralf Schoenian wrote: -> ->> Hello, ->> ->> I have tried to install a new openssh version on a SuSE Linux 6.4 The rpm ->> expected the glibc 2.2 so I have installed this too. Now I am in trouble. A ->> friend told me, that the server will not reboot. Is that true? Does anyone ->> have an idea what I can do? ->not absolutely. ->i did the same BUT i have the server at my side and i replaced ->all (or most) of the base packages (that is series a) and there ->lies another dog :-) the packages nkita and nkitb are split ->up on newer suses for example telnet is now in telnet and telnet-server ->ESPECIALLY inetd is in a separate package. -> ->summing up: it should work check closely for base packages -> (maybe replace the kernel) and check for needed and running -> servers: as long as you donot reboot the running servers -> will serve although no longer installed. -> ->-- -> BINGO: conveniently integrate economically sound technology -> --- Engelbert Gruber ----=~ -> SSG Fintl,Gruber,Lassnig -> -> A6410 Telfs Untermarkt 9 -> Tel. ++43-5262-64727 ----=~ -> -> ->-- ->To unsubscribe, e-mail: suse-security-unsubscribe@suse.com ->For additional commands, e-mail: suse-security-help@suse.com ->Security-related bug reports go to security@suse.de, not here -> -----=====-----=====-----=====-----=====----- Ben Rosenberg mailto:ben@whack.org -----=====-----=====-----=====-----=====----- "I've never been quarantined. But the more I look around the more I think it might not be a bad thing." -JC

If you install something that was compiled for glibc 2.2 on a 2.4 glibc system then it will run..ie backwards compatible..but if you install something compiled for glibc 2.4 on a system with 2.2 installed..it most like will hiccup and not run right. So if you update glibc on a system to a newer version..then some of the software will need recompiling so it can run right. It's not forward compatible...2.4 binaries will have issues running on a 2.2 (glibc) system. * Anders Johansson (andjoh@cicada.linux-site.net) [020224 23:39]: ->On Monday 25 February 2002 08:31, Ben Rosenberg wrote: ->> glibc is backward compatible but not forward..so if ->> they are looking for libs that are newer version then they were compiled ->> against then they will most likely error. -> ->Hm. -> ->This sounds a bit strange. Could you expand on this? -> ->//Anders -> ->-- ->To unsubscribe, e-mail: suse-security-unsubscribe@suse.com ->For additional commands, e-mail: suse-security-help@suse.com ->Security-related bug reports go to security@suse.de, not here -> -----=====-----=====-----=====-----=====----- Ben Rosenberg mailto:ben@whack.org -----=====-----=====-----=====-----=====----- "I've never been quarantined. But the more I look around the more I think it might not be a bad thing." -JC

Hi Engelbert, engelbert.gruber@ssg.co.at schrieb am 25.02.2002, 09:19:55:

On Sun, 24 Feb 2002, Ben Rosenberg wrote:

...

If you install something that was compiled for glibc 2.2 on a 2.4 glibc system then it will run..ie backwards compatible..but if you install something compiled for glibc 2.4 on a system with 2.2 installed..it most like will hiccup and not run right. So if you update glibc on a system to a newer version..then some of the software will need recompiling so it can run right. It's not forward compatible...2.4 binaries will have issues running on a 2.2 (glibc) system. suse64 is pre glibc as far as i can remember, so everything should run as glibc is backwards compatible.

Are you sure? I left the libc untouched. I could imagine that the elder daemons will use the libc and only the newer sshd will use the glibc but who knows for sure?! I will install a second server on another machine within vmware and test it. In the meanwhile I will pray that I do not have to reboot. Should have done this testing before. Million thanks for all your answers, so far. Greetings Ralf Schoenian

Hi Everyone. I have just starting using chrootkit and as I do not really know what files are installed. I was wondering if these files are really suspicious and if I should delete them. please note. I have installed the Apache webserver with perl for the Intranet. Searching for suspicious files and dirs, it may take a while... /usr/lib/perl5/5.6.0/i586-linux/.packlist /usr/lib/perl5/site_perl/5.6.0/i586- linux/auto/Alien/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/Storable/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/Tk/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/Locale/gettext/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/Tie/IxHash/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/Digest/MD5/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/HTML/Parser/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/MIME/Base64/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/URI/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/Net/.packlist /usr/lib/perl5/site_perl/5.6.0/i586-linux/auto/libwww-perl/.packlist /usr/lib/jdk1.1.8/bin/.java_wrapper /usr/lib/jdk1.1.8/bin/i686/green_threads/.extract_args /usr/lib/jdk1.1.8/bin/i686/native_threads/.extract_args Ian Laws

On Tue, Feb 26, 2002 at 09:57:32AM +0000, Bob Vickers wrote:

Ian,

Have you done any checking with rpm? It has good options for verifying where files came from, e.g.

rpm -qf filename rpm --verify packagename rpm -ql packagename

In order to check _all_ packages, you can also use rpm -V -a The third column reads "5" if the md5 sum of the file differs from the data saved in the rpm database. If someone has modified binaries (and the rpm db is not corrupted), they will show up when you pick out modified files via rpm -V -a | grep "..5"

I suppose if you are really paranoid you might distrust the information if you think you have been cracked, [...]

I have no idea how easy it is to modify the rpm database. Does anyone know of a rootkit that automates this? Best regards, Albert

Yeah, I know. You just proved what I thought was correct..everything before 6.0 was libc5..6.0 was glibc ;) * Roman Drahtmueller (draht@suse.de) [020226 06:13]: ->Hi Ben! -> ->> ->> Nope, 6.0 was glibc I believe...anything prior to it was libc5. ->> -> ->Ack. From http://www.suse.de/de/support/security/2001_046_glibc_txt.html : -> ->Overview: -> -> dist | source-RPM | shared libs | static libs,header| profiling -> ->----------------------------------------------------------------------- -> 6.4,7.0 libc shlibs libc libd -> 7.1,7.2,7.3 glibc glibc glibc-devel glibc-profile -> -> ->6.4 and 7.0 have a glibc-2.1.3, ->7.1 has glibc-2.2, ->7.2 has glibc-2.2.2, ->7.3 has glibc-2.2.4 -> ->The old 6.0 and 6.1 versions had a glibc-2.0, 6.2 and on were the first ->ones with a 2.1 glibc. -> ->Thanks, ->Roman. ->-- -> - - ->| Roman Drahtmüller // "You don't need eyes to see, | -> SuSE GmbH - Security Phone: // you need vision!" ->| Nürnberg, Germany +49-911-740530 // Maxi Jazz, Faithless | -> - - -> -----=====-----=====-----=====-----=====----- Ben Rosenberg mailto:ben@whack.org -----=====-----=====-----=====-----=====----- "I've never been quarantined. But the more I look around the more I think it might not be a bad thing." -JC