[linux-elitists] Comprehensive list of Linux malware

Karsten M. Self kmself@ix.netcom.com
Thu Dec 9 16:33:27 PST 2004


on Thu, Dec 09, 2004 at 10:06:34AM -0500, Etienne Goyer (etienne.goyer@videotron.ca) wrote:
> Karsten M. Self wrote:
> >on Wed, Dec 08, 2004 at 09:50:13AM -0500, Etienne Goyer 
> >(etienne.goyer@videotron.ca) wrote:
> >
> >>Karsten M. Self wrote:
> >>
> >>>For RPM, you'd require explicit RPM support.
> >>
> >>Why ?
> >
> >
> >   $ ldd $( which rpm )
> 
> So what ?  

Well, I was hoping I wouldn't have to be this pedantic, but:

    $ ldd $( which rpm )
    librpmbuild-4.0.4.so => /usr/lib/librpmbuild-4.0.4.so (0x4002a000)
  * librpm-4.0.4.so => /usr/lib/librpm-4.0.4.so (0x4005a000)
  * librpmdb-4.0.4.so => /usr/lib/librpmdb-4.0.4.so (0x400a5000)
    libdb3.so.3 => /usr/lib/libdb3.so.3 (0x400ba000)
  * librpmio-4.0.4.so => /usr/lib/librpmio-4.0.4.so (0x40164000)
    libz.so.1 => /usr/lib/libz.so.1 (0x401a2000)
    libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x401b4000)
    libpopt.so.0 => /lib/libpopt.so.0 (0x401c4000)
    librt.so.1 => /lib/tls/librt.so.1 (0x401cd000)
    libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401d3000)
    libc.so.6 => /lib/tls/libc.so.6 (0x401e2000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

...and for what that takes:

    $ du -sch $( ldd $( which rpm ) | awk '/rpm/ {print $3}' )
    112K    /usr/lib/librpmbuild-4.0.4.so
    260K    /usr/lib/librpm-4.0.4.so
    72K     /usr/lib/librpmdb-4.0.4.so
    212K    /usr/lib/librpmio-4.0.4.so
    656K    total

...or 39% of a 1.7 MiB floppy's storage capacity.

Another utility is 'alien', a perl executable, so we'll look for 'use'
statements:

    use Getopt::Long;
    use Alien::Package::Deb;
  * use Alien::Package::Rpm;
    use Alien::Package::Tgz;
    use Alien::Package::Slp;
    use Alien::Package::Pkg;
    use Alien::Package::Lsb;

...Alien::Packag::Rpm itself relies on rpm2cpio, for which we see a
familiar list:

    $ ldd $( which rpm2cpio )
    librpmbuild-4.0.4.so => /usr/lib/librpmbuild-4.0.4.so (0x4002a000)
  * librpm-4.0.4.so => /usr/lib/librpm-4.0.4.so (0x4005a000)
  * librpmdb-4.0.4.so => /usr/lib/librpmdb-4.0.4.so (0x400a5000)
    libdb3.so.3 => /usr/lib/libdb3.so.3 (0x400ba000)
  * librpmio-4.0.4.so => /usr/lib/librpmio-4.0.4.so (0x40164000)
    libz.so.1 => /usr/lib/libz.so.1 (0x401a2000)
    libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x401b4000)
    libpopt.so.0 => /lib/libpopt.so.0 (0x401c4000)
    librt.so.1 => /lib/tls/librt.so.1 (0x401cd000)
    libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401d3000)
    libc.so.6 => /lib/tls/libc.so.6 (0x401e2000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


> You could do your disk shuttling thingy on a RedHat just as well on a
> RedHat system.  Why would you need RPM ?

What's required, specifically, is RPM support, namely, the RPM libs.
Which lay a 656 KiB storage overhead on your system.

Why do you need this?  To unpack the archives.  I'm talking about
building up a system from scratch, or after gross damage.

Compare with a DEB's requirements:  ar & tar:

    $ ldd $( which ar )
    libbfd-2.15.so => /usr/lib/libbfd-2.15.so (0x4002a000)
    libc.so.6 => /lib/tls/libc.so.6 (0x400b9000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

    $ ldd $( which tar )
    librt.so.1 => /lib/tls/librt.so.1 (0x4002a000)
    libc.so.6 => /lib/tls/libc.so.6 (0x40030000)
    libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4016c000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

...all libc or binary utilities deps.
 
> The point is moot anyway.  If your system is so old that it does not
> have a bootable CD-ROM, I think it might be time to upgrade to one
> built after 1996.  Really.

Bootable floppies offer one advantage over (most) bootable CDs:  you
free both the floppy *and* the CDROM after boot, as the system runs
entirely in memory.  While this is possible with a CDROM, you need
memory sufficient for the entire disk image in memory.  That's ~50MB +
for a mini/businesscard CD, 650-700 MiB+ for a full image.  Given
there's a lot of systems with ~128 - 512 MiB RAM (and the latter being a
bit "beefy" for standard desktop deployment), in-memory bootable CDs are
an iffy proposition.

You can moot the issue all you want.  What I know is that there's a lot
of extant hardware for which these techniques work, and alternatives
don't.  The point is that by keeping the bar, requirements, and
dependencies to a minimum, you're left with a lot of flexibility when
using DEBs (or Slack packages, or anything else built out of standard
shell tools).  RPM loses in this regard.

KISS.  You've heard of it?


Peace.

-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Necessity knows no law.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20041209/75adba5b/attachment.pgp 


More information about the linux-elitists mailing list