On Tue, Jan 22, 2019 at 2:34 PM Hauke Mehrtens <ha...@hauke-m.de> wrote:
>
> On 1/19/19 2:56 PM, Dave Taht wrote:
> > Hauke Mehrtens <ha...@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.
There's still a fair amount of work to be done there.
One of my annoyances is that checksec.sh requires bash and a few other
utilities. It's useful to run on the router as some binaries are
symlinks to local /bin locations.
binutils for example, does not have any OpenWrt settings. It also
seems to be relatively unmaintained (old version).:
RELRO STACK CANARY NX PIE RPATH
RUNPATH Symbols FORTIFY Fortified Fortifiable
FILE
Full RELRO No canary found NX enabled No PIE No
RPATH No RUNPATH No Symbols No 0 0 /bin/strings
PKG_ASLR_PIE is enabled btw.
My current list of binaries with such issues are:
/bin/strings
/sbin/askfirst
/usr/bin/bon_csv2html
/usr/bin/bonnie++
/usr/bin/buddy-ng
/usr/bin/dbus-uuidgen
/usr/bin/ldd
/usr/bin/resolveip
/usr/bin/file
/usr/sbin/fw_printenv
/lib/libatomic.so.
/lib/libsetlbf.so
/usr/lib/libbz2.so.1.0
/usr/lib/libcmdline-contexts-samba4.so
/usr/lib/libcrypto.so.1.0.0 - NX...
/usr/lib/libgthread-2.0.so
/usr/lib/libnatpmp.so.1 - relro
/usr/lib/libpanelw.so - relro
/usr/lib/libstdc++.so.6 - relro
/usr/lib/libopcodes-2.27.so
/usr/lib/libmagic.so.1
on an mvebu device (Turris Omnia)
>
> >> 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.
I actually disagree with this. Some packages have a --with-pic
parameter in their configure script. I think packages should be fixed
on an individual basis. Not all packages need or require PIE
(/sbin/askfirst for example).
>
> >> 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@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
