On Mon, Dec 17, 2018 at 3:40 PM Dave Taht <[email protected]> wrote: > > John Crispin <[email protected]> writes: > > > On 17/12/2018 23:18, Dave Taht wrote: > >> Rosen Penev <[email protected]> writes: > >> > >>> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht <[email protected]> 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. > >>> As of kernel 4.14.88, I see the same problems. > >> Well, I see that the stack, at least, on kernel 4.4.92 on mips and > >> 4.14 on openwrt 18.06... > >> > >> is mapped rw only, with no execute bit. > >> > >> That doesn't mean the other other flaws discussed in the paper don't > >> exist, but at least current openwrt HEAD is using the right gcc version > >> to turn the right linkage on. Someone here with waaaay more expertise in > >> the compiler, here, should take a hard look at this and the paper. > >> > >> > >> root@lupin-jeff:~# cat /proc/self/maps > >> 00400000-0044b000 r-xp 00000000 1f:04 879 /bin/busybox > >> 0045b000-0045c000 rw-p 0004b000 1f:04 879 /bin/busybox > >> 77182000-771a4000 r-xp 00000000 1f:04 611 /lib/libgcc_s.so.1 > >> 771a4000-771a5000 rw-p 00012000 1f:04 611 /lib/libgcc_s.so.1 > >> 771a6000-77238000 r-xp 00000000 1f:04 653 /lib/libc.so > >> 77245000-77246000 r--p 00000000 00:00 0 [vvar] > >> 77246000-77247000 r-xp 00000000 00:00 0 [vdso] > >> 77247000-77249000 rw-p 00091000 1f:04 653 /lib/libc.so > >> 77249000-7724b000 rwxp 00000000 00:00 0 # is this the heap? > >> 7fe06000-7fe27000 rw-p 00000000 00:00 0 [stack] > >> > >> > >>>> _______________________________________________ > >>>> openwrt-devel mailing list > >>>> [email protected] > >>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > >> _______________________________________________ > >> openwrt-devel mailing list > >> [email protected] > >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > Dave, > > > > too lazy to read thd pdf, in a nutshell whats the issue and what do we > > need to do do to mitigate it ? > > From the paper: (It's the second comment regarding ALSR bypass via a > deterministic segment that concerns me most). They are claiming that the > emulation segment at > > 7ffff000-80000000 rwxp 00000000 00:00 0 > > is a bad idea, in the paper. Which openwrt has. > > > "Timeline Key: > (A) > 2001: Linux introduces FPU emulation in kernel 2.4.3.4. This puts code on the > stack and > executes it there requiring the stack be marked as readable, writable, and > executable. > (B) > 2016 July: a new page was introduced to execute branch delay slot > instructions. This > was introduced to remove the code being inserted and executed on the program > stack. > However, this fix introduced a new fixed location segment that can be used to > bypass > ASLR defenses. > 3 > (C) > 2016 August: a patch to make the stack and heap non-execute was introduced, > if a > PT_GNU_STACK was present. However, as noted in the patch none of the > toolchains > used to build executables created a PT_GNU_STACK and the stack would remain > executable until this was addressed in compiler toolchains. > 4 > In summary, Linux MIPS binaries have been easier to exploit by way of classic > stack overflow > attacks for over a decade, and continue to be so according to our examination > of toolchain > patches. Additionally, the fix that moved FPU emulation off the stack created > a separate DEP > and > > ASLR exposure. Even if patches were introduced today for both the kernel and > the > toolchains, the lag in adoption implies it could be years before Linux MIPS > devices can be > expected to have basic DEP and ASLR. > " > > Their proof of concept for exploiting this on mipsel is: > > include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <unistd.h> > > int main(void) { > // set a pointer to the vfpu emulation page address > void* p = (void *)0x7ffff000; > printf("%p\n", (void*)p); > // construct a function pointer from p > void (*func_ptr)(void) = p; > // 'jr $ra' mips32el instruction bytes > char code[] = {0x08, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x00, 0x00}; > // copy the instruction to the vfpu page > memcpy(p, code, 8); > // call the function pointer, this should then directly return back > (*func_ptr)(); > // print out the current maps of the process > char cmd[200]; > sprintf(cmd, "cat /proc/%d/maps", getpid()); > system(cmd); > return 0; > } I tested this. Output on current master:
root@OpenWrt:/tmp# ./a.out 0x7ffff000[ 1213.393861] do_page_fault(): sending SIGSEGV to a.out for invalid write access to 7ffff003 [ 1213.402945] epc = 555757ac in a.out[55575000+1000] [ 1213.407816] ra = 55575774 in a.out[55575000+1000] Segmentation fault > > > > > > John > > > > > > > > > > > > _______________________________________________ > > openwrt-devel mailing list > > [email protected] > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
