Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Vincent Lefevre]

Control: tags -1 - moreinfo

On 2016-01-22 02:36:44 +, Ben Hutchings wrote:
> Do you think there is still a bug to fix here, or can this be closed?

Well, the core dump problem has been fixed in the kernel. Now, I think
that if there is an issue, it is in ldd. It is still not clear whether
/libx32 is free for any use if x32 related packages are not installed.
About /lib, FHS 2.3 says "[...] on systems which support more
than one binary format requiring separate libraries" but I don't think
that one can say that Debian/amd64 supports the x32 binary format. And
about the requirements, "If one or more of these directories exist"
is rather unclear: does "these directories" mean any directory name
matching /lib* or any directory associated with a supported binary
format?

If /libx32 is free for any use, then there may be a security issue
because /libx32/ld-linux-x32.so.2 gets executed by ldd.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Ben Hutchings]

Control: tag -1 moreinfo

On Sun, 25 Aug 2013 00:37:53 +0200 Vincent Lefevre 
wrote:
> Package: initramfs-tools
> Version: 0.113
> Severity: important
> Tags: security
> 
> I've noticed that when running update-initramfs, a core dump was
> generated in the current directory, which is in itself a first bug.
> 
> After looking at this problem with strace, I saw that this came from:
> 
>   /usr/bin/ldd /lib/firmware/cis/PCMLM28.cis
[...]

In version 0.121~rc1 the copy_exec function has been split up and we
should now only be running ldd when copying executables.

These executables are being copied and used in the initramfs so they
are already trusted.  So I don't think there's any security reason to
move away from using ldd.

Do you think there is still a bug to fix here, or can this be closed?

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got


signature.asc
Description: This is a digitally signed message part

Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Ben Hutchings]

Control: retitle -1 initramfs-tools: Use static check for library dependencies 
instead of ldd
Control: severity -1 normal

On Sun, 2013-08-25 at 14:38 +0200, Vincent Lefevre wrote:
 On 2013-08-25 09:53:07 +0100, Ben Hutchings wrote:
  No, this has a defined meaning in FHS:
  
  http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL
 
 OK (both the French and English versions of the Wikipedia article
 didn't mention these directories... I've updated them now).
 
 I still think that ldd should be avoided, though.

The core dump seems to have been due to a kernel bug, fixed in
3.14.15-1:

  * [amd64] Reject x32 executables if x32 ABI not supported

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Debian Bug Tracking System]

Processing control commands:

 retitle -1 initramfs-tools: Use static check for library dependencies instead 
 of ldd
Bug #720735 [initramfs-tools] initramfs-tools: mkinitramfs uses ldd, which is 
insecure and generates core dumps
Changed Bug title to 'initramfs-tools: Use static check for library 
dependencies instead of ldd' from 'initramfs-tools: mkinitramfs uses ldd, which 
is insecure and generates core dumps'
 severity -1 normal
Bug #720735 [initramfs-tools] initramfs-tools: Use static check for library 
dependencies instead of ldd
Severity set to 'normal' from 'important'

-- 
720735: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720735
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b720735.14120094225545.transcr...@bugs.debian.org

Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Ben Hutchings]

On Sun, 2013-08-25 at 02:13 +0200, Vincent Lefevre wrote:
 On 2013-08-25 00:47:36 +0100, Ben Hutchings wrote:
  What?  It belongs to glibc;
  
  $ dpkg -S /libx32
  libc6-x32: /libx32
 
 If libc6-x32 is not installed, this directory doesn't belong to
 anything!
 
 $ dpkg -S /libx32
 dpkg-query: no path found matching pattern /libx32
 
 So, there's nothing wrong in mounting it via NFS, and the system
 mustn't use it!

No, this has a defined meaning in FHS:

http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


signature.asc
Description: This is a digitally signed message part

Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Vincent Lefevre]

On 2013-08-25 09:53:07 +0100, Ben Hutchings wrote:
 No, this has a defined meaning in FHS:
 
 http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL

OK (both the French and English versions of the Wikipedia article
didn't mention these directories... I've updated them now).

I still think that ldd should be avoided, though.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130825123836.gb7...@xvii.vinc17.org

Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Vincent Lefevre]

Package: initramfs-tools
Version: 0.113
Severity: important
Tags: security

I've noticed that when running update-initramfs, a core dump was
generated in the current directory, which is in itself a first bug.

After looking at this problem with strace, I saw that this came from:

  /usr/bin/ldd /lib/firmware/cis/PCMLM28.cis

apparently via mkinitramfs. The strace output shows:

23190 execve(/libx32/ld-linux-x32.so.2, [/libx32/ld-linux-x32.so.2], [/* 
115 vars */]) = 0
23190 syscall_1073741836(0, 0, 0x400c, 0xbfebfbff, 0x37f, 0x64, 0x1000, 
0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 
0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 
0x1000, 0x1000, 0x1000, 0x1000, 0x1000) = -1 (errno 38)
23190 syscall_1073742340(0x2, 0xfffbaa70, 0x1, 0xbfebfbff, 0xf77b0a3e, 
0xf776d8cc, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 
0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 
0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 
0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 
0xf776ef7d, 0xf776ef7d, 0xf776ef7d) = -1 (errno 38)
23190 syscall_1073742055(0x7f, 0x403c, 0x7f, 0xbfebfbff, 0x40e7, 
0xf776d8cc, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 
0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7) = -1 (errno 38)
23190 syscall_1073741884(0x7f, 0x403c, 0x7f, 0xbfebfbff, 0x40e7, 
0xf776d8cc, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 
0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7) = -1 (errno 38)
23190 --- SIGSEGV (Segmentation fault) @ 0 (0) ---

I wonder whether it may be a security bug. /libx32 is not necessarily
a standard directory, and could for instance be NFS mounted, have
write-access to more people, or whatever; only some particular
packages use this directory, but if they are not installed, I assume
that the admin is free to do whatever he wants with it, and tools
like mkinitramfs are not supposed to run anything from it.

And this is not a bug in ldd, as the ldd man page says:

  Security
In the usual  case,  ldd  invokes  the  standard  dynamic  linker  (see
ld.so(8))  with the LD_TRACE_LOADED_OBJECTS environment variable set to
1, which causes the linker to display  the  library  dependencies.   Be
aware,  however,  that  in some circumstances, some versions of ldd may
attempt to obtain the dependency information by directly executing  the
program.  Thus, you should never employ ldd on an untrusted executable,
since this may result in the execution  of  arbitrary  code.   A  safer
alternative when dealing with untrusted executables is:

$ objdump -p /path/to/program | grep NEEDED

For this reason, I think that the use of ldd should be dropped
entirely from initramfs-tools. It might ease privilege escalation
if there's another security bug on the system.

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 13M 2013-08-24 23:54:26 /boot/initrd.img-3.10-1-amd64
-rw-r--r-- 1 root root 13M 2013-08-24 23:35:31 /boot/initrd.img-3.10-2-amd64
-rw-r--r-- 1 root root 13M 2013-08-24 23:36:02 /boot/initrd.img-3.8-1-amd64
-rw-r--r-- 1 root root 13M 2013-08-24 23:35:55 /boot/initrd.img-3.8-2-amd64
-rw-r--r-- 1 root root 13M 2013-08-24 23:35:46 /boot/initrd.img-3.9-1-amd64
-- /proc/cmdline
root=/dev/mapper/xvii-root ro quiet reboot=pci

-- resume
RESUME=/dev/mapper/xvii-swap_1
-- /proc/filesystems
ext3
fuseblk
ext2

-- lsmod
Module  Size  Used by
cuse   12971  3 
cpufreq_powersave  12454  0 
cpufreq_stats  12866  0 
cpufreq_userspace  12576  0 
cpufreq_conservative14184  0 
xt_multiport   12548  2 
iptable_filter 12536  1 
ip_tables  22036  1 iptable_filter
x_tables   19041  3 ip_tables,xt_multiport,iptable_filter
parport_pc 22409  0 
ppdev  12763  0 
lp 13025  0 
parport31901  3 lp,ppdev,parport_pc
bnep   17535  2 
rfcomm 33471  0 
bluetooth 170002  10 bnep,rfcomm
crc16  12343  1 bluetooth
binfmt_misc12925  1 
uinput 17439  1 
nfsd  192007  2 
auth_rpcgss39085  1 nfsd
oid_registry   12419  1 auth_rpcgss
nfs_acl12511  1 nfsd
nfs   110304  0 
lockd  59673  2 nfs,nfsd
dns_resolver   12641  1 nfs
fscache37551  1 nfs
sunrpc164583  6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
ext2   59601  1 
firewire_sbp2  17956  0 
loop   22869  0 
fuse   67503  2 cuse
uvcvideo   66788  0 
arc4   12543  2 
iwldvm111931  0 
coretemp   12898  0 

Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Ben Hutchings]

Control: tag -1 - security

On Sun, 2013-08-25 at 00:37 +0200, Vincent Lefevre wrote:
 Package: initramfs-tools
 Version: 0.113
 Severity: important
 Tags: security
 
 I've noticed that when running update-initramfs, a core dump was
 generated in the current directory, which is in itself a first bug.
 
 After looking at this problem with strace, I saw that this came from:
 
   /usr/bin/ldd /lib/firmware/cis/PCMLM28.cis
 
 apparently via mkinitramfs. The strace output shows:
 
 23190 execve(/libx32/ld-linux-x32.so.2, [/libx32/ld-linux-x32.so.2], [/* 
 115 vars */]) = 0
 23190 syscall_1073741836(0, 0, 0x400c, 0xbfebfbff, 0x37f, 0x64, 0x1000, 
 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 
 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 
 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000) = -1 (errno 38)
 23190 syscall_1073742340(0x2, 0xfffbaa70, 0x1, 0xbfebfbff, 0xf77b0a3e, 
 0xf776d8cc, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 
 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 
 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 
 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 0xf776ef7d, 
 0xf776ef7d, 0xf776ef7d, 0xf776ef7d) = -1 (errno 38)
 23190 syscall_1073742055(0x7f, 0x403c, 0x7f, 0xbfebfbff, 0x40e7, 
 0xf776d8cc, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 
 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7) = -1 (errno 
 38)
 23190 syscall_1073741884(0x7f, 0x403c, 0x7f, 0xbfebfbff, 0x40e7, 
 0xf776d8cc, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 
 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7, 0x7) = -1 (errno 
 38)
 23190 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
 
 I wonder whether it may be a security bug. /libx32 is not necessarily
 a standard directory, and could for instance be NFS mounted,
[...]

What?  It belongs to glibc;

$ dpkg -S /libx32
libc6-x32: /libx32

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Debian Bug Tracking System]

Processing control commands:

 tag -1 - security
Bug #720735 [initramfs-tools] initramfs-tools: mkinitramfs uses ldd, which is 
insecure and generates core dumps
Removed tag(s) security.

-- 
720735: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720735
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.b720735.13773880688270.transcr...@bugs.debian.org

Bug#720735: initramfs-tools: mkinitramfs uses ldd, which is insecure and generates core dumps

[Vincent Lefevre]

On 2013-08-25 00:47:36 +0100, Ben Hutchings wrote:
 What?  It belongs to glibc;
 
 $ dpkg -S /libx32
 libc6-x32: /libx32

If libc6-x32 is not installed, this directory doesn't belong to
anything!

$ dpkg -S /libx32
dpkg-query: no path found matching pattern /libx32

So, there's nothing wrong in mounting it via NFS, and the system
mustn't use it!

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130825001337.ga7...@xvii.vinc17.org