[OpenWrt-Devel] MIPS stack security and other problems
dave at taht.net
Sat Jan 19 08:56:45 EST 2019
Hauke Mehrtens <hauke at hauke-m.de> 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:
>>> 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"
>>  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:" .
>> You can build a device which scores 100% in the one and 0% in the other,
>> there is no overlap. ;-)
> 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
> 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
> 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.
> 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.
> 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:
> 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?
> 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.
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel