From nobody@FreeBSD.org  Wed Sep 10 17:44:37 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 37384106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 10 Sep 2008 17:44:37 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 234948FC21
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 10 Sep 2008 17:44:37 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m8AHia6U053644
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 10 Sep 2008 17:44:36 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m8AHiaQq053643;
	Wed, 10 Sep 2008 17:44:36 GMT
	(envelope-from nobody)
Message-Id: <200809101744.m8AHiaQq053643@www.freebsd.org>
Date: Wed, 10 Sep 2008 17:44:36 GMT
From: Dominic Fandrey <kamikaze@bsdforen.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ldd invokes linux yes
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         127276
>Category:       bin
>Synopsis:       [patch] ldd(1) invokes linux yes
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    markj
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 10 17:50:01 UTC 2008
>Closed-Date:    Tue Sep 03 23:22:54 UTC 2013
>Last-Modified:  Tue Sep 03 23:22:54 UTC 2013
>Originator:     Dominic Fandrey
>Release:        RELENG_7
>Organization:
private
>Environment:
FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug 29 23:22:22 CEST 2008     root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b  amd64
>Description:
When ldd is used on linux yes it invokes it instead of producing the usual output.

# pkg_info -W /compat/linux/usr/bin/yes
/compat/linux/usr/bin/yes was installed by package linux_base-f8-8_4
# sysctl compat.linux.osrelease
compat.linux.osrelease: 2.6.16

This behaviour breaks pkg_libchk from the sysutils/bsdadminscripts port.
>How-To-Repeat:
# ldd /compat/linux/usr/bin/yes
>Fix:


>Release-Note:
>Audit-Trail:

From: John Baldwin <jhb@FreeBSD.org>
To: freebsd-amd64@FreeBSD.org
Cc: Dominic Fandrey <kamikaze@bsdforen.de>, freebsd-gnats-submit@FreeBSD.org
Subject: Re: amd64/127276: ldd invokes linux yes
Date: Wed, 10 Sep 2008 16:10:13 -0400

 ldd is not going to work for Linux binaries.  The Linux ldd should be used for 
 Linux binaries.
 
 -- 
 John Baldwin

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: John Baldwin <jhb@freebsd.org>
Cc: freebsd-amd64@freebsd.org, freebsd-gnats-submit@freebsd.org
Subject: Re: amd64/127276: ldd invokes linux yes
Date: Thu, 11 Sep 2008 07:01:09 +0200

 I don't need it to work, I just need it not to invoke linux binaries. I'm
 using ldd in a script and by ldd not returning 0 the script should know that
 it hasn't encountered a valid binary. Instead ldd opens a linux binary like
 yes and the script spills out ys (yes) or waits for input from stdin
 (md5sum). I'm pretty certain ldd is in no way meant to invoke programs.

From: Rui Paulo <rpaulo@FreeBSD.org>
To: Dominic Fandrey <kamikaze@bsdforen.de>
Cc: John Baldwin <jhb@freebsd.org>, freebsd-gnats-submit@freebsd.org,
	freebsd-amd64@freebsd.org
Subject: Re: amd64/127276: ldd invokes linux yes
Date: Thu, 11 Sep 2008 13:10:58 +0100

 I chatted briefly with John about this. The way our ldd works is by
 setting the environment variable TRACE_LOADED_OBJECTS and after some
 dlopen() magic it exec()'s the binary. FreeBSD rtld detects the environmental
 variable, prints the list of shared objects and quits.
 
 Linux rtld doesn't work this way, so FreeBSD ldd on a Linux binary will
 just run the Linux binary (Linux rtld will ignore the rest).
 
 Also, ldd wil return 1 on static binaries. Your best bet is to use
 file(1) to detect FreeBSD binaries. Something like `file $binary | grep
 FreeBSD-style` does the trick.
 
 Regards,
 -- 
 Rui Paulo

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Rui Paulo <rpaulo@FreeBSD.org>
Cc: John Baldwin <jhb@freebsd.org>, freebsd-gnats-submit@freebsd.org, 
 freebsd-amd64@freebsd.org
Subject: Re: amd64/127276: ldd invokes linux yes
Date: Thu, 11 Sep 2008 18:37:23 +0200

 Ok, thanks. I have already created a workaround with readelf, but I'd still
 consider this a bug in ldd. Shouldn't it check the elf brand if it only
 works for a single one?
 
 Regards

From: John Baldwin <jhb@freebsd.org>
To: Dominic Fandrey <kamikaze@bsdforen.de>
Cc: freebsd-amd64@freebsd.org, freebsd-gnats-submit@freebsd.org
Subject: Re: amd64/127276: ldd invokes linux yes
Date: Thu, 11 Sep 2008 10:38:32 -0400

 As Rui indicated, ldd always execs binaries.  It just sets environment 
 variables that the FreeBSD runtime linker checks for.  If the runtime linker 
 sees them, it will modify it's behavior.  You can achieve the same thing 
 using env:
 
 % ldd /bin/ls
 /bin/ls:
         libutil.so.7 => /lib/libutil.so.7 (0x2808b000)
         libncurses.so.7 => /lib/libncurses.so.7 (0x28099000)
         libc.so.7 => /lib/libc.so.7 (0x280d8000)
 % env LD_TRACE_LOADED_OBJECTS=yes /bin/ls
         libutil.so.7 => /lib/libutil.so.7 (0x2808b000)
         libncurses.so.7 => /lib/libncurses.so.7 (0x28099000)
         libc.so.7 => /lib/libc.so.7 (0x280d8000)
  
 All the "ldd" printfs, etc. are actually from the runtime linker, not ldd 
 itself.  The Linux runtime linker doesn't modify it's behavior for 
 LD_TRACE_LOADED_OBJECTS, so Linux apps just run normally when invoked by ldd.
 
 -- 
 John Baldwin

From: linimon@lonesome.com (Mark Linimon)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: amd64/127276: ldd invokes linux yes
Date: Thu, 11 Sep 2008 18:29:24 -0500

 ----- Forwarded message from John Baldwin <jhb@freebsd.org> -----
 
 FreeBSD binaries from various releases have been branded in different ways.  I 
 would consider it more of a user error to run ldd on a Linux binary. :)  You 
 could maybe add a "IMPLEMENTATION NOTES" section to the manpage that explains 
 how it works and why it will execute any binary using a different runtime 
 linker.
 
 -- 
 John Baldwin
 
 ----- End forwarded message -----
State-Changed-From-To: open->suspended 
State-Changed-By: linimon 
State-Changed-When: Tue Sep 16 02:55:49 UTC 2008 
State-Changed-Why:  
As noted in the feedback trail, the fix is not as obvious as it first 
might appear.  Mark this as 'suspended' for now to note that although 
we understand the problem, it is going to need more research. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=127276 

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: bug-followup@FreeBSD.org, kamikaze@bsdforen.de
Cc:  
Subject: Re: amd64/127276: ldd(1) invokes linux yes
Date: Fri, 03 Jul 2009 09:22:37 +0200

 How about documenting this behaviour in the manual page and
 closing this bug? I'm willing to write a patch if someone
 thinks this would be an acceptable solution.

From: Shuichi KITAGUCHI <ki@hh.iij4u.or.jp>
To: bug-followup@FreeBSD.org, kamikaze@bsdforen.de
Cc:  
Subject: Re: amd64/127276: ldd invokes linux yes
Date: Tue, 04 May 2010 12:21:45 +0900 (JST)

 ----Next_Part(Tue_May_04_12_21_45_2010_795)--
 Content-Type: Text/Plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 Hello,
 
 I investigate this problem today and found that Linux's ld.so
 accepts "LD_TRACE_LOADED_OBJECTS".
 
 % env LD_TRACE_LOADED_OBJECTS=yes /compat/linux/bin/ls
         librt.so.1 => /lib/librt.so.1 (0x28087000)
         libselinux.so.1 => /lib/libselinux.so.1 (0x28092000)
         libcap.so.2 => /lib/libcap.so.2 (0x280af000)
         libacl.so.1 => /lib/libacl.so.1 (0x280b4000)
         libc.so.6 => /lib/libc.so.6 (0x280bc000)
         libpthread.so.0 => /lib/libpthread.so.0 (0x28234000)
         /lib/ld-linux.so.2 (0x28063000)
         libdl.so.2 => /lib/libdl.so.2 (0x2824e000)
         libattr.so.1 => /lib/libattr.so.1 (0x28254000)
 
 I think environment variable "LD_32_TRACE_LOADED_OBJECTS" is
 FreeBSD specific, and "LD_TRACE_LOADED_OBJECTS" should be passed
 to other binaries.
 
 Attached patch is reasonable?
 
 
 --
 Shuichi KITAGUCHI // kit@ysnb.net / ki@hh.iij4u.or.jp
 
 ----Next_Part(Tue_May_04_12_21_45_2010_795)--
 Content-Type: Text/X-Patch; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline; filename="ldd.c.patch"
 
 --- ldd.c.old	2009-09-19 21:45:17.000000000 +0900
 +++ ldd.c	2010-05-04 11:48:42.000000000 +0900
 @@ -65,7 +65,7 @@
  #endif
  
  static int	is_executable(const char *fname, int fd, int *is_shlib,
 -		    int *type);
 +			      int *osabi, int *type);
  static void	usage(void);
  
  #define	TYPE_UNKNOWN	0
 @@ -177,14 +177,14 @@
  
  	rval = 0;
  	for (; argc > 0; argc--, argv++) {
 -		int fd, status, is_shlib, rv, type;
 +		int fd, status, is_shlib, rv, type, osabi;
  
  		if ((fd = open(*argv, O_RDONLY, 0)) < 0) {
  			warn("%s", *argv);
  			rval |= 1;
  			continue;
  		}
 -		rv = is_executable(*argv, fd, &is_shlib, &type);
 +		rv = is_executable(*argv, fd, &is_shlib, &osabi, &type);
  		close(fd);
  		if (rv == 0) {
  			rval |= 1;
 @@ -197,6 +197,8 @@
  			break;
  #if __ELF_WORD_SIZE > 32 && defined(ELF32_SUPPORTED)
  		case TYPE_ELF32:
 +			if (osabi != ELFOSABI_FREEBSD)
 +				break;
  			rval |= execldd32(*argv, fmt1, fmt2, aflag, vflag);
  			continue;
  #endif
 @@ -267,7 +269,7 @@
  }
  
  static int
 -is_executable(const char *fname, int fd, int *is_shlib, int *type)
 +is_executable(const char *fname, int fd, int *is_shlib, int *osabi, int *type)
  {
  	union {
  		struct exec aout;
 @@ -300,6 +302,8 @@
  		return (1);
  	}
  
 +	*osabi = hdr.elf.e_ident[EI_OSABI];
 +
  #if __ELF_WORD_SIZE > 32 && defined(ELF32_SUPPORTED)
  	if ((size_t)n >= sizeof(hdr.elf32) && IS_ELF(hdr.elf32) &&
  	    hdr.elf32.e_ident[EI_CLASS] == ELFCLASS32) {
 
 ----Next_Part(Tue_May_04_12_21_45_2010_795)----
State-Changed-From-To: suspended->open 
State-Changed-By: arundel 
State-Changed-When: Mon Aug 23 22:03:43 UTC 2010 
State-Changed-Why:  
Back to open, because a patch has been submitted. 


Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs 
Responsible-Changed-By: arundel 
Responsible-Changed-When: Mon Aug 23 22:03:43 UTC 2010 
Responsible-Changed-Why:  
This issue doesn't seem to be amd64 specific. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=127276 

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: bug-followup@FreeBSD.org, kamikaze@bsdforen.de
Cc:  
Subject: Re: bin/127276: [patch] ldd(1) invokes linux yes
Date: Thu, 13 Jan 2011 11:44:06 +0100

 I tested the patch, prior to the test:
 
 > ldd /compat/linux/usr/bin/yes
 y
 y
 y
 y
 y
 y
 ...
 
 After I applied the patch:
 > ldd /compat/linux/usr/bin/yes
 /compat/linux/usr/bin/yes:
 	libc.so.6 => /lib/libc.so.6 (0x28075000)
 	/lib/ld-linux.so.2 (0x2804f000)
 
 Apparently it returns libraries from the /compat/linux perspective.
 
 > ldd /compat/linux/lib/ld-linux.so.2
 ldd: /compat/linux/lib/ld-linux.so.2: not a FreeBSD ELF shared object
 
 The behaviour caused by the patch is comprehensible and a vast
 improvement over the old behaviour in my opinion, so I'm all for
 it.
 
 At some point the manual page of ldd should be updated to describe
 the new behaviour. If the patch is committed, I volunteer to make
 the changes.
 
 Because the patch was mangled by Gnats, I resubmit it here. I did
 not make any changes apart from the header to trigger the usual
 patch detection magic.
 
 Regards
 
 diff -u ldd.c.old ldd.c
 --- ldd.c.old	2009-09-19 21:45:17.000000000 +0900
 +++ ldd.c	2010-05-04 11:48:42.000000000 +0900
 @@ -65,7 +65,7 @@
  #endif
  
  static int	is_executable(const char *fname, int fd, int *is_shlib,
 -		    int *type);
 +			      int *osabi, int *type);
  static void	usage(void);
  
  #define	TYPE_UNKNOWN	0
 @@ -177,14 +177,14 @@
  
  	rval = 0;
  	for (; argc > 0; argc--, argv++) {
 -		int fd, status, is_shlib, rv, type;
 +		int fd, status, is_shlib, rv, type, osabi;
  
  		if ((fd = open(*argv, O_RDONLY, 0)) < 0) {
  			warn("%s", *argv);
  			rval |= 1;
  			continue;
  		}
 -		rv = is_executable(*argv, fd, &is_shlib, &type);
 +		rv = is_executable(*argv, fd, &is_shlib, &osabi, &type);
  		close(fd);
  		if (rv == 0) {
  			rval |= 1;
 @@ -197,6 +197,8 @@
  			break;
  #if __ELF_WORD_SIZE > 32 && defined(ELF32_SUPPORTED)
  		case TYPE_ELF32:
 +			if (osabi != ELFOSABI_FREEBSD)
 +				break;
  			rval |= execldd32(*argv, fmt1, fmt2, aflag, vflag);
  			continue;
  #endif
 @@ -267,7 +269,7 @@
  }
  
  static int
 -is_executable(const char *fname, int fd, int *is_shlib, int *type)
 +is_executable(const char *fname, int fd, int *is_shlib, int *osabi, int *type)
  {
  	union {
  		struct exec aout;
 @@ -300,6 +302,8 @@
  		return (1);
  	}
  
 +	*osabi = hdr.elf.e_ident[EI_OSABI];
 +
  #if __ELF_WORD_SIZE > 32 && defined(ELF32_SUPPORTED)
  	if ((size_t)n >= sizeof(hdr.elf32) && IS_ELF(hdr.elf32) &&
  	    hdr.elf32.e_ident[EI_CLASS] == ELFCLASS32) {

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/127276: commit references a PR
Date: Wed,  7 Aug 2013 00:28:30 +0000 (UTC)

 Author: markj
 Date: Wed Aug  7 00:28:17 2013
 New Revision: 254018
 URL: http://svnweb.freebsd.org/changeset/base/254018
 
 Log:
   Pass variables prefixed with both LD_ and LD_32_ to the run-time linker.
   This prevents unintentional execution of programs when running ldd(1) on
   32-bit Linux binaries.
   
   PR:		175339, 127276
   Suggested by:	kib, rstone
   Reviewed by:	kib
   MFC after:	2 weeks
 
 Modified:
   head/usr.bin/ldd/ldd.c
 
 Modified: head/usr.bin/ldd/ldd.c
 ==============================================================================
 --- head/usr.bin/ldd/ldd.c	Wed Aug  7 00:20:30 2013	(r254017)
 +++ head/usr.bin/ldd/ldd.c	Wed Aug  7 00:28:17 2013	(r254018)
 @@ -49,12 +49,6 @@ __FBSDID("$FreeBSD$");
  
  #include "extern.h"
  
 -#ifdef COMPAT_32BIT
 -#define	LD_	"LD_32_"
 -#else
 -#define	LD_	"LD_"
 -#endif
 -
  /*
   * 32-bit ELF data structures can only be used if the system header[s] declare
   * them.  There is no official macro for determining whether they are declared,
 @@ -64,6 +58,16 @@ __FBSDID("$FreeBSD$");
  #define	ELF32_SUPPORTED
  #endif
  
 +#define	LDD_SETENV(name, value, overwrite) do {		\
 +	setenv("LD_" name, value, overwrite);		\
 +	setenv("LD_32_" name, value, overwrite);	\
 +} while (0)
 +
 +#define	LDD_UNSETENV(name) do {		\
 +	unsetenv("LD_" name);		\
 +	unsetenv("LD_32_" name);	\
 +} while (0)
 +
  static int	is_executable(const char *fname, int fd, int *is_shlib,
  		    int *type);
  static void	usage(void);
 @@ -82,7 +86,7 @@ execldd32(char *file, char *fmt1, char *
  	char *argv[8];
  	int i, rval, status;
  
 -	unsetenv(LD_ "TRACE_LOADED_OBJECTS");
 +	LDD_UNSETENV("TRACE_LOADED_OBJECTS");
  	rval = 0;
  	i = 0;
  	argv[i++] = strdup(_PATH_LDD32);
 @@ -121,7 +125,7 @@ execldd32(char *file, char *fmt1, char *
  	}
  	while (i--)
  		free(argv[i]);
 -	setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1);
 +	LDD_SETENV("TRACE_LOADED_OBJECTS", "yes", 1);
  	return (rval);
  }
  #endif
 @@ -210,15 +214,15 @@ main(int argc, char *argv[])
  		}
  
  		/* ld.so magic */
 -		setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1);
 +		LDD_SETENV("TRACE_LOADED_OBJECTS", "yes", 1);
  		if (fmt1 != NULL)
 -			setenv(LD_ "TRACE_LOADED_OBJECTS_FMT1", fmt1, 1);
 +			LDD_SETENV("TRACE_LOADED_OBJECTS_FMT1", fmt1, 1);
  		if (fmt2 != NULL)
 -			setenv(LD_ "TRACE_LOADED_OBJECTS_FMT2", fmt2, 1);
 +			LDD_SETENV("TRACE_LOADED_OBJECTS_FMT2", fmt2, 1);
  
 -		setenv(LD_ "TRACE_LOADED_OBJECTS_PROGNAME", *argv, 1);
 +		LDD_SETENV("TRACE_LOADED_OBJECTS_PROGNAME", *argv, 1);
  		if (aflag)
 -			setenv(LD_ "TRACE_LOADED_OBJECTS_ALL", "1", 1);
 +			LDD_SETENV("TRACE_LOADED_OBJECTS_ALL", "1", 1);
  		else if (fmt1 == NULL && fmt2 == NULL)
  			/* Default formats */
  			printf("%s:\n", *argv);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->patched 
State-Changed-By: markj 
State-Changed-When: Wed Aug 7 00:39:53 UTC 2013 
State-Changed-Why:  
This has been fixed with r254018 by passing both LD_TRACE_LOADED_OBJECTS 
and LD_32_TRACE_LOADED_OBJECTS to the runtime linker. 


Responsible-Changed-From-To: freebsd-bugs->markj 
Responsible-Changed-By: markj 
Responsible-Changed-When: Wed Aug 7 00:39:53 UTC 2013 
Responsible-Changed-Why:  
This has been fixed with r254018 by passing both LD_TRACE_LOADED_OBJECTS 
and LD_32_TRACE_LOADED_OBJECTS to the runtime linker. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=127276 
State-Changed-From-To: patched->closed 
State-Changed-By: markj 
State-Changed-When: Tue Sep 3 23:22:53 UTC 2013 
State-Changed-Why:  
A fix has been merged to stable/8 and stable/9. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=127276 
>Unformatted:
