On Tue, Jan 1, 2019 at 9:44 AM Hauke Mehrtens <ha...@hauke-m.de> wrote: > > On 12/18/18 12:46 PM, Hauke Mehrtens wrote: > > On 12/17/18 1:54 AM, Dave Taht wrote: > >> > >> A pretty deep look at home MIPS and arm routers, and a surprising bug in > >> Linux/MIPS - by mudge and co: > >> > >> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html > >> > >> I have no idea if current openwrt, or what prior releases... are subject to > >> the problems they outline. > > > > In the second paper "Build Safety of Software in 28 Popular Home Router" > > [0] they checked the "security" of multiple popular devices, by checking > > if they activate ASLR, Non stack Exec, Relro and stack guards. The best > > device was the Linksys wrt32x and this is based on OpenWrt with not so > > many modifications. ;-) Just something like Samba downgrade to 3.0.37. > > The paper also wonders why the other Linksys devices like the wrt1900ac > > are much worse, but they probably do not use OpenWrt or a much older > > version. The GPL source code tar.gz of the Linksys wrt32x, begins with > > cloning from https://github.com/openwrt/openwrt.git > > > > > > It is also interesting how different this approve to security checking > > is to what the German BSI published in the "BSI TR-03148: Secure > > Broadband Router:" [1]. > > You can build a device which scores 100% in the one and 0% in the other, > > there is no overlap. ;-) > > > > Hauke > > > > > > [0]: > > https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf > > [1]: > > https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile&v=2 > > It looks like they ran checksec from > http://github.com/slimm609/checksec.sh on the root file system of the > devices and came up with these results. The numbers for the Linksys > wrt32x look very similar to current OpenWrt master, even for MIPS CPUs. > > I attached two outputs of checksec to this mail from the lantiq target > with a MIP24Kc CPU. One with master and the current default > configuration and one with master + activated ASLR configuration option. > > You can generate these yourself like this: > ../checksec.sh/checksec -d build_dir/target-mips_24kc_musl/root-lantiq/ This is not accurate for some of the busybox symlinks. Some of them are linked to "busybox", giving the proper result. Others to /bin/busybox which gives a result for the local machine. Maybe should be fixed. > > ASLR increases the image size by about 2.8%: > Without ASLR: 5.386.965 bytes > With ASLR: 5.540.565 bytes > > This is caused by increased user space binary size, see for example > busybox binary which is 7% bigger: > Without ASLR: 425.532 bytes > With ASLR: 457.336 bytes > > The fortified function count does not work with fortify-headers, but > only with glibc. With glibc some function calls are getting replaced > with calls to *_chk functions which are taking extra arguments, this is > done by some glibc header magic. For musl libc OpenWrt uses > fortify-headers which overwrites the original functions and inlined some > extra security checks into the calling application. The result should be > similar, so I assume that we have at least in most places similar > security for the glibc fortified functions. > I checked this by compiling an test application and checked the > assembler code, it contained some extra size checks. > > It looks like the detection does not work correctly for kernel modules. > > Currently RELRO is not activated for the following libraries: > root-lantiq/usr/lib/libbz2.so.1.0 > root-lantiq/usr/lib/libbz2.so.1.0.6 > root-lantiq/lib/libgcc_s.so.1 > this looks like a bug. > > For libgcc_s.so.1 also NX is disabled, which is not good. > > Some binaries do not use a stack canary, I assume that these binaries For ramips, it seems to be most binaries for me. Maybe something wrong with the build settings... > just do not have an array on the stack which could be exploited. The > compiler adds stack canaries only to functions which the compiler thinks > need it. > > ASLR is deactivated for root-lantiq/sbin/vdsl_cpe_control, because this > application does not link any more when ASLR is activated, this is a bug > in the package build system. > > Hauke > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel