In order to know if SMEP is enabled or not, run the following command. Once the system has been installed (don't develop on a LiveCD), we need to check that the system configuration is as expected. You can use the free version of vmware for instance or any other virtualization tool as long as it supports SMEP (we will bypass it). However, we discourage using virtualbox as it didn't support SMEP (not sure if it does right now). WARNING: To ease debugging, you must run the target with a virtualization software. If you want to develop the exploit on another target, please see the next section.ĭo not worry if you don't know what are SLAB/SMEP/SMAP, this will be covered in part 3 and part 4. The "default" configuration on the previous ISO satisfies all of those requirements. Otherwise, reallocation may need additional steps (cf. WARNING: Due to code variation in the suggested target, it is recommended to set the number of CPU to one. One is okay, you will understand why soon enough. Kernel version must be lower than 4.11.9 (we recommend =512MB.While the bug is (mostly) exploitable in various configurations/architecture, the only requirements needed to exploit it the same way we do are: Most of the changes will appear during the last stages of exploitation (cf. We only confirmed that the bug is reachable and makes the kernel crash. There might be slight variations in the code that shouldn't be blocking. However, you can try to implement the exploit on the following target. The code exposed here comes from a specific target (2.6.32.x). UPDATE: Thanks to readers feedbacks, this section has been updated (). A guide to Kernel Exploitation: Attacking the Core (E. Understanding Linux Network Internals (C.We recommend you to read those books (they are great!): This article only covers a small subset of the whole kernel. Note: we do not deserve any credit for this CVE discovery, it is basically a 1-day implementation. Anyway, if you really want to get into kernel hacking, you must be ready to read a lot of codes and documentation. Warning: Please do not get scared by the size of this series, there are tons of code. Fire up your favorite code crawling tool and let's start! It is recommended grabbing the source code of a vulnerable kernel and try to follow the code on the go (or even better, implement the exploit). Do not try to run the exploit as is, this will just crash your system! You can find the final exploit here. Hence, some modifications are required to run it on another target (structure offsets/layout, gadgets, function addresses.). The exploit built here is not targetless. It shouldn't be too hard to find the equivalent paths on a more recent kernel. One might think that this version is too old, yet it is still actually used in a lot of places and some paths might be easier to understand. The kernel code exposed here matches a specific version (v2.6.32.x), nevertheless the bug also affects kernels up to 4.11.9. At the time of writing, there is no known public exploit. Most distributions patched it during the mid 2017. The CVE developed here is CVE-2017-11176, aka "mq_notify: double sock_put()". In addition, we will show some debugging techniques, tools, common pitfalls and how to fix them. Exploit writing is actually a good way to understand the Linux kernel. Think of it as a guided Linux kernel tour supported by a practical example. While it is impossible to cover everything in a single article, we will try to unroll every kernel path needed to develop the exploit. In the end, every single line of the exploit should be understood, as well as their impact on the kernel. Since most kernel exploit articles imply that the reader is already familiar with the kernel code, we will try to fill the gap by exposing core data structure and important code paths. The targeted audience is the Linux kernel newcomers (nothing too fancy for the veterans). The PoC is then turned into an arbitrary call primitive ( part 3) which is finally used to execute arbitrary code in ring-0 ( part 4). It starts with the patch analysis to understand the bug and trigger it from kernel land ( part 1), then it gradually builds a working proof-of-concept code ( part 2). This series covers a step-by-step walkthrough to develop a Linux kernel exploit from a CVE description.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |