OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Critical
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Maxim Mikityanskiy - 07.11.2018

FS#1938 - CONFIG_PKG_ASLR_PIE and CONFIG_USE_MKLIBS are incompatible

I’m building OpenWrt trunk (commit dceee8cc09a54f96dee82a6e95e3e77a6dd7ac13) for Netgear R7800 (though I think, device doesn’t matter here).

It turns out that if both CONFIG_PKG_ASLR_PIE and CONFIG_USE_MKLIBS are turned on, the system renders unusable. In my case, when building with GCC 7, dropbear doesn’t start, and when building with GCC 8, the system doesn’t boot, and the status LED is off.

The culprit is this line: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/rootfs.mk;h=76425c017a8b33340dbcc41cecaf1241352c7dbc;hb=HEAD#l7

      # first find all programs and add them to the mklibs list
      find $(STAGING_DIR_ROOT) -type f -perm /100 -exec \
              file -r -N -F '' {} + | \
              awk ' /executable.*dynamically/ { print $$1 }' > $(TMP_DIR)/mklibs-progs

It should generate the list of executables for mklibs, however, with PIE turned on, most of the executables don’t get into that list. In my config, only fw_printenv gets into the mklibs-progs list. And, because some executables are not on the list, the symbols they need may be stripped off the libraries, rendering these executables unusable.

The reason is that the file command detects PIE executables as shared objects, not as executables. Compare:

  With ASLR off:
  bin/busybox ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, with debug_info, not stripped
  With ASLR on:
  bin/busybox ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, with debug_info, not stripped
  This one single executable displays the same, independently of ASLR state:
  usr/sbin/fw_printenv ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, stripped

If CONFIG_PKG_ASLR_PIE=n, all executables are detected properly and get into the mklibs-progs list.

A more proper way should be found to detect executables, as the current one skips PIE executables completely and makes the system unusable, because some of the PIE executables can’t start due to missing symbols in libraries.

I’ve chosen the critical severity, because the system doesn’t work if I set those two config options to y, and this combination isn’t something unusual, because many people would like both increased security and smaller size of the firmware.

Jose Olivera commented on 15.05.2019 12:20

For anyone that stumbles upon this with whatever search engine you're using:

One way to fix this without changing the script is by having the host update the 'file' program to version 5.36. More info here: https://stackoverflow.com/a/55704865

The new output will look like:

bin/busybox ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, with debug_info, not stripped

On Ubuntu 18.04 LTS (May 2019) this can be done by downloading the source tar from ftp://ftp.astron.com/pub/file/file-5.36.tar.gz

Then extracting it and running this in the terminal (tested only on Ubuntu 18.04 LTS):

cd file-5.36
./configure --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu/
make
make check
sudo make install

Running:

file -v 

should now show:

file-5.36
magic file from /usr/share/misc/magic 

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing