#26 [PATCH] LD_LIBRARY_PATH size-dependent false positive

closed
unSpawn
rkhunter (35)
5
2009-01-13
2008-12-10
Jan Iven
No

environment variables can alter the base address for shared libraries.

A longish LD_LIBRARY_PATH in this test might lead to a false positive, even if the path is invalid or does not contain any system libraries.

quick example - compare:

LD_LIBRARY_PATH=`perl -e 'print "a"x40960'` ldd /bin/ls
LD_LIBRARY_PATH= ldd /bin/ls

typically lowest-mapped library base address would shift by a few k.

The patch replaces the base addresses in the ldd output. A difference in the actual library path should still get reported.

Discussion

  • unSpawn

    unSpawn - 2008-12-10

    Could you help me understand the impact of this? LD_LIBRARY_PATH discards entries longer than say 258 chars, so if I export your 40960 char LD_LIBRARY_PATH and 'ldd /some/binary|md5sum' the hash is the same as without LD_LIBRARY_PATH?

     
  • unSpawn

    unSpawn - 2008-12-10
    • labels: --> rkhunter
    • assigned_to: nobody --> unspawn
     
  • Jan Iven

    Jan Iven - 2008-12-10

    Sure - the impact is via the "larger" environment, not through ld.so's usage of LD_LIBRARY_PATH - so any large environment variable might shift the base address. It is just that between the two tests (to see whether system binaries are affected) rkhunter only drops LD_LIBRARY_PATH..

    On a RHEL5-clone (or RHEL4), the above test gives
    ~$ LD_LIBRARY_PATH=`perl -e 'print "a"x40960'` ldd /bin/ls
    linux-gate.so.1 => (0x002c2000)
    librt.so.1 => /lib/librt.so.1 (0x005be000)
    libacl.so.1 => /lib/libacl.so.1 (0x00df6000)
    libselinux.so.1 => /lib/libselinux.so.1 (0x00790000)
    libc.so.6 => /lib/libc.so.6 (0x00a8a000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00bfe000)
    /lib/ld-linux.so.2 (0x00a67000)
    libattr.so.1 => /lib/libattr.so.1 (0x00995000)
    libdl.so.2 => /lib/libdl.so.2 (0x00bf8000)
    libsepol.so.1 => /lib/libsepol.so.1 (0x07236000)
    ~$ LD_LIBRARY_PATH= ldd /bin/ls
    linux-gate.so.1 => (0x0095a000)
    librt.so.1 => /lib/librt.so.1 (0x005be000)
    libacl.so.1 => /lib/libacl.so.1 (0x00df6000)
    libselinux.so.1 => /lib/libselinux.so.1 (0x00790000)
    libc.so.6 => /lib/libc.so.6 (0x00a8a000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00bfe000)
    /lib/ld-linux.so.2 (0x00a67000)
    libattr.so.1 => /lib/libattr.so.1 (0x00995000)
    libdl.so.2 => /lib/libdl.so.2 (0x00bf8000)
    libsepol.so.1 => /lib/libsepol.so.1 (0x07236000)

    (so linux-gate.so.1 moved from 0x002c2000 to 0x0095a000 - rkhunter would treat this as a possible attempt to subvert the binary, even though nothing really changed).

    Best regards
    Jan

     
  • unSpawn

    unSpawn - 2008-12-10

    Ah. On CentOS-3 and CentOS-5 I didn't see that behaviour at all but on Slackware 12.1 I do. Makes me wonder what causes it that I see none in CentOS. Wrt your remark "A difference in the actual library path should still get reported" currently RKH only alerts if LD_LIBRARY_PATH is used or not. We don't save the info so path elements nor changes get checked.

     
  • unSpawn

    unSpawn - 2008-12-11
    • status: open --> pending
     
  • unSpawn

    unSpawn - 2008-12-11

    Added in CVS for testing.

     
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • SourceForge Robot

    • status: pending --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks