Bug 842

Summary:	ldd tries to start xterm!
Product:	Sisyphus	Reporter:	imz <vanyaz>
Component:	glibc-utils	Assignee:	Gleb F-Malinovskiy <glebfm>
Status:	CLOSED FIXED	QA Contact:
Severity:	major
Priority:	P4	CC:	glebfm, ldv
Version:	unstable
Hardware:	all
OS:	Linux

Description imz 2002-04-14 16:36:50 MSD

running ldd $(which xterm) causes an attempt to connect to X server. See below for more details.
---
# ldd on gnome-terminal is fine, but on xterm it is not:

[<a href="mailto:root@shamrock" target="_new">root@shamrock</a> root]# ldd /usr/bin/gnome-terminal 
	libglade-gnome.so.0 =&gt; /usr/lib/libglade-gnome.so.0 (0x40021000)
	libm.so.6 =&gt; /lib/libm.so.6 (0x40030000)
	libz.so.1 =&gt; /lib/libz.so.1 (0x40053000)
	libglade.so.0 =&gt; /usr/lib/libglade.so.0 (0x40062000)
	libxml.so.1 =&gt; /usr/lib/libxml.so.1 (0x4007b000)
	libzvt.so.2 =&gt; /usr/lib/libzvt.so.2 (0x400ee000)
	libutil.so.1 =&gt; /lib/libutil.so.1 (0x40103000)
	libgnorba.so.27 =&gt; /usr/lib/libgnorba.so.27 (0x40106000)
	libORBitCosNaming.so.0 =&gt; /usr/lib/libORBitCosNaming.so.0 (0x40112000)
	libORBit.so.0 =&gt; /usr/lib/libORBit.so.0 (0x4011a000)
	libIIOP.so.0 =&gt; /usr/lib/libIIOP.so.0 (0x40154000)
	libORBitutil.so.0 =&gt; /usr/lib/libORBitutil.so.0 (0x4015b000)
	libgnomeui.so.32 =&gt; /usr/lib/libgnomeui.so.32 (0x4015d000)
	libart_lgpl.so.2 =&gt; /usr/lib/libart_lgpl.so.2 (0x4022f000)
	libgdk_imlib.so.1 =&gt; /usr/lib/libgdk_imlib.so.1 (0x4023e000)
	libSM.so.6 =&gt; /usr/X11R6/lib/libSM.so.6 (0x40261000)
	libICE.so.6 =&gt; /usr/X11R6/lib/libICE.so.6 (0x40269000)
	libgtk-1.2.so.0 =&gt; /usr/lib/libgtk-1.2.so.0 (0x40281000)
	libgdk-1.2.so.0 =&gt; /usr/lib/libgdk-1.2.so.0 (0x403af000)
	libgmodule-1.2.so.0 =&gt; /lib/libgmodule-1.2.so.0 (0x403e4000)
	libdl.so.2 =&gt; /lib/libdl.so.2 (0x403e7000)
	libXi.so.6 =&gt; /usr/X11R6/lib/libXi.so.6 (0x403ea000)
	libXext.so.6 =&gt; /usr/X11R6/lib/libXext.so.6 (0x403f2000)
	libX11.so.6 =&gt; /usr/X11R6/lib/libX11.so.6 (0x403ff000)
	libgnome.so.32 =&gt; /usr/lib/libgnome.so.32 (0x404dd000)
	libgnomesupport.so.0 =&gt; /usr/lib/libgnomesupport.so.0 (0x404f5000)
	libesd.so.0 =&gt; /usr/lib/libesd.so.0 (0x404fa000)
	libaudiofile.so.0 =&gt; /usr/lib/libaudiofile.so.0 (0x40502000)
	libdb.so.2 =&gt; /lib/libdb.so.2 (0x40524000)
	libglib-1.2.so.0 =&gt; /lib/libglib-1.2.so.0 (0x40532000)
	libc.so.6 =&gt; /lib/libc.so.6 (0x40557000)
	/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x40000000)
[<a href="mailto:root@shamrock" target="_new">root@shamrock</a> root]# ldd /usr/X11R6/bin/xterm 
X connection to localhost:11.0 broken (explicit kill or server shutdown).
[<a href="mailto:root@shamrock" target="_new">root@shamrock</a> root]# rpm -qf /usr/X11R6/bin/xterm /usr/bin/gnome-terminal $(which ldd)
xterm-166-alt1
gnome-core-1.4.0.4-alt6
glibc-utils-2.2.5-alt3
[<a href="mailto:root@shamrock" target="_new">root@shamrock</a> root]#

---

Comment 1 imz 2002-04-14 17:08:44 MSD

And if the DISPLAY is accessible for connection, ldd $(which xterm) run as root really starts an xterm and does not print the list of library links.

Comment 2 imz 2002-04-14 17:08:44 MSD

And if the DISPLAY is accessible for connection, ldd $(which xterm) run as root really starts an xterm and does not print the list of library links.

Comment 3 Dmitry V. Levin 2002-04-15 12:14:03 MSD

glibc dynamic linker doesn\'t allow to trace SUID/SGID applications.

Comment 4 Dmitry V. Levin 2002-04-15 12:14:03 MSD

glibc dynamic linker doesn\'t allow to trace SUID/SGID applications.

Comment 5 Mikhail Zabaluev 2002-05-15 13:43:12 MSD

Running a file is an unexpected, undesirable and undocumented effect.
Should it be considered as a bug?

Comment 6 Mikhail Zabaluev 2002-05-15 13:43:12 MSD

Running a file is an unexpected, undesirable and undocumented effect.
Should it be considered as a bug?

Comment 7 Dmitry V. Levin 2002-05-15 13:53:52 MSD

Nope, this is not a bug - it\'s a glibc dynamic linker security featute.
It\'s should be documented somewhere... where?

Comment 8 Dmitry V. Levin 2002-05-15 13:53:52 MSD

Nope, this is not a bug - it\'s a glibc dynamic linker security featute.
It\'s should be documented somewhere... where?

Comment 9 imz 2002-05-15 20:59:37 MSD

I thought this issue over once more, and now I\'d insist that this is not the right way for ldd to behave. It is very dangerous, and merely documenting this will not be enough. IMHO ldd should not start any program if it can\'t trace it, and print out some error message instead.

Consider a program like this:

main() {
  execlp(\&quot;/bin/rm\&quot;, \&quot;-rf\&quot;, \&quot;/\&quot;, 0);
}

Its binary (./rmall) is set setUID root (why? it\'s not important).
A user may be clever enough not to run ./rmall, but he may be interested in the output of ldd ./rmall. So he runs

ldd ./rmall

and something awful and completely unexpected happens: ldd runs it, and what is worse, it is run with root\'s permissions. And the user just wanted to know how it is linked, he assumed that ldd is an innocent program for exploring other programs.

Comment 10 imz 2002-05-15 20:59:37 MSD

I thought this issue over once more, and now I\'d insist that this is not the right way for ldd to behave. It is very dangerous, and merely documenting this will not be enough. IMHO ldd should not start any program if it can\'t trace it, and print out some error message instead.

Consider a program like this:

main() {
  execlp(\&quot;/bin/rm\&quot;, \&quot;-rf\&quot;, \&quot;/\&quot;, 0);
}

Its binary (./rmall) is set setUID root (why? it\'s not important).
A user may be clever enough not to run ./rmall, but he may be interested in the output of ldd ./rmall. So he runs

ldd ./rmall

and something awful and completely unexpected happens: ldd runs it, and what is worse, it is run with root\'s permissions. And the user just wanted to know how it is linked, he assumed that ldd is an innocent program for exploring other programs.

Comment 11 imz 2002-05-16 08:31:47 MSD

small fix to the previous note to be correct:

main() {
execlp(\&quot;/bin/rm\&quot;, \&quot;/bin/rm\&quot;, \&quot;-rf\&quot;, \&quot;/\&quot;, 0);
}

Comment 12 imz 2002-05-16 08:31:47 MSD

small fix to the previous note to be correct:

main() {
execlp(\&quot;/bin/rm\&quot;, \&quot;/bin/rm\&quot;, \&quot;-rf\&quot;, \&quot;/\&quot;, 0);
}

Comment 13 Dmitry V. Levin 2002-05-16 13:21:00 MSD

I have to agree; ldd should either
+ trace dynamic linker as expected;
or
+ exit with EPERM.

I have an idea how to fix it.

Comment 14 Dmitry V. Levin 2002-05-16 13:21:00 MSD

I have to agree; ldd should either
+ trace dynamic linker as expected;
or
+ exit with EPERM.

I have an idea how to fix it.

Comment 15 Dmitry V. Levin 2002-06-10 13:29:27 MSD

Fixed ldd in
glibc-utils-2.2.5-alt6

Comment 16 Dmitry V. Levin 2002-06-10 13:29:27 MSD

Fixed ldd in
glibc-utils-2.2.5-alt6