clock_gettime call not using vDSO?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I already asked a question on a similar topic (vDSO file path in Android x86 kernel) but I encountered another problem.
I am working on a school research on Dirty CoW vulnerability. I found out that some of the existing solutions exploit vDSO by causing a race condition that injects some shellcode into the shared object.
I tried to replicate the attack on Android 4.4-r4 (x86), I have successfully injected my shellcode into vDSO (I write the content of vDSO to a file after the attack), but the system seems to not even have noticed. The original attack was injecting two shellcodes - the first was written behind the vDSO code and contained code, that was calling SYS_EXECVE executing /system/bin/touch /sdcard/FILE123.txt
. The other shellcode was written to the prologue of __vdso_clock_gettime
and contained instruction calling the first shellcode.
The prologue before the exploit:
000006ac <__vdso_clock_gettime@@LINUX_2.6>:
6ac: 55 push %ebp
6ad: 89 e5 mov %esp,%ebp
6af: 57 push %edi
6b0: 56 push %esi
6b1: 53 push %ebx
6b2: 83 ec 10 sub $0x10,%esp
The prlogue after the exploit:
000006ac <__vdso_clock_gettime@@LINUX_2.6>:
6ac: e8 6f 07 00 00 call e20 <__kernel_vsyscall@@LINUX_2.5+0x38c>
6b1: 90 nop
6b2: 83 ec 10 sub $0x10,%esp
The other shellcode is written to an empty space on offset 0xe20
.
That did not work, so I made another shellcode, that only writes 0x90 (nop)
starting from the beginning of __vdso_clock_gettime
all the way up to the end of the memory page. That succeeded as well, but it has no effect at all. I even wrote a C program that calls clock_gettime()
:
#include <time.h>
#include <errno.h>
...
struct timespec tp;
tp.tv_sec = 0;
tp.tv_nsec = 0;
int r = clock_gettime(CLOCK_REALTIME, &tp);
if(r != 0)
printf("Gettime error (%d) - errno: %dn", r, errno);
else
printf("Gettime success (%d) - time is: %d s %ld nsn", r, tp.tv_sec, tp.tv_nsec);
...
After compiling this program using Android NDK standalone toolchain and executing it (via ADB), it always succeeds and the output looks like this:
Gettime success (0) - time is: 1517237312 s 649357893 ns
How is that possile? I destroyed the function I am calling, so it should not work, right? Or are the calls to the functions from vDSO cached somewhere else? How do I persuade the system to call this particular function?
kernel linux-kernel android clock
add a comment |Â
up vote
0
down vote
favorite
I already asked a question on a similar topic (vDSO file path in Android x86 kernel) but I encountered another problem.
I am working on a school research on Dirty CoW vulnerability. I found out that some of the existing solutions exploit vDSO by causing a race condition that injects some shellcode into the shared object.
I tried to replicate the attack on Android 4.4-r4 (x86), I have successfully injected my shellcode into vDSO (I write the content of vDSO to a file after the attack), but the system seems to not even have noticed. The original attack was injecting two shellcodes - the first was written behind the vDSO code and contained code, that was calling SYS_EXECVE executing /system/bin/touch /sdcard/FILE123.txt
. The other shellcode was written to the prologue of __vdso_clock_gettime
and contained instruction calling the first shellcode.
The prologue before the exploit:
000006ac <__vdso_clock_gettime@@LINUX_2.6>:
6ac: 55 push %ebp
6ad: 89 e5 mov %esp,%ebp
6af: 57 push %edi
6b0: 56 push %esi
6b1: 53 push %ebx
6b2: 83 ec 10 sub $0x10,%esp
The prlogue after the exploit:
000006ac <__vdso_clock_gettime@@LINUX_2.6>:
6ac: e8 6f 07 00 00 call e20 <__kernel_vsyscall@@LINUX_2.5+0x38c>
6b1: 90 nop
6b2: 83 ec 10 sub $0x10,%esp
The other shellcode is written to an empty space on offset 0xe20
.
That did not work, so I made another shellcode, that only writes 0x90 (nop)
starting from the beginning of __vdso_clock_gettime
all the way up to the end of the memory page. That succeeded as well, but it has no effect at all. I even wrote a C program that calls clock_gettime()
:
#include <time.h>
#include <errno.h>
...
struct timespec tp;
tp.tv_sec = 0;
tp.tv_nsec = 0;
int r = clock_gettime(CLOCK_REALTIME, &tp);
if(r != 0)
printf("Gettime error (%d) - errno: %dn", r, errno);
else
printf("Gettime success (%d) - time is: %d s %ld nsn", r, tp.tv_sec, tp.tv_nsec);
...
After compiling this program using Android NDK standalone toolchain and executing it (via ADB), it always succeeds and the output looks like this:
Gettime success (0) - time is: 1517237312 s 649357893 ns
How is that possile? I destroyed the function I am calling, so it should not work, right? Or are the calls to the functions from vDSO cached somewhere else? How do I persuade the system to call this particular function?
kernel linux-kernel android clock
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I already asked a question on a similar topic (vDSO file path in Android x86 kernel) but I encountered another problem.
I am working on a school research on Dirty CoW vulnerability. I found out that some of the existing solutions exploit vDSO by causing a race condition that injects some shellcode into the shared object.
I tried to replicate the attack on Android 4.4-r4 (x86), I have successfully injected my shellcode into vDSO (I write the content of vDSO to a file after the attack), but the system seems to not even have noticed. The original attack was injecting two shellcodes - the first was written behind the vDSO code and contained code, that was calling SYS_EXECVE executing /system/bin/touch /sdcard/FILE123.txt
. The other shellcode was written to the prologue of __vdso_clock_gettime
and contained instruction calling the first shellcode.
The prologue before the exploit:
000006ac <__vdso_clock_gettime@@LINUX_2.6>:
6ac: 55 push %ebp
6ad: 89 e5 mov %esp,%ebp
6af: 57 push %edi
6b0: 56 push %esi
6b1: 53 push %ebx
6b2: 83 ec 10 sub $0x10,%esp
The prlogue after the exploit:
000006ac <__vdso_clock_gettime@@LINUX_2.6>:
6ac: e8 6f 07 00 00 call e20 <__kernel_vsyscall@@LINUX_2.5+0x38c>
6b1: 90 nop
6b2: 83 ec 10 sub $0x10,%esp
The other shellcode is written to an empty space on offset 0xe20
.
That did not work, so I made another shellcode, that only writes 0x90 (nop)
starting from the beginning of __vdso_clock_gettime
all the way up to the end of the memory page. That succeeded as well, but it has no effect at all. I even wrote a C program that calls clock_gettime()
:
#include <time.h>
#include <errno.h>
...
struct timespec tp;
tp.tv_sec = 0;
tp.tv_nsec = 0;
int r = clock_gettime(CLOCK_REALTIME, &tp);
if(r != 0)
printf("Gettime error (%d) - errno: %dn", r, errno);
else
printf("Gettime success (%d) - time is: %d s %ld nsn", r, tp.tv_sec, tp.tv_nsec);
...
After compiling this program using Android NDK standalone toolchain and executing it (via ADB), it always succeeds and the output looks like this:
Gettime success (0) - time is: 1517237312 s 649357893 ns
How is that possile? I destroyed the function I am calling, so it should not work, right? Or are the calls to the functions from vDSO cached somewhere else? How do I persuade the system to call this particular function?
kernel linux-kernel android clock
I already asked a question on a similar topic (vDSO file path in Android x86 kernel) but I encountered another problem.
I am working on a school research on Dirty CoW vulnerability. I found out that some of the existing solutions exploit vDSO by causing a race condition that injects some shellcode into the shared object.
I tried to replicate the attack on Android 4.4-r4 (x86), I have successfully injected my shellcode into vDSO (I write the content of vDSO to a file after the attack), but the system seems to not even have noticed. The original attack was injecting two shellcodes - the first was written behind the vDSO code and contained code, that was calling SYS_EXECVE executing /system/bin/touch /sdcard/FILE123.txt
. The other shellcode was written to the prologue of __vdso_clock_gettime
and contained instruction calling the first shellcode.
The prologue before the exploit:
000006ac <__vdso_clock_gettime@@LINUX_2.6>:
6ac: 55 push %ebp
6ad: 89 e5 mov %esp,%ebp
6af: 57 push %edi
6b0: 56 push %esi
6b1: 53 push %ebx
6b2: 83 ec 10 sub $0x10,%esp
The prlogue after the exploit:
000006ac <__vdso_clock_gettime@@LINUX_2.6>:
6ac: e8 6f 07 00 00 call e20 <__kernel_vsyscall@@LINUX_2.5+0x38c>
6b1: 90 nop
6b2: 83 ec 10 sub $0x10,%esp
The other shellcode is written to an empty space on offset 0xe20
.
That did not work, so I made another shellcode, that only writes 0x90 (nop)
starting from the beginning of __vdso_clock_gettime
all the way up to the end of the memory page. That succeeded as well, but it has no effect at all. I even wrote a C program that calls clock_gettime()
:
#include <time.h>
#include <errno.h>
...
struct timespec tp;
tp.tv_sec = 0;
tp.tv_nsec = 0;
int r = clock_gettime(CLOCK_REALTIME, &tp);
if(r != 0)
printf("Gettime error (%d) - errno: %dn", r, errno);
else
printf("Gettime success (%d) - time is: %d s %ld nsn", r, tp.tv_sec, tp.tv_nsec);
...
After compiling this program using Android NDK standalone toolchain and executing it (via ADB), it always succeeds and the output looks like this:
Gettime success (0) - time is: 1517237312 s 649357893 ns
How is that possile? I destroyed the function I am calling, so it should not work, right? Or are the calls to the functions from vDSO cached somewhere else? How do I persuade the system to call this particular function?
kernel linux-kernel android clock
edited Feb 18 at 22:15
asked Feb 17 at 12:12
Topper Harley
176
176
add a comment |Â
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f424779%2fclock-gettime-call-not-using-vdso%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password