Dregate

+=-----------------------------------------------------------------------=+
|=[call gates as stable comunication channel for NT x86 and Linux x86_64]=|
|=-----[ David Reguera aka Dreg - Dreg@fr33project.org @therealdreg]=-----|
|=--=[ https://www.fr33project.org/  https://github.com/therealdreg/ ]=--=|
+=--------------------=[ v13: Aug 2022 - Sep 2022 ]=---------------------=+

Phrack Staff is still reviewing my paper from Aug 2022...
So my patience ran out


Thx to Yarden Shafir (@yarden_shafir https://github.com/yardenshafir) for
her technical review + comments. It's a great honor for me :D


------[  First of all

WARNING: This paper and POCs are just for fun and just to enjoy x86_64 +
ring0 Linux/Windows internals.

*** I don't think anyone will ever use this shit for anything useful.

After paper publication all POCs + Bochs instrumentation will be available:

https://github.com/therealdreg/dregate

All POCs should work with: UMIP, NX, KASLR, SMEP, KPTI/PTI/KAISER, SMAP...
But you need to be able to load unsigned drivers on guest OS (or use an
exploit/bypass/...).

NOTE: If you don't know what these things are, you won't understand this
paper, go back to your home :D

All NT POCs presented in this paper, were tested from Windows 2000 x86 to
Windows 10 x86 10.0.19044 (with default OS protections enabled).

All Linux x86_64 POCs were tested on (with default OS protections enabled):
- Debian 11 bullseye 5.10.0-17-amd64 SMP x86_64 (last Aug 2022)
- Ubuntu 22.04.1 LTS jammy 5.15.0-46-generic SMP x86_64 (last Aug 2022)

Linux & Windows POCs Tested on (HW Tiger Lake, i7 11th GEN):
- Bochs 2.7 cpu=corei3_cnl (Cannonlake UMIP...). Host: Windows 10 x86_64.
- VirtualBox 6.1.36 r152435. Host: Windows 10 x86_64.
- Qemu/KVM 6.2.0 (q35 + host-passthrough). Host: Ubuntu 22.04.1 x86_64.
- Native OS installation: Ubuntu 22.04.1 x86_64 & Windows 10 x86 10.0.19044

Thx to Duncan Ogilvie (x64dbg owner: @mrexodia https://github.com/mrexodia)
for proofreading, I love you bro :D

Thx to micronn for their test/comments/time .... :***

Thx to ZwClose for his feedback


<<<<<<<<<<<<<<<
Only one prerequisite for understanding this paper:

- Have an OSCP certification... xDDDDDDDDDDDDDDDDDDDD


------[  NT x86 call gates: Introduction

Well... It has been 14+ years since my last publication on Phrack (#65)

At that time I was ~17 years old, I was young and stupid. Today is much
better because I am no longer young :-(

By the way, phook had a lot of stupid and wrong things xD, but it was
just a dirty POC idea.

Let's get started with Windows part:

"x86 call gates as stable comunication channel for NT"

First, a little background:

x86 chips offer several ways of performing system calls. A few Examples
are: SYSCALL, SYSENTER, Software interrupts and Call gates.

A call gate allows the kernel to call to user mode and vice versa.

Call gates were rarely used because of portability issues. NT does not use
them, but they have been used in exploits and malware like Gurong.A

<<<<<<<<<<<<<<<
If you have not understood anything so far, I'm sorry flag-hunter but this
paper is not for you. Just run back to TryHackMe/HackTheBox.

The reason for this paper is that there is a little problem with call
gates (YES, in 2022!):

AFAIK, all public sources have some race conditions because this mechanism
is not compatible with the NT design. As a result you get random BSODs.

Just for fun, I developed a tricky way to give it stability.

First of all, a bit of lore/gossip:

January 2010, Mateusz "j00ru" Jurczyk and Gynvael Coldwind present a new
paper: "GDT and LDT in Windows kernel vulnerability exploitation"

Btw, we worked for the "same" company at the time (Hispasec/Virustotal),
What a coincidence! Small world :D

Their paper explains how to use a write-what-where condition to convert a
custom LDT entry into a call gate and then use this call gate to elevate
the privilige mode from ring3 to ring0.

Before this paper, I made some changes to the "Call gate" chapter in the
2nd edition of "The Rootkit Arsenal". Bill Blunden accepted my corrections
and they were published (thx for the credit bro! :-D). But as I said, race
conditions/BSODs can happen with our code :-(

After j00ru and Gynvael's publication, my reaction as a Rootkit Unhooker
contributor was to add some features: detecting GDT/LDT call gates, LDT
forward attacks, etc. AFAIK, it has been the only tool that detects things
like LDT forward attack. Rku was the best anti rootkit tool by far, don't
you think? :D

btw, thanks to EP_X0FF for taking my crap POCs and making it decent.

** I miss the kernelmode/rootkit.com era. Btw, one of my childhood dreams
was to collaborate with Rku/29a/phrack/uninformed. So, I can die in peace

At that moment (2009) we were all happy with our buggy call gate POCs,
but...

A fast and furious Indy appeared!!! (woodmann.com/forum, 2009):
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
https://web.archive.org/web/20181222042324/
http://www.woodmann.com/forum/showthread.php
?13355-quot-Descriptor-tables-in-kernel-exploitation-quot-a-new-article
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Indy to j00ru & Gynvael:
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
...
Using the descriptor table is not desirable for the escalation of
privileges. Callgate has many drawbacks (high probability of crash, it is
better to use IDT), such as:
o Do not reset TF and IF.
o Do not formed a trap frame(this is a great disadvantage).
Should use the mechanism that lead to the call target code after the change
of the CPL, the already formed trap frame and unmask interrupts
...
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Gynvael:
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
...
You are correct about the drawback, however, let me comment on the issues
you stated:
1. The TF is controllable - if one does not explicitly set the TF flag with
a POPF one instruction between the CALL FAR to the call gate, then the TF
flag is neglectable in my opionion

2. The IF flag is not reset, which creates a small but existing race
condition Windows - after the CALL FAR, but before explicitly disabling the
IF (cli). I admit that it is possible, but I would judge that the
probability is rather small.

3. The trap frame is not formed indeed, but it can be emulated on demand by
the shellcode writer.
...
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Indy:
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
...
1. If there is a call to the gateway with TF = 1, then it will lead to the
emergence of the trace exception (#DB) in the kernel. Accordingly, the
handler is not installed, that will cause crash. Of course this is not a
critical situation, but can cause problems. But you can ignore this.

2, 3.

While not formed trap frame interrupts can not be unmasked. Although the
stack will be switched to kernel from TSS, but the context of the problem
is not formed, ie the problem does not exist, it will lead to crash.
Of course you can reduce the probability of crash - after crossing the
gateway to mask interrupts, and then manually create trap frame.
Also all user memory is discharged(to swap), the page may be loaded from
drive(swap) only if the interrupt unmasked and only on the first two IRQL.

Yet formed trap frame not available any kernel runtine. You can use the
exception, for example - registration of a handler in the kernel, with
subsequent generation of exception, or any mechanism that formed trap
frame. For hand building trap frame(macro ENTER_TRAP, although it is not
necessary) - the best way to morph handlers in the memory (transfer).
...
Masked interrupts are equivalent to the highest level of IRQL (0xff). It is
forbidden:
- Use memory is pumping. In particular the process address space.
- Apply to other modules and subsystems.
- Use a scheduler runtime. Waiting at the objects, working with threads,
service calls, I/O operations, APC (and others, the context has not been
formed  ), etc., that is, in fact, we can not do anything.
Exploit's for a privilege escalation are too valuable to work with some
probability of crash experienced by the coder
This possibility exists because of memory paging and context switching
(hardware interrupts can do after passing through the gateway, but to mask
interrupts manually (cli), and hardware interrupts are completed by calling
the scheduler).
All this is just my imho. I think the mechanism callgates not suitable for
use in the NT, as a special case in exploit's
...
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Years later (rohitab.com, 2014), zwclose7 post about a own call gate code:

http://www.rohitab.com/discuss/topic/40765-installing-call-gate-on-Windows/

And of course, Indy strikes again x-)

Indy to zwclose7:
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Transition through the gateway does not change Eflags. Ie not masked IF and
is not reset TF. Therefore technology is not compatible with NT. When
tracing is bugcheck. On the IF - instability.
__asm
{
push ebp
mov ebp,esp
push fs // Save the value of FS
mov ax,0x30 // Set FS to kernel mode value
mov fs,ax
}
Where you copied the code ?
I'm here for you. Do you want to invite. You burned on to this code.

You do not know segmentation and protected mode.
You do not see a vulnerability in your code.
You stole the code by MsRem(Delphy, crap; 2006).
You not VX.
You pretend.

I was wrong.
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Well, as you can see, Indy is a hard call gate hater xD, but mentions
several true and interesting things.


------[  Call Gate Problems in NT

1- BSOD when stepping into (TF=1) a CALL FAR (usually during debugging).

2- BSOD when an interrupt happens inside the call gate (after executing
the) CA