On 1/19/19 2:56 PM, Dave Taht wrote: > Hauke Mehrtens <[email protected]> writes: > >> 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 might be a useful tool to make more obvious security issues to > future builders of openwrt.
Yes it is really helpful to check the compiler security settings used to compile a binary, it would be nice if someone could check a bigger build of OpenWrt if we use the correct compiler settings everywhere. >> ASLR increases the image size by about 2.8%: >> Without ASLR: 5.386.965 bytes >> With ASLR: 5.540.565 bytes > > To me this seems worth it on the larger flash sizes. The problem is that this would even be a toolchain option, but we can probably activate it at least for all modern arm CPUs and x86, they all have bigger flashes as far as I know. >> 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. > > Hmm. Does gcc still actually contain executable code in this segment? When I compile this for x86 NX is set, I do not know why it is not set for MIPS, I would like to investigate this further. >> Some binaries do not use a stack canary, I assume that these binaries >> 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 [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
