Aggregator

最近访问博客发现页面显示不正常，F12查看网络情况后发现cloudflare加载的静态资源出了问题，具体表现为浏览器出现HSTS警告，使用socks5代理时正常(使用socks5代理时，DNS查询也是用的socks5代理)：

2020年1月15日, Oracle官方发布了Weblogic

Last weekend we played Hack.lu CTF and got 5th place. I am quite busy recently so I only solved one challenge: Stonks Socket, and I think it is quite interesting and worthy to do a writeup.

In this challenge we need to exploit Linux kernel. In the kernel module, tcp_prot.ioctl of TCP socket is written to self-defined function stonks_ioctl, and sk_prot->recvmsg of TCP socket is written to self-defined function stonks_rocket inside one of the handlers in stonks_ioctl. The vulnerability is a use-after-free caused by race condition: sk_user_data field of struct sock is fetched before blocking in stonks_rocket and can be freed while blocking, and one of its function pointer field will be called after blocking. Therefore, we perform heap spray to control its function pointer field so to control rip in kernel mode. Since SMEP is not enabled, we can execute shellcode in user-space memory to call commit_cred(prepare_kernel_cred(0)) and get root privilege.

There are actually 3 vulnerabilities in this challenge, but I found other 2 not useful for exploitation:

1. The first vulnerability is the one I mentioned in overview section. Inside stonks_rocket, struct StonksSocket *s_sk = sk->sk_user_data; is executed to fetch user data of skin first few lines, and the function can be blocked by tcp_recvmsg. However, while blocking, we can actually free sk->sk_user_data through OPTION_PUT command in stonks_ioctl using another thread. Therefore, after resuming from tcp_recvmsg, s_sk is already a freed dangling pointer but s_sk->hash_function will be called. Thus, this is an UAF bug.
2. The second vulnerability is an out-of-bound read in command OPTION_DEBUG, which allows us to leak arbitrary kernel data. However, it seems that we don’t need such data leakage.
3. The third vulnerability is a stack overflow in secure_hash. Since h->length is controllable and not limited, (&h->word1)[i] = h->key; in loop body would cause out-of-bound write. However, since we can only write one 64-bit value and cannot skip over the stack canary, this vulnerability is not quite useful either.

To trigger stonks_ioctl, we just need to call ioctl using connfd returned by accept function; after calling ioctl(connfd, OPTION_CALL, &a) we can trigger stonks_rocket via recv function using connfd.

As briefly mentioned above, we need to firstly call OPTION_CALL command of ioctl on connfd.

Then we create a thread, immediately followed by a recv function called on connfd that fetches sk->sk_user_data and blocks the main thread.

Inside thread function, sleep(1) is called to ensure recv function in main thread is blocked first. Then ioctl(connfd, OPTION_PUT, NULL) is called to free sk->sk_user_data, and some data is sent to server via client file descriptor to resume recv function blocked in main thread.

This is actually the part that got me stuck for longest time. I firstly considered to use universal heap spraying, but userfaultfd is not available due to kernel configuration. Then we tried to find a 32-byte kernel object allocated on heap that can allow user to control the last 8 bytes (e.i. function pointer field), and we indeed found this. However, it seems that corresponding protocol is not supported in this kernel build.

Finally, I still decided to use kmalloc called in function secure_hash shown below.

When h->length is 4, 32-byte chunk will be allocated and filled with user-controlled data, which is exactly pointed by sk->sk_user_data; and even if the chunk is freed, last 8 bytes will still remain to be our own data. Although this seems to be great, when while loop breaks, the buffer is filled with all zeros. After some debugging, I realized that kmalloc here would clear the memory chunk allocated to zeros. The loop exit condition is i == 0, so this means copy_from_iter should return 0 for the last time loop body is executed. copy_from_iter always returns the number of bytes that is copied to the destination buffer. Combining these two, this means in the last run of the while loop, the buffer will be filled with zeros and no input is read into the buffer, so s_sk->hash_function is also NULL.

Therefore, we need to let main thread call sk->sk_user_data->hash_function at the same time when secure_hash is still executing that while loop. This can be done by creating a new thread to run secure_hash function. Initially I was spending a lot of time in trying to let copy_from_iter block by using the stack overflow (e.i. third bug mentioned above) to tamper struct iov_iter. However, this does not work because if we need to trigger the stack overflow, h->length is no longer 4 so that size allocated is not 32 bytes, which means we cannot allocate to chunk pointed by sk->sk_user_data.

The final approach is to let the while loop run many times by sending a large chunk of data, and hope when executing the while loop, the function pointer field is called. It turns out the probability of success is not low if parameter is tuned properly. The important thread functions are shown below.

The large chunk of data is sent before via send(*clientfd, a, sizeof(a), 0), where a is initialized to be pointers to our get_root function, which obtains kernel address stored on stack and calls commit_cred(prepare_kernel_cred(0)).

One interesting point to note is that rip hijacked is sometimes shift of &get_root (e.g. &get_root << 8). Possible reason is that recv does not necessarily stops at alignment of 8, so that future alignment might be broken.

The full exploit is here.