Disable stack protection on Ubuntu for buffer overflow without C compiler flagsHow to turn off stack...
Is it possible to (7 day) schedule sleep time of a hard drive?
Russian equivalent of the French expression "broyer du noir"
What are the peak hours for public transportation in Paris?
Building a road to escape Earth's gravity by making a pyramid on Antartica
Why only the fundamental frequency component is said to give useful power?
Random Portfolios vs Efficient Frontier
Select items in a list that contain criteria #2
2.8 is missing the Carve option in the Boolean Modifier
Remove sudoers using script
How Can I Tell The Difference Between Unmarked Sugar and Stevia?
How to skip replacing first occurrence of a character in each line?
How can drunken, homicidal elves successfully conduct a wild hunt?
siunitx error: Invalid numerical input
Did the first version of Linux developed by Linus Torvalds have a GUI?
Trapping Rain Water
What's the correct term for a waitress in the Middle Ages?
Cause of continuous spectral lines
Average spam confidence
Bent spoke design wheels — feasible?
Avoiding cliches when writing gods
How many pairs of subsets can be formed?
Why don’t airliners have temporary liveries?
When conversion from Integer to Single may lose precision
How to retract the pitched idea from employer?
Disable stack protection on Ubuntu for buffer overflow without C compiler flags
How to turn off stack protector in linux kernel easily?How can I use my server to compile a kernel for my laptop?autoconf save ./configure command line to config.hBuilding Snapwm on FreeBSD (Problem of gcc and clang)?Where can I “hide” easter eggs for students learning about Linux security?Debugging info in linux kernel - how does it work?Do these commands look malicious?Problems compiling Python 3.6.0+ in Qubes OS DebianWhy can't a project compile with symbol linkApache + mod_ssl build not linking to my OpenSSL buildHow to install Musescore 3 on Debian?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I'd like to try some shell codes and I want to disable linux protections.
I know I could compile using flags but I know another way exists to disable these protections in general I just can't remember. Can you help me?
linux security compiling
add a comment |
I'd like to try some shell codes and I want to disable linux protections.
I know I could compile using flags but I know another way exists to disable these protections in general I just can't remember. Can you help me?
linux security compiling
add a comment |
I'd like to try some shell codes and I want to disable linux protections.
I know I could compile using flags but I know another way exists to disable these protections in general I just can't remember. Can you help me?
linux security compiling
I'd like to try some shell codes and I want to disable linux protections.
I know I could compile using flags but I know another way exists to disable these protections in general I just can't remember. Can you help me?
linux security compiling
linux security compiling
edited Mar 4 '13 at 22:52
Gilles
556k13411421651
556k13411421651
asked Mar 4 '13 at 11:01
PhatePhate
1572410
1572410
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Stack protection is done by the compiler (add some extra data to the stack and stash some away on call, check sanity on return). Can't disable that without recompiling. It's part of the point, really...
6
ASLR requires the OS to do it at runtime. NX bits also require system support. What part can't be disabled at runtime?
– Jeff Ferland
Mar 4 '13 at 23:38
add a comment |
To expand on what vonbrand has (correctly, +1) said, there are two parts to Linux's stack protection.
Stack canaries
Stack canaries are the compiler-enforced feature vonbrand refers to. These can't be disabled without a recompile.
To prove this to yourself and see how they work take the following code:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
int mybadfunction(char* a_bad_idea)
{
char what[100];
strcpy(what, a_bad_idea);
printf("You passed %sn", what);
}
int main(int argc, char** argv)
{
printf("Tralalalaalan");
mybadfunction(argv[1]);
}
Now compile that (gcc -fstack-protector -masm=intel -S test.c
) into something gnu as would be happy to assemble and read the output. The important point is that on exit from the mybadfunction
function, there is this little piece of code:
mov edx, DWORD PTR [ebp-12]
xor edx, DWORD PTR gs:20
je .L2
call __stack_chk_fail
As you can guess, that's taking a stack cookie from [ebp-12]
and comparing it to the value at gs:20
. Doesn't match? It then calls a function __stack_chk_fail
in glibc which kills your program right there.
There are ways to work around this in terms of writing exploits, but the easy way in terms of building a shellcode test case is to compile your program with -fno-stack-protector
.
Non-executable pages
There are some other considerations on modern Linux systems. If you take the usual shellcode testing stub:
char buffer[] = {...};
typedef void (* func)(void);
int main(int argc, char** argv)
{
func f = (func) buffer;
f();
return 0;
}
modern GCC/Linux will map the .rodata
section of the PE file read only with no execute permissions. You need to turn that off, which can be done using the code sample from this blog post. Basic idea: you use mprotect
to add the permissions you want to the pages in which the shellcode data resides.
Non-executable stacks
If you are going to test a traditional exploit scenario, e.g. my bad code above, with your shellcode then you also need to ensure the stack is executable for the simple cases. The PE file format contains a field for determining whether the stack is executable — you can query and control this with execstack. To enable an executable stack, run
execstack -s /path/to/myprog
This can be done on arbitrary programs without needing a recompile, but won't automatically disable stack canaries as these are baked in on compile.
Added bonus: aslr:
To turn that off, echo 0 > /proc/sys/kernel/randomize_va_space
.
Did you just tell someone how to exploit my precious penguin?
No. Any exploit must work around stack canaries (very much non trivial) and either find a program with execstack
set, or set it (meaning it can already execute arbitrary commands anyway) or else use more difficult techniques, such as return to libc/return orientated programming.
add a comment |
You can disable some protections (stack smashing detection and making the stack executable) with these options.
--z execstack
-f no-stack-protector
You can, also, turn off ASLR (address space layout randomization) with Bash with the command:
echo 0 > /proc/sys/kernel/randomize_va_space
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f66802%2fdisable-stack-protection-on-ubuntu-for-buffer-overflow-without-c-compiler-flags%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Stack protection is done by the compiler (add some extra data to the stack and stash some away on call, check sanity on return). Can't disable that without recompiling. It's part of the point, really...
6
ASLR requires the OS to do it at runtime. NX bits also require system support. What part can't be disabled at runtime?
– Jeff Ferland
Mar 4 '13 at 23:38
add a comment |
Stack protection is done by the compiler (add some extra data to the stack and stash some away on call, check sanity on return). Can't disable that without recompiling. It's part of the point, really...
6
ASLR requires the OS to do it at runtime. NX bits also require system support. What part can't be disabled at runtime?
– Jeff Ferland
Mar 4 '13 at 23:38
add a comment |
Stack protection is done by the compiler (add some extra data to the stack and stash some away on call, check sanity on return). Can't disable that without recompiling. It's part of the point, really...
Stack protection is done by the compiler (add some extra data to the stack and stash some away on call, check sanity on return). Can't disable that without recompiling. It's part of the point, really...
answered Mar 4 '13 at 11:06
vonbrandvonbrand
14.4k22745
14.4k22745
6
ASLR requires the OS to do it at runtime. NX bits also require system support. What part can't be disabled at runtime?
– Jeff Ferland
Mar 4 '13 at 23:38
add a comment |
6
ASLR requires the OS to do it at runtime. NX bits also require system support. What part can't be disabled at runtime?
– Jeff Ferland
Mar 4 '13 at 23:38
6
6
ASLR requires the OS to do it at runtime. NX bits also require system support. What part can't be disabled at runtime?
– Jeff Ferland
Mar 4 '13 at 23:38
ASLR requires the OS to do it at runtime. NX bits also require system support. What part can't be disabled at runtime?
– Jeff Ferland
Mar 4 '13 at 23:38
add a comment |
To expand on what vonbrand has (correctly, +1) said, there are two parts to Linux's stack protection.
Stack canaries
Stack canaries are the compiler-enforced feature vonbrand refers to. These can't be disabled without a recompile.
To prove this to yourself and see how they work take the following code:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
int mybadfunction(char* a_bad_idea)
{
char what[100];
strcpy(what, a_bad_idea);
printf("You passed %sn", what);
}
int main(int argc, char** argv)
{
printf("Tralalalaalan");
mybadfunction(argv[1]);
}
Now compile that (gcc -fstack-protector -masm=intel -S test.c
) into something gnu as would be happy to assemble and read the output. The important point is that on exit from the mybadfunction
function, there is this little piece of code:
mov edx, DWORD PTR [ebp-12]
xor edx, DWORD PTR gs:20
je .L2
call __stack_chk_fail
As you can guess, that's taking a stack cookie from [ebp-12]
and comparing it to the value at gs:20
. Doesn't match? It then calls a function __stack_chk_fail
in glibc which kills your program right there.
There are ways to work around this in terms of writing exploits, but the easy way in terms of building a shellcode test case is to compile your program with -fno-stack-protector
.
Non-executable pages
There are some other considerations on modern Linux systems. If you take the usual shellcode testing stub:
char buffer[] = {...};
typedef void (* func)(void);
int main(int argc, char** argv)
{
func f = (func) buffer;
f();
return 0;
}
modern GCC/Linux will map the .rodata
section of the PE file read only with no execute permissions. You need to turn that off, which can be done using the code sample from this blog post. Basic idea: you use mprotect
to add the permissions you want to the pages in which the shellcode data resides.
Non-executable stacks
If you are going to test a traditional exploit scenario, e.g. my bad code above, with your shellcode then you also need to ensure the stack is executable for the simple cases. The PE file format contains a field for determining whether the stack is executable — you can query and control this with execstack. To enable an executable stack, run
execstack -s /path/to/myprog
This can be done on arbitrary programs without needing a recompile, but won't automatically disable stack canaries as these are baked in on compile.
Added bonus: aslr:
To turn that off, echo 0 > /proc/sys/kernel/randomize_va_space
.
Did you just tell someone how to exploit my precious penguin?
No. Any exploit must work around stack canaries (very much non trivial) and either find a program with execstack
set, or set it (meaning it can already execute arbitrary commands anyway) or else use more difficult techniques, such as return to libc/return orientated programming.
add a comment |
To expand on what vonbrand has (correctly, +1) said, there are two parts to Linux's stack protection.
Stack canaries
Stack canaries are the compiler-enforced feature vonbrand refers to. These can't be disabled without a recompile.
To prove this to yourself and see how they work take the following code:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
int mybadfunction(char* a_bad_idea)
{
char what[100];
strcpy(what, a_bad_idea);
printf("You passed %sn", what);
}
int main(int argc, char** argv)
{
printf("Tralalalaalan");
mybadfunction(argv[1]);
}
Now compile that (gcc -fstack-protector -masm=intel -S test.c
) into something gnu as would be happy to assemble and read the output. The important point is that on exit from the mybadfunction
function, there is this little piece of code:
mov edx, DWORD PTR [ebp-12]
xor edx, DWORD PTR gs:20
je .L2
call __stack_chk_fail
As you can guess, that's taking a stack cookie from [ebp-12]
and comparing it to the value at gs:20
. Doesn't match? It then calls a function __stack_chk_fail
in glibc which kills your program right there.
There are ways to work around this in terms of writing exploits, but the easy way in terms of building a shellcode test case is to compile your program with -fno-stack-protector
.
Non-executable pages
There are some other considerations on modern Linux systems. If you take the usual shellcode testing stub:
char buffer[] = {...};
typedef void (* func)(void);
int main(int argc, char** argv)
{
func f = (func) buffer;
f();
return 0;
}
modern GCC/Linux will map the .rodata
section of the PE file read only with no execute permissions. You need to turn that off, which can be done using the code sample from this blog post. Basic idea: you use mprotect
to add the permissions you want to the pages in which the shellcode data resides.
Non-executable stacks
If you are going to test a traditional exploit scenario, e.g. my bad code above, with your shellcode then you also need to ensure the stack is executable for the simple cases. The PE file format contains a field for determining whether the stack is executable — you can query and control this with execstack. To enable an executable stack, run
execstack -s /path/to/myprog
This can be done on arbitrary programs without needing a recompile, but won't automatically disable stack canaries as these are baked in on compile.
Added bonus: aslr:
To turn that off, echo 0 > /proc/sys/kernel/randomize_va_space
.
Did you just tell someone how to exploit my precious penguin?
No. Any exploit must work around stack canaries (very much non trivial) and either find a program with execstack
set, or set it (meaning it can already execute arbitrary commands anyway) or else use more difficult techniques, such as return to libc/return orientated programming.
add a comment |
To expand on what vonbrand has (correctly, +1) said, there are two parts to Linux's stack protection.
Stack canaries
Stack canaries are the compiler-enforced feature vonbrand refers to. These can't be disabled without a recompile.
To prove this to yourself and see how they work take the following code:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
int mybadfunction(char* a_bad_idea)
{
char what[100];
strcpy(what, a_bad_idea);
printf("You passed %sn", what);
}
int main(int argc, char** argv)
{
printf("Tralalalaalan");
mybadfunction(argv[1]);
}
Now compile that (gcc -fstack-protector -masm=intel -S test.c
) into something gnu as would be happy to assemble and read the output. The important point is that on exit from the mybadfunction
function, there is this little piece of code:
mov edx, DWORD PTR [ebp-12]
xor edx, DWORD PTR gs:20
je .L2
call __stack_chk_fail
As you can guess, that's taking a stack cookie from [ebp-12]
and comparing it to the value at gs:20
. Doesn't match? It then calls a function __stack_chk_fail
in glibc which kills your program right there.
There are ways to work around this in terms of writing exploits, but the easy way in terms of building a shellcode test case is to compile your program with -fno-stack-protector
.
Non-executable pages
There are some other considerations on modern Linux systems. If you take the usual shellcode testing stub:
char buffer[] = {...};
typedef void (* func)(void);
int main(int argc, char** argv)
{
func f = (func) buffer;
f();
return 0;
}
modern GCC/Linux will map the .rodata
section of the PE file read only with no execute permissions. You need to turn that off, which can be done using the code sample from this blog post. Basic idea: you use mprotect
to add the permissions you want to the pages in which the shellcode data resides.
Non-executable stacks
If you are going to test a traditional exploit scenario, e.g. my bad code above, with your shellcode then you also need to ensure the stack is executable for the simple cases. The PE file format contains a field for determining whether the stack is executable — you can query and control this with execstack. To enable an executable stack, run
execstack -s /path/to/myprog
This can be done on arbitrary programs without needing a recompile, but won't automatically disable stack canaries as these are baked in on compile.
Added bonus: aslr:
To turn that off, echo 0 > /proc/sys/kernel/randomize_va_space
.
Did you just tell someone how to exploit my precious penguin?
No. Any exploit must work around stack canaries (very much non trivial) and either find a program with execstack
set, or set it (meaning it can already execute arbitrary commands anyway) or else use more difficult techniques, such as return to libc/return orientated programming.
To expand on what vonbrand has (correctly, +1) said, there are two parts to Linux's stack protection.
Stack canaries
Stack canaries are the compiler-enforced feature vonbrand refers to. These can't be disabled without a recompile.
To prove this to yourself and see how they work take the following code:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
int mybadfunction(char* a_bad_idea)
{
char what[100];
strcpy(what, a_bad_idea);
printf("You passed %sn", what);
}
int main(int argc, char** argv)
{
printf("Tralalalaalan");
mybadfunction(argv[1]);
}
Now compile that (gcc -fstack-protector -masm=intel -S test.c
) into something gnu as would be happy to assemble and read the output. The important point is that on exit from the mybadfunction
function, there is this little piece of code:
mov edx, DWORD PTR [ebp-12]
xor edx, DWORD PTR gs:20
je .L2
call __stack_chk_fail
As you can guess, that's taking a stack cookie from [ebp-12]
and comparing it to the value at gs:20
. Doesn't match? It then calls a function __stack_chk_fail
in glibc which kills your program right there.
There are ways to work around this in terms of writing exploits, but the easy way in terms of building a shellcode test case is to compile your program with -fno-stack-protector
.
Non-executable pages
There are some other considerations on modern Linux systems. If you take the usual shellcode testing stub:
char buffer[] = {...};
typedef void (* func)(void);
int main(int argc, char** argv)
{
func f = (func) buffer;
f();
return 0;
}
modern GCC/Linux will map the .rodata
section of the PE file read only with no execute permissions. You need to turn that off, which can be done using the code sample from this blog post. Basic idea: you use mprotect
to add the permissions you want to the pages in which the shellcode data resides.
Non-executable stacks
If you are going to test a traditional exploit scenario, e.g. my bad code above, with your shellcode then you also need to ensure the stack is executable for the simple cases. The PE file format contains a field for determining whether the stack is executable — you can query and control this with execstack. To enable an executable stack, run
execstack -s /path/to/myprog
This can be done on arbitrary programs without needing a recompile, but won't automatically disable stack canaries as these are baked in on compile.
Added bonus: aslr:
To turn that off, echo 0 > /proc/sys/kernel/randomize_va_space
.
Did you just tell someone how to exploit my precious penguin?
No. Any exploit must work around stack canaries (very much non trivial) and either find a program with execstack
set, or set it (meaning it can already execute arbitrary commands anyway) or else use more difficult techniques, such as return to libc/return orientated programming.
edited Sep 28 '16 at 5:02
Jonathan Leffler
1,195914
1,195914
answered Mar 5 '13 at 10:07
user119
add a comment |
add a comment |
You can disable some protections (stack smashing detection and making the stack executable) with these options.
--z execstack
-f no-stack-protector
You can, also, turn off ASLR (address space layout randomization) with Bash with the command:
echo 0 > /proc/sys/kernel/randomize_va_space
add a comment |
You can disable some protections (stack smashing detection and making the stack executable) with these options.
--z execstack
-f no-stack-protector
You can, also, turn off ASLR (address space layout randomization) with Bash with the command:
echo 0 > /proc/sys/kernel/randomize_va_space
add a comment |
You can disable some protections (stack smashing detection and making the stack executable) with these options.
--z execstack
-f no-stack-protector
You can, also, turn off ASLR (address space layout randomization) with Bash with the command:
echo 0 > /proc/sys/kernel/randomize_va_space
You can disable some protections (stack smashing detection and making the stack executable) with these options.
--z execstack
-f no-stack-protector
You can, also, turn off ASLR (address space layout randomization) with Bash with the command:
echo 0 > /proc/sys/kernel/randomize_va_space
answered 1 hour ago
gotoatgotoat
367
367
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f66802%2fdisable-stack-protection-on-ubuntu-for-buffer-overflow-without-c-compiler-flags%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown