Subject: bin/3046: ldd actually runs target programs.
To: None <gnats-bugs@gnats.netbsd.org>
From: Chris G. Demetriou <cgd@sun-lamp.pc.cs.cmu.edu>
List: netbsd-bugs
Date: 12/12/1996 20:47:55
>Number: 3046
>Category: bin
>Synopsis: ldd actually runs target programs.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people (Utility Bug People)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 19 02:05:02 1996
>Last-Modified:
>Originator: Chris G. Demetriou
>Organization:
Kernel Hackers 'r' Us
>Release: NetBSD-current as of Dec. 12, 1996
>Environment:
System: NetBSD sun-lamp.pc.cs.cmu.edu 1.2B NetBSD 1.2B (SUN_LAMP) #3: Fri Nov 8 17:29:37 EST 1996 cgd@sun-lamp.pc.cs.cmu.edu:/a/netbsd-src/working/src/sys.nkpde/arch/i386/compile/SUN_LAMP i386
>Description:
NetBSD's (a.out) ldd actually runs target programs, with
an environment variable set, to determine whether or not they
are dynamically linked.
While that works fine given NetBSD's standard C runtime startup
and dynamic linker code, it can be exploited to create trojan
horses.
Some would claim that this is a "known fact" about ldd, but
it's not a well publicised one (in particular, it's not mentioned
in the ldd manual page), nor is it one that makes very much
sense to a naive user.
>How-To-Repeat:
Simple:
Set the 'dynamically linked' flag in a statically-linked program's
a.out header, then 'ldd' that program. Note that the program itself
is run, works as it normally would, etc.
More complex:
Create a statically linked program that simulates dynamic linker
error messages (indicating library problems) if run normally, but
which performs malicious actions and outputs ldd-like data
if run under ldd. Set the 'dynamically linked' flag in its a.out
header. Convince somebody to run ldd on it, to help you diagnose
your problem.
>Fix:
Have 'ldd' actually examine dynamically-linked executables'
dynamic linking data structures to determine what libraries
they want to include.
>Audit-Trail:
>Unformatted: