[OpenWrt-Devel] MIPS stack security and other problems

[Hauke Mehrtens]

On 1/19/19 2:56 PM, Dave Taht wrote:
> 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:
>>>>
>>>> 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
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel