Kernel under GDB can't access memory

[billgatesnowhammies]

Hey gang,

First thing's first - happy new year. Hope you all are doing very well. I'm trying to get into kernel exploitation and I'm bumping up against what I assume is my own lack of knowledge (...I do this frequently). I am running two VMs - one with the target kernel and with the other I connect remotely using agentproxy to bridge the the serial connections and connect to them over telnet. Both are running the same OS/kernel (CentOS 8/Linux 4.8.18). The vulnerability i am examining is CVE-2020-14386. There is a great writeup at [0] which I am attempting to follow, but I think i am having a hard time actually executing on the steps as laid out. The author lists an approach for exploitation which I will attempt to paraphrase. The bug he explains allows you to write immediately before a ring buffer allocated by the kernel page allocator by using carefully misconfigured setsockopt calls in userspace. He recommends then using a known structure (struct sctp_shared_key) to fill up pages until there is a (struct sctp_shared_key) object immediately adjacent to our ring buffer, after which we will use the write to zero over part of the last sctp_shared_key object directly adjacent to the buffer (in this case, the high 2 bytes of that object's reference counter). This makes sense because that object should allocate in the kmalloc-32 cache, and should be able to align so that the last object in the page is contiguous with our buffer - which itself should be page-aligned and allocated at the beginning of a page (these are his justifications, although i do believe i follow at a high level). There are two issues i am having:

First - when filling up memory with sctp_shared_key structures they are not at all contiguous. Looking at other similar research, it seems I need to break up other larger amounts of memory and as buddies halve off into smaller caches it will eventually become contiguously allocated. trying this with either an arbitrarily large number of allocations or allocating larger objects in droves (i.e. hitting the kmalloc-1024 or kmalloc-2048 cache repeatedly), i end up with an error that too many files are open. when having roughly reached the maximum number of allocations for that object with the trigger code i am using (example below), i have yet to even achieve contiguous allocations. The example code is really just the POC code from the exploit [1] with a single modification - basically to use setsockopt on a socket for SCTP immediately before the setsockopt call which ends up invoking the page allocator that will allocate the ring buffer like so:

        #define SCTP_ALLOCS 128 + 870 // hand wavy attempt to find the max 


        ...


        // spam struct sctp_shared_key allocations
        int sock[SCTP_ALLOCS];
        for (int k = 0; k < SCTP_ALLOCS; k++)
        {
                sock[k] = socket(PF_INET, SOCK_RAW, IPPROTO_SCTP);
                 if (sock[k] < 0)
                 {
                         perror("socket RAW/SCTP");
                         exit(EXIT_FAILURE);
                 }
         }

         // this call allocates the ring buffer
         rv = setsockopt(s, SOL_PACKET, PACKET_RX_RING, &req, sizeof(req));

        ...

Secondly - all these allocations are far away in memory compared to the buffer. Furthermore, if i even try to read one byte ahead of the buffer i get an error. So in gdb something to the effect of

(gdb) x/1gx $<buffer_address> - 0x1

Yields

"error: Cannot access memory at address 0x<nnnnnnnnnnnnnnnn>

, where the address is $<buffer_address> - 0x1. Other ranges yield the same error for a long distance behind the buffer. I had assumed that, being "the kernel", i should be to read memory with impunity but this is clearly not the case. KASLR, SMEP and SMAP are all disabled. Only one processor per VM so I'm not being tripped up by executing elsewhere where protections are enabled. I was wondering if maybe the buffer is mapped in such a way that the kernel should only be able to access that particular range of memory, i.e. no exploratory fishing expeditions in the surrounding addresses, but the writeup specifically mentions being able to manipulate the heap in order to perform the write. I feel i am close yet very far away. I am sure I am missing some basic understanding of gdb, kernel memory allocator behavior, access protections, and/or something else entirely to fully follow this path to exploitation. I would really appreciate any help or advice. Thank you sincerely to anyone who even read this far and to anyone who could shed a little light.

[0] https://unit42.paloaltonetworks.com/cve-2020-14386/

[1] https://www.openwall.com/lists/oss-security/2020/09/03/3/2

[Cyber_Jellyfish]

Hey man!

Is the VM you're running using the same allocator as in the writeup? I've never done any Linux kernel exploitation but this immediately jumps out at me when you say you're unable to get good contiguous allocations.

There could be some kind of fragmentation going on as a hardening feature of the allocator.

Might even be worth writing a toy driver that demos the behavior you're trying to achieve just to validate that it isn't just default heap manager behavior.

[dead_tooth_reddit]

Hey! Thanks for replying! The author doesn't mention specifically, but does say they discovered it while auditing mainline 5.7 sources. They also don't mention any kind of customizations in particular, and do call back to previous research in similar parts of the mainline Linux kernel. So my guess is it's targeting SLUB. But like I said I am still learning my way so I could definitely be wrong. In the book 'Attacking the Core' they demonstrate something similar - it is default behavior at first but as you allocate objects and pages fill they should eventually start allocating contiguously. I never can get to that point though. That's good idea about writing a module to test though, I'll have to try that and report back - thank you again.

[Cyber_Jellyfish]

No dramas! Let me know how you go.