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;
}







9















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?










share|improve this question































    9















    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?










    share|improve this question



























      9












      9








      9


      10






      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?










      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 4 '13 at 22:52









      Gilles

      556k13411421651




      556k13411421651










      asked Mar 4 '13 at 11:01









      PhatePhate

      1572410




      1572410






















          3 Answers
          3






          active

          oldest

          votes


















          6














          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...






          share|improve this answer



















          • 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



















          24














          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.






          share|improve this answer

































            0














            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





            share|improve this answer
























              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
              });


              }
              });














              draft saved

              draft discarded


















              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









              6














              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...






              share|improve this answer



















              • 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














              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...






              share|improve this answer



















              • 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








              6







              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...






              share|improve this answer













              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...







              share|improve this answer












              share|improve this answer



              share|improve this answer










              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














              • 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













              24














              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.






              share|improve this answer






























                24














                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.






                share|improve this answer




























                  24












                  24








                  24







                  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.






                  share|improve this answer















                  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.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Sep 28 '16 at 5:02









                  Jonathan Leffler

                  1,195914




                  1,195914










                  answered Mar 5 '13 at 10:07







                  user119






























                      0














                      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





                      share|improve this answer




























                        0














                        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





                        share|improve this answer


























                          0












                          0








                          0







                          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





                          share|improve this answer













                          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






                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered 1 hour ago









                          gotoatgotoat

                          367




                          367






























                              draft saved

                              draft discarded




















































                              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.




                              draft saved


                              draft discarded














                              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





















































                              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







                              Popular posts from this blog

                              Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

                              Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

                              Ciclooctatetraenă Vezi și | Bibliografie | Meniu de navigare637866text4148569-500570979m