Results 1 to 8 of 8

Thread: Stack executability

Hybrid View

  1. #1
    Just burned his ISO
    Join Date
    Sep 2007
    Posts
    3

    Default Stack executability

    Hi, I'm not really new to hacking/programming in general, but I am a newb when it comes to Linux. I'm messing around with buffer overflows on a BT install, but it isn't working. I don't think there is anything wrong with my exploit, so I was wondering if the stack is set to non-executable by default, either by gcc or the kernel, and if it is, how I would go about changing that (I'm hoping that's the problem, if not it means my exploit is ****ed)?

    Also, much thanks to the creators of BT for making their platform so accessible.

    Regards.

  2. #2
    Developer
    Join Date
    Mar 2007
    Posts
    6,124

    Default

    Quote Originally Posted by nullbashr View Post
    Hi, I'm not really new to hacking/programming in general, but I am a newb when it comes to Linux. I'm messing around with buffer overflows on a BT install, but it isn't working. I don't think there is anything wrong with my exploit, so I was wondering if the stack is set to non-executable by default, either by gcc or the kernel, and if it is, how I would go about changing that (I'm hoping that's the problem, if not it means my exploit is ****ed)?

    Also, much thanks to the creators of BT for making their platform so accessible.

    Regards.
    You'll have to be more clear. Are you attcking Backtrack from another machine or what? Are you attempting a buffer over flow on the kernal or a certain program? and lastly why? As we have said many times backtrack is a pentesting distro. it is not meant as a standalone OS therfore it would not normally be under attack.

  3. #3
    Developer balding_parrot's Avatar
    Join Date
    May 2007
    Posts
    3,399

    Default

    Quote Originally Posted by purehate View Post
    You'll have to be more clear. Are you attcking Backtrack from another machine or what? Are you attempting a buffer over flow on the kernal or a certain program? and lastly why? As we have said many times backtrack is a pentesting distro. it is not meant as a standalone OS therfore it would not normally be under attack.
    It sounds to me like he is attacking the backtrack kernel from another machine, but it isn't clear.

  4. #4
    Just burned his ISO
    Join Date
    Sep 2007
    Posts
    3

    Default

    I'm attacking a contrived test program locally. I think it should be working, because I have carried out similar attacks on Windows successfully, but unfortunately I do not know how to work gdb very well. I am learning, but in the meantime I am reduced to just guessing what the problem is.

    I don't see why it matters how I am attacking, all I was really asking is whether the stack in Backtrack 2 is set to non-executable by default. Sorry if that was unclear.

  5. #5
    Developer
    Join Date
    Mar 2007
    Posts
    6,124

    Default

    Quote Originally Posted by nullbashr View Post
    I'm attacking a contrived test program locally. I think it should be working, because I have carried out similar attacks on Windows successfully, but unfortunately I do not know how to work gdb very well. I am learning, but in the meantime I am reduced to just guessing what the problem is.

    I don't see why it matters how I am attacking, all I was really asking is whether the stack in Backtrack 2 is set to non-executable by default. Sorry if that was unclear.
    I'm not really sure about your question but what I do know is that muts and the guys would not reave backtrack open to any script kiddie exploits or buffer over flows. What you really should be researching is the slax kernal. i personally have no intrest in attempting a stack overflow on my backtrack kernal but please update us as to how you get on.

  6. #6
    Member imported_blackfoot's Avatar
    Join Date
    Jun 2007
    Posts
    386

    Default Nonsense

    Your comments and question are utter nonsense.

    Firstly, gcc is a compiler for the 'C' programming language.

    Secondly, gdb is the general debugger. Its use is trivial.

    Thirdly, your professed expertise in hacking and programming is doubted by virtue of your composition.

    The use of expletives is unnecessary here. Your so-called exploit is probably as you say...unworkable given the current comments.

    The stack is commonly exploited or referenced as a program stack. Each program modifies it as part of its function. It is used commonly as a means of recursion for subroutines and memory contents subject to frequent change by the program.

    Linux is a very stable platform from which to conduct cross-platform executions. However, it is always open to attacks on the kernel just like any other system not because of inherent weaknesses in itself, but through poor programming and input capture control of programs in the user space. The tightest implementation is a unix variant named OpenBSD. It is conceivable that there are deficiencies in stack execution of this slax-based operating system but, frankly, I doubt it, since it utilises the common linux kernel, (see kernel.org). The linux kernel is absolutely unlike the Windows Operating System. One can never presume that behaviour in one will be mirrored in another. Porting applications across platforms is not trivial.

    I feel that the thread can now be terminated but do expand on any particular point which remains unclear.
    Lux sit

  7. #7
    Just burned his ISO
    Join Date
    Sep 2007
    Posts
    3

    Default

    blackfoot, what the **** are you talking about? It's apparent that you do not know what you are talking about.

    Quote Originally Posted by blackfoot
    Firstly, gcc is a compiler for the 'C' programming language.
    Good job. When you compile a program it is converted into machine code, then linked as an executable for a particular operating system, in this case elf format for linux. I was not sure if setting stack executability was handled directly by the kernel, or set as an optional header in the elf format. I'm a Linux newb, I wasn't sure, so I allowed for that possibility.

    Quote Originally Posted by blackfoot
    Secondly, gdb is the general debugger. Its use is trivial.
    Actually it stands for "GNU debugger". YOU are trivial.

    Quote Originally Posted by blackfoot
    The use of expletives is unnecessary here. Your so-called exploit is probably as you say...unworkable given the current comments.
    You haven't seen the program nor the exploit, nor do you know anything about me... how can you say a ****ing thing about its workability? If you want technical details on the program and the exploit, I will gladly supply them, but they will most likely be over your head, given the ignorance you exhibit in your post.

    Quote Originally Posted by blackfoot
    The stack is commonly exploited or referenced as a program stack. Each program modifies it as part of its function. It is used commonly as a means of recursion for subroutines and memory contents subject to frequent change by the program.
    I know what a stack is, jackass.

    Do you know anything about exploitation? The simplest technique for exploiting a vulnerability (specifically buffer overflow) is to place your shellcode into the same buffer you overflow to overwrite the stack. Your overflow, in the simplest case overwriting a return address for a function (which are stored on the stack by the "call" operation, assuming we are talking about x86 assembly), causes the program to return into your shellcode, which at this point exists on the stack, when the function attempts to return to its caller (in x86, it uses the "ret" operation, which pops the return address off the stack and jumps to it). If the stack is set to non-executable, you will get a segmentation fault (which is what I'm getting right now). Otherwise, your shellcode will be run.

    Quote Originally Posted by blackfoot
    Linux is a very stable platform from which to conduct cross-platform executions. However, it is always open to attacks on the kernel just like any other system not because of inherent weaknesses in itself, but through poor programming and input capture control of programs in the user space. The tightest implementation is a unix variant named OpenBSD. It is conceivable that there are deficiencies in stack execution of this slax-based operating system but, frankly, I doubt it, since it utilises the common linux kernel, (see kernel.org). The linux kernel is absolutely unlike the Windows Operating System. One can never presume that behaviour in one will be mirrored in another. Porting applications across platforms is not trivial.
    First of all, I am not exploiting the kernel, I am exploiting a user-space application. Second of all, I am not porting anything, but even if I were it is just a simple C program that I am exploiting so yes, it would be trivial. Third of all, I am exploiting the program within the context of Linux, NOT Windows, so I am not making the presumption that one behavior will mimic the other.

    Quote Originally Posted by blackfoot
    I feel that the thread can now be terminated but do expand on any particular point which remains unclear.
    Shut the **** up, you know nothing. You don't get to tell the mods what to do, and you are completely talking out of your ass. Either eat some humble pie, or **** off. kthxbye.

    P.S. I use expletives by default, because I can. If it offends you, cry me a river.

    Quote Originally Posted by purehate
    I'm not really sure about your question but what I do know is that muts and the guys would not reave backtrack open to any script kiddie exploits or buffer over flows. What you really should be researching is the slax kernal. i personally have no intrest in attempting a stack overflow on my backtrack kernal but please update us as to how you get on.
    Okay, thanks for your help. I will do that.

  8. #8
    Developer balding_parrot's Avatar
    Join Date
    May 2007
    Posts
    3,399

    Default

    This behaviour has gone too far, so I am putting an end to it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •