Cookie Consent by Free Privacy Policy Generator ๐Ÿ“Œ Exploiting CVE-2021-43267

๐Ÿ  Team IT Security News

TSecurity.de ist eine Online-Plattform, die sich auf die Bereitstellung von Informationen,alle 15 Minuten neuste Nachrichten, Bildungsressourcen und Dienstleistungen rund um das Thema IT-Sicherheit spezialisiert hat.
Ob es sich um aktuelle Nachrichten, Fachartikel, Blogbeitrรคge, Webinare, Tutorials, oder Tipps & Tricks handelt, TSecurity.de bietet seinen Nutzern einen umfassenden รœberblick รผber die wichtigsten Aspekte der IT-Sicherheit in einer sich stรคndig verรคndernden digitalen Welt.

16.12.2023 - TIP: Wer den Cookie Consent Banner akzeptiert, kann z.B. von Englisch nach Deutsch รผbersetzen, erst Englisch auswรคhlen dann wieder Deutsch!

Google Android Playstore Download Button fรผr Team IT Security



๐Ÿ“š Exploiting CVE-2021-43267


๐Ÿ’ก Newskategorie: IT Security Nachrichten
๐Ÿ”— Quelle: haxx.in

Introduction

A couple of weeks ago a heap overflow vulnerability in the TIPC subsystem of theLinux kernel was disclosed by Max van Amerongen (@maxpl0it).He posted a detailed write up about the bug on the SentinelLabs website.

Itโ€™s a pretty clear cut heap buffer overflow where we control the size and data of the overflow.I decided I wanted to embark on a small exploit development adventure to see how hard it would be to exploit this bugon a kernel with common mitigations in place (SMEP/SMAP/KASLR/KPTI).

If you came here to find novel new kernel exploitation strategies, you picked thewrong blogpost, sorry!

TIPC?

To quote the TIPC webpage:

Have you ever wished you had the convenience of Unix Domain Sockets even when transmitting data between cluster nodes? Where you yourself determine the addresses you want to bind to and use? Where you donโ€™t have to perform DNS lookups and worry about IP addresses? Where you donโ€™t have to start timers to monitor the continuous existence of peer sockets? And yet without the downsides of that socket type, such as the risk of lingering inodes?

Well.. I have not. But then again, Iโ€™m just an opportunistic vulndev person.

Welcome to the Transparent Inter Process Communication service, TIPC in short, which gives you all of this, and a lot more.

Thanks for having me.

How to tipc-over-udp?

In order to use the TIPC support provided by the Linux kernel youโ€™ll have to compilea kernel with TIPC enabled, or load the TIPC module which ships with many populardistributions. To easily interface with the TIPC subsystem you can use the tipc utilitywhich is part of iproute2.

For example, to list all the node links you can issue tipc link list. We want totalk to the TIPC subsystem over UDP, and for that weโ€™ll have to enable the UDP bearermedia. This can be done using tipc bearer enable media udp name <NAME> localip <SOMELOCALIP>.

Under the hood the tipc userland utility uses netlink messages (using address familyAF_TIPC) to do its thing. Interestingly enough, these netlink messages can be sentby any unprivileged user. So even if thereโ€™s no existing TIPC configuration in place,this bug can still be exploited.

How to reach the vulnerable code path?

So now we know how to enable the UDP listener for TIPC, how do we go about actuallyreaching the vulnerable code? Weโ€™ll have to present ourselves as a valid node andestablish a link before we can trigger the MSG_CRYPTO code path. We can find aprotocol specification on the TIPC webpage that detailseverything about transport, addressing schemes, fragmentation and so on.

Thatโ€™s a lot of really dry stuff though. I made some PCAPs of a tipc-over-udpsession setup and with some hand-waving and reading the kernel source narrowedit down to a few packets we need to emit before we can start sending the messageswe are interested in.

In short, a typical TIPC datagram starts with a header, that consist out of at leastsix 32bit words in big endian byte order. Those are typically referred to as w0 through w5.This header is (optionally) followed by a payload. w0 encodes the TIPC version,header size, payload size, the message โ€˜protocolโ€™. Thereโ€™s also a flag whichindicates whether this is a sequential message or not.

w1 encodes (among other things) a protocol message type specific to the protocol.

The header also specifies a node_id in w3 which is a unique identifier a nodeincludes in every packet. Typically, nodes encode their IPv4 address to be theirnode_id.

A quick way to learn about the various bit fields of theheader format is by consulting net/tipc/msg.h.

To establish a valid node link we send three packets:

protocol: LINK_CONFIG   -> message type: DSC_REQ_MSGprotocol: LINK_PROTOCOL -> message type: RESET_MSGprotocol: LINK_PROTOCOL -> message type: STATE_MSG

The LINK_CONFIG packet will advertise ourselves. The link is then reset with theLINK_PROTOCOL packet that has the RESET_MSG message type. Finally, the linkis brought up by sending a LINK_PROTOCOL packet with the STATE_MSG message type.

Now we are actually in a state where we can send MSG_CRYPTO TIPC packets andstart playing with the heap overflow bug.

Corrupting some memories

A MSG_CRYPTO TIPC packet payload looks like this:

struct tipc_aead_key {    char alg_name[TIPC_AEAD_ALG_NAME];    unsigned int keylen;    char key[];};

As detailed in the SentinelLabs write up, the length of the kmallocโ€™d heap buffer is determinedby taking the payload size from the TIPC packet header. After which the key is memcpyโ€™dinto this buffer with the length specified in the MSG_CRYPTO structure.

At first youโ€™d think that means the overflow uses uncontrolled data.. but you cansend TIPC packets that lie about the actual length of the payload(by making tipc_hdr.payload_size smaller than the actual payload size).This passes all the checks and reaches the memcpy without the remainder of thepayload being discarded, giving us full control over the overflowed data. Great!

The length specified in keylen will be passed to kmalloc directly.

Smaller (up to 8KiB) heap objects allocated by the kernel using kmalloc end up incaches that are grouped by size (powers of two). You can have a peep at /proc/slabinfoand look at the entries prefixed by kmalloc- to get an overview of the general purposeobject cache sizes.

Since we can control the size of the heap buffer that will be allocated and overflowed,we can pick in which of these caches our object ends up. This is a great ability, as itallows us to overflow into adjacent kernel objects of a similar size!

Defeating KASLR

If we want to do any kind of control flow hijacking weโ€™re going to need an information leakto disclose (at least) some kernel text/data addresses so we can deduce the randomizedbase address.

It would be great if we could find some kernel objects that contain a pointer/offset/lengthfield early on in their structure, and that can be made to return data back to userland somehow.

While googling I stumbled on this cool paperby some Pennsylvania State University students who dubbed objects with such properties โ€œElastic Objectsโ€.Their research on the subject is quite exhaustive and covers Linux, BSD and XNU.. I definitley recommendchecking it out.

Since we can pick arbitrarily sized allocations, weโ€™re free to target any convenientelastic object. I went with msg_msg, which is popular choice amongst fellow exploitdevs. ;-)

The structure of a msg_msg as defined in include/linux/msg.h:

/* one msg_msg structure for each message */struct msg_msg {struct list_head m_list;long m_type;size_t m_ts;/* message text size */struct msg_msgseg *next;void *security;/* the actual message follows immediately */};

You can easily allocate msg_msg objects using the msgsnd system call. Andthey can be freed again using the msgrcv system call. These system calls arenot to be confused with the sendmsg and recvmsg system calls btw, great naming scheme!

If we corrupt the m_ts field of a msg_msg object we can extend its size and get a relative kernel heap out-of-boundsread back to userland when retrieving the message from the queue again using the msgrcvsystem call.

A small problem with this is that overwriting the m_ts field also requirestrampling over the struct list_head members (a prev/next pointer). When msgrcvis called and a matching message is found, it wants to unlink it from the linked list..but since weโ€™re still in the information leak stage of the exploit, we canโ€™t put any legitimate/meaningfulpointers in there. Luckily, thereโ€™s a flag you can pass to msgrcv called MSG_COPY, whichwill make a copy of the message and not unlink the original one, avoiding a bad pointer dereference.

So the basic strategy is to line up three objects like this:

msg_msgmsg_msgsome_interesting_object

and proceed to free the first msg_msg object and allocate the MSG_CRYPTO keybuffer into the hole it left behind. We corrupt the adjacent msg_msg using thebuffer overflow and subsequently leak data from some_interesting_object usingthe msgrcv system call with the MSG_COPY flag set.

I chose to leak the data of tty_struct, which can easily be allocated by open()โ€˜ing/dev/ptmx. This tty_struct holds all kinds of state related to the tty, andstarts off like this:

struct tty_struct {    int magic;    struct kref kref;    struct device *dev; /* class device or NULL (e.g. ptys, serdev) */    struct tty_driver *driver;    const struct tty_operations *ops;    int index;    ...}

A nice feature of this structure is the magic at the very start, it allows usto easily confirm the validity of our leak by comparing it against the expectedvalue TTY_MAGIC (0x5401). A few members later we find struct tty_operations *ops whichpoints to a list of function pointersassociated with various operations. This points to somewhere in kernel .data, andthus we can use it to defeat KASLR!

Depending on whether the tty_struct being leaked belongs to a master pty orslave pty (they are allocated in pairs) weโ€™ll end up finding the address of ptm_unix98_ops or pty_unix98_ops.

As an added bonus, leaking tty_struct also allows us to figure out the addressof the tty_struct because tty_struct.ldisc_sem.read_wait.next points to itself!

Getting $RIP (or panic tryinโ€™)

Naturally, the tty_operations pointer is a nice target for overwriting to hijackthe kernel execution flow. So in the next stage of the exploit we start by sprayinga bunch of copies of a fake tty_operations table. We can accurately guesstimatethe address of one of these sprayed copies by utilizing the heap pointer we leakedin the previous step.

Now we repeatedly: allocate msg_msg, allocate tty_struct(s), free msg_msg, triggerTIPC bug to (hopefully) overflow into a tty_struct. To confirm we actually overwrote(the first part) of a tty_struct we invoke ioctl on the fd we got from opening/dev/ptmx, this will call tty_struct.ops.ioctl and should get us control over $RIPif we managed to hijack the ops pointer of this object. If its not the case, weclose() the pty again to not exhaust resources.

Avoiding ROP (mostly)

Where to jump to in the kernel? We could set up a ROP stack somewhere and pivotthe stack into it.. but this can get messy quick, especially once you need to docleanup and resume the kernel thread like nothing ever happened.

If we look at the prototype of the ioctl callback from the ops list, we see:

int (*ioctl)(struct tty_struct *tty, unsigned int cmd, unsigned long arg);

We can set both cmd and arg from the userland invocation easily!

So effectively we have an arbitrary function call where we control the 2ndand 3rd argument (RSI and RDX respectively). Well, cmd is actually truncatedto 32bit, but thatโ€™s good enough.

Letโ€™s try to look for some gadget sequence that allows us to do an arbitrary write:

$ objdump -D -j .text ./vmlinux \    | grep -C1 'mov    %rsi,(%rdx)' \    | grep -B2 ret..ffffffff812c51f5:       31 c0                   xor    %eax,%eaxffffffff812c51f7:       48 89 32                mov    %rsi,(%rdx)ffffffff812c51fa:       c3                      ret..

This one is convenient, it also clears rax so the exploit can tell whether theinvocation was a success. We now have some arbitrary 64bit write gadget! (For somedefinition of arbitrary, the value is always 32bit controlled + 32bit zeroes, but whatever)

Meet my friend: modprobe_path

Okay, we have this scuffed arbitrary write gadget we can repeatedly invoke, what do weoverwrite? Classic kernel exploits would target the cred structure of the currenttask to elevate the privileges to uid0. We could of course build an arbitrary readmechanism in the same way we build the arbitrary write.. but lets try something else.

There are various scenarios in which the kernel will spawn a userland process(using the usermode_helper infrastructure in the kernel) to load additionalkernel modules when it thinks that is necessary. The process spawned to loadthese modules is, of course: modprobe. The path to the modprobe binary is storedin a global variable called modprobe_path and this can be set by a privilegeduser through the sysfs node /proc/sys/kernel/modprobe.

This is a perfect candidate for overwriting using our write gadget. If we overwritethis path and convince the kernel we need some additional module support we can invokeany executable as root!

One of these modprobe scenarios is when you try to run a binary that has no knownmagic, in fs/exec.c we see:

/* * cycle the list of binary formats handler, until one recognizes the image */static int search_binary_handler(struct linux_binprm *bprm){    ..    if (request_module("binfmt-%04x", *(ushort *)(bprm->buf + 2)) < 0)    ..}

request_module ends up invoking call_modprobe which spawns a modprobe processbased on the path from modprobe_path.

Closing Words

I hope you enjoyed the read. Feel free to reach out to point out any inaccuraciesor feedback. The full exploit code can be found here

A succesful run of the exploit should look something like this:

PoC in action

...



๐Ÿ“Œ CVE-2020-4464 and CVE-2020-4448: Exploiting Remote Protocols in IBM WebSphere


๐Ÿ“ˆ 13.87 Punkte

๐Ÿ“Œ Attackers exploiting ConnectWise ScreenConnect flaws, fixes available for all users (CVE-2024-1709, CVE-2024-1708)


๐Ÿ“ˆ 13.87 Punkte

๐Ÿ“Œ [papers] - Windows Kernel Exploitation 101: Exploiting CVE-2014-4113


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ [papers] - Windows Kernel Exploitation 101: Exploiting CVE-2014-4113


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Analysis of CVE-2016-10190 - Exploiting FFmpeg ft. Paul Cher


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ RTMP Heap Overflow CVE-2016-10191 - Exploiting FFmpeg ft. Paul Cher


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Hackers are exploiting theย CVE-2018-0101ย CISCO ASA flaw in attacks in the wild


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Experts uncovered a watering hole attack on leading Hong Kong Telecom Site exploiting CVE-2018-4878 flaw


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Analysis of a targeted attack exploiting the WinRar CVE-2018-20250 vulnerability


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Exploiting CVE-2019-0752 without shellcode - details of a write-what-where vulnerability in IE (with PoC)


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Exploiting the Windows Task Scheduler Through CVE-2019-1069


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ CVE-2019-18683: Exploiting a Linux kernel vulnerability in the V4L2 subsystem


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Exploiting F5 Big IP Vulnerability | CVE-2020-5902


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Vigilante hackers strike Russia and Iran Networks exploiting Cisco CVE-2018-0171 flaw


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Microsoft warns of spam campaign exploiting CVE-2017-11882 flaw


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ It didn't take long for attackers to start exploiting the recently publicly revealed exim vulnerability (cve-2019-10149).


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ US Cyber Command warns of Iran-linked hackers exploiting CVE-2017-11774 Outlook flaw


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Us cyber command posted on twitter a warning about a series of cyber attacks exploiting the cve-2017-11774 vulnerability in outlook.


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ CVE-2020-9715: Exploiting a Use-After-Free in Adobe Reader


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ CVE-2020-9715: Exploiting a Use-After-Free in Adobe Reader


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Exploiting CVE-2014-3153 (Towelroot)


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ [Video] Exploiting Windows RPC โ€“ CVE-2022-26809 Explained | Patch Analysis


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Exploiting the Windows Task Scheduler Through CVE-2019-1069


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ AA22-138A: Threat Actors Exploiting F5 BIG-IP CVE-2022-1388


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ CVE-2022-23088: Exploiting a Heap Overflow in the FreeBSD Wi-Fi Stack


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ CVE-2022-23088: Exploiting a Heap Overflow in the FreeBSD Wi-Fi Stack -- includes root cause analysis and PoC code


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Malicious app exploiting CVE-2019-2215 zero-day available in Google Play since March


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ CVE-2019-18683: Exploiting a Linux kernel vulnerability in the V4L2 subsystem


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Nation-state actors are exploiting CVE-2020-0688 Microsoft Exchange server flaw


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ US CISA warns of attacks exploiting CVE-2020-5902 flaw in F5 BIG-IP


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Attacks exploiting Netlogon vulnerability (CVE-2020-1472)


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ [Video] Exploiting Windows RPC &#8211; CVE-2022-26809 Explained | Patch Analysis


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Threat actors target govt networks exploiting Fortinet SSL-VPN CVE-2022-42475 bug


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Attacks exploiting Netlogon vulnerability (CVE-2020-1472)


๐Ÿ“ˆ 12.61 Punkte

๐Ÿ“Œ Attacks exploiting Netlogon vulnerability (CVE-2020-1472)


๐Ÿ“ˆ 12.61 Punkte











matomo