Notes about ret2dir & PaX/Grsecurity

A paper "ret2dir: Rethinking Kernel Isolation" was released two years ago. It claimed that ret2dir can bypass modern mitigations including KERNEXEC/UDEREF/SMEP/SMAP/PXN. The author proposed a defensive solution is called eXclusive Page Frame Ownership (XPFO) in the paper. But it was not merge into the vanilla kernel back then. Some guys are trying to merge it again lately.

ret2dir might be a dramatic exploit technique can be useful to bypass mitigations. But it's not that "perfect" when it comes to PaX/Grsecurity. KERNEXEC does much more things than SMEP/PXN simply does not allow kernel code execution from userspace. I'd like to share a few things( truth?):

1, Even under kernel <= 3.9, the kernel patched with PaX/Grsecurity can prevent ret2dir attack without enabling any features. ret2dir only works if a few highly situational conditions satisfied. More detail? Plz ask those who did the tricks;-)

2, The fully ret2dir attack is based on PFN's information. The paper reveals two approaches to get the information:

1) simply read the info from /proc
2) physmap spraying

Unfortunately, all exploits we've found( public exploits & unpacked from malwares) are using the 1st approach in past 18 months. The evidence revealed that all other ret2dir exploits are copycats of these two ret2dir exploit examples( exploit writers aren't work hard?):

IMOHO, ROP is the only option left for ret2dir attack. Otherwise, creating a ROP chains is not that easy on PaX/Grsecurity kernel even without RAP, isn't it?

Debian GNU/Linux security checklist and hardening

The 1st time I met Debian GNU/Linux was about a decade ago when I was a college dude. Stupid college life was too boring back then;-) It was almost the same time I met Phrack ezine in my 1st time. Damn, time is running on...

Anyway, I'd like to share this article "Debian GNU/Linux security checklist and hardening" with you guys. H0pe you can find your peace in this pathetic era;-) Yeah..yeah..I just wanna say: "Phrack is not dead, PaX/Grsecurity is not dead, DNFWAH is not dead, 0ld sch00l is not dead, the Underground spirit is not dead.....If they were, that'd be on us!!!".

Simple linux rootkit on Debian with kernel 3.13

I've wasted a lot of time in 2013. I've always find some shity execuses, like "I'm fucking busy recently" to delay my hacking journey of kernel rootkit. This was supposed to be done a couple of months ago. Thank L0rd! I found a slot during Chinese new year vacation at my hometown. I begun the adventure of rootkit hacking. I've read a bunch of great Phrack papers from the old good hacking days. It's old but it'd help.

---------------------------------------------------------------
[Weakening the Linux Kernel, Phrack Magazine Volume 8, Issue 52
January 26, 1998, article 18 of 20]
http://www.phrack.org/issues.html?issue=52&id=18&mode=txt

[Advances in Kernel Hacking, Volume 0x0b, Issue 58, Phile #0x06 of
0x0e]
http://www.phrack.org/issues.html?issue=58&id=6&mode=txt

[Handling Interrupt Descriptor Table for fun and profit, Volume 0x0b,
Issue 59, Phile #0x04 of 0x12]
http://www.phrack.org/issues.html?issue=59&id=4&mode=txt

[Kernel Rootkit Experiences, Volume 0x0b, Issue 61, Phile 0x0e of
0x0f]
http://www.phrack.org/issues.html?issue=61&id=14&mode=txt

[Mistifying the debugger, Volume 0x0c, Issue 65, Phile #0x08 of
0x0f]
http://www.phrack.org/issues.html?issue=65&id=8&mode=txt

Especially thanks to THC's paper, which was released in 1999:
[Complete Linux Loadable Kernel Modules]
https://www.thc.org/papers/LKM_HACKING.html
---------------------------------------------------------------

I wrote a simple rootkit that can only hide a specific file. Just a
few old school steps could make its feature possible:

Firstly, we need to retrieve the system call table. But it's no longer
exported since 2.6. Fortunately, there's still a few system calls are
exported. sys_close() is one of them:
--------------------------------------
root@d6-test:/home/shawn# grep sys_close /boot/System.map-3.13.0
c10e0aa1 T sys_close
c140fdc4 R __ksymtab_sys_close
c141815c r __kcrctab_sys_close
c1420e33 r __kstrtab_sys_close
--------------------------------------

I used a brute force way to locate that system call. I learned it from
memset's blog:
https://memset.wordpress.com/2011/03/18/syscall-hijacking-dynamically-obtain-syscall-table-address-kernel-2-6-x-2/

Start mem addr would be 0xc0000000, then it would try it repeatly unti
it locate sys_close()'s addr.

Then, write protection bit in cr0 has to be shut down. WP bit is the
16th bit in cr0 register.

31  30  29  28          19  18  17  16  15         6  5  4  3  2  1  0
+----------------------------------------------------------------------+
|PG|CD |NW|-----------------|AM|---|WP|--------------|NE|ET|TS|EM|MP|PE|
+----------------------------------------------------------------------+

After we done above steps, we are able to hijack the system call we
want. Here I choose to hijack getdents64(). Why? Because all I wanna
do is hide a specific file from "ls". Let's see what "ls" would
usually do:
------------------------------------------
// begin.........
execve("/bin/ls", ["ls"], [/* 16 vars */]) = 0
brk(0)                                  = 0x8366000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7791000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=19346, ...}) = 0
.......................
.......................
.......................
// look, that's it
getdents64(3, /* 17 entries */, 32768)  = 544
getdents64(3, /* 0 entries */, 32768)   = 0
close(3)                                = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7790000
.......................
// then it would display them in the standard out(1)
write(1, "a.out  dirent.c  dirent.c~  insi"..., 107a.out  dirent.c  dirent.c~  insight-lab  libmnl  libnftables  linux-3.13  linux-3.13.tar  my_tmp  nftables
) = 107
.......................
------------------------------------------

The only struct from kernel we have to face is:
-------------------------------------------------------------------
           struct linux_dirent {
               unsigned long  d_ino;     /* Inode number */
               unsigned long  d_off;     /* Offset to next linux_dirent */
               unsigned short d_reclen;  /* Length of this linux_dirent */
               char           d_name[];  /* Filename (null-terminated) */
                                   /* length is actually (d_reclen - 2 -
                                      offsetof(struct linux_dirent, d_name) */
               /*
               char           pad;       // Zero padding byte
               char           d_type;    // File type (only since Linux 2.6.4;
                                         // offset is (d_reclen - 1))
               */

           }
-------------------------------------------------------------------

d_reclen is size of the current linux_dirent64, it does matters. Plz
read the fucking source code for any detail! Well, like in good old days, I drew an ascii big picture here.

May the L0rd's hacking spirit guide us!!!

How to compile the glibc-2.14.1 on Slackware 13.37

Note: This article is nothing about build a cross-compiler toolchains. The only reason I need to rebuild the glibc is for hacking the glibc itself, which mean to providing a debugging platform. If you need to build a cross-compiler toolchains( for Play Station III?) , go to openWRT community.

1, download the glibc-2.14.1.

2, Preparation before compiling:

root@sl13:/home/libs/2.14-build# mkdir -p /home/root_shawn/etc
root@sl13:/home/libs/2.14-build# cp /etc/ld.so.conf /home/root_shawn/etc/

3, Decompressing the source code and compiling:

root@sl13:/home/libs# tar jxvf glibc-2.14.1.tar.bz2
root@sl13:/home/libs/2.14-build# ../glibc-2.14.1/configure --prefix=/home/root_shawn --with-tls --enable-add-ons=nptl
root@sl13:/home/libs/2.14-build# make -j 2 && make install

4, Edit some config files:

add "export LIBRARY_PATH=/home/root_shawn/lib:/lib:/usr/lib" to the file /etc/profile

edit the file "/usr/lib/gcc/i486-slackware-linux/4.5.2/specs", and replace "/lib/ld-linux.so.2" with "/home/root_shawn/lib/ld-linux.so.2"

add "/home/root_shawn/lib" to the file /etc/ld.so.conf

root@sl13:/home/libs/2.14-build# ldconfig
root@sl13:/home/libs/2.14-build# source /etc/profile

5, Testing the current version of glibc

hello.c:
------------------------------------------------
#include <stdio.h>
#include <gnu/libc-version.h>
int main ()
{
        printf("%s\n", gnu_get_libc_version ());
        return 0;
}


root@sl13:~# gcc hello.c
root@sl13:~# ./a.out
2.14.1

Bingo, it's already upgrade!

6, Check the linking path

root@sl13:~# readelf -l a.out

Elf file type is EXEC (Executable file)
Entry point 0x8048340
There are 7 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
  INTERP         0x000114 0x08048114 0x08048114 0x00023 0x00023 R   0x1
      [Requesting program interpreter: /home/root_shawn/lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x00504 0x00504 R E 0x1000
  LOAD           0x000504 0x08049504 0x08049504 0x00104 0x0010c RW  0x1000
  DYNAMIC        0x000518 0x08049518 0x08049518 0x000c8 0x000c8 RW  0x4
  NOTE           0x000138 0x08048138 0x08048138 0x00020 0x00020 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

 Section to Segment mapping:
  Segment Sections...
   00   
   01     .interp
   02     .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame
   03     .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag
   06   

[Requesting program interpreter: /home/root_shawn/lib/ld-linux.so.2] --- that's what I want. Shit~ I can debug the fucking glibc now. I'll keep reading the Phrack paper( avoid the stack canary to remote exploit for profit and fun? ) this week. 29% is too far away from my goal/gold.....hmm...maybe emacs's lines counter has some problem @_@

btw: The Architecture wants the Matrix running by the paradigms of  closed system/linear/mechanic/engineering/controlled. The Oracle wants the Matrix becoming a diversity world with infinitely possibility, by following the paradigms of open system/non-linear/biological/evolving/out of control. The matters is depend on your "choice".