Hot answers tagged

146

Address Space Layout Randomisation (ASLR) is a technology used to help prevent shellcode from being successful. It does this by randomly offsetting the location of modules and certain in-memory structures. Data Execution Prevention (DEP) prevents certain memory sectors, e.g. the stack, from being executed. When combined it becomes exceedingly difficult to ...


37

To complement @Polynomial's self-answer: DEP can actually be enforced on older x86 machines (which predate the NX bit), but at a price. The easy but limited way to do DEP on old x86 hardware is to use segment registers. With current operating systems on such systems, addresses are 32-bit values in a flat 4 GB address space, but internally each memory access ...


13

While the accepted answer is correct in suggesting moving everything to a different function does not explain why. As you can see in this question and answer main() functions often perform a stack alignment to ensure that the stack is setup properly. The following instruction is performed: 83 e4 f0 and esp, 0xfffffff0 This will align ...


13

"Leaky Pointers" or more commonly known as "Dangling Pointers" is useful to create an attack chain to bypass a layered security system. The idea behind DEP is that you are making regions of memory non-executable, such that shellcode in this area cannot be executed. DEP alone is really easy to bypass, you can just ret-to-lib, and call any function you ...


8

The x86-compatible CPU are aptly named: they are compatible with each other. This means that the same OS code will work on all of them. So, from the point of view of the code which runs on the processor (which includes the operating system itself), things do not vary (much) depending on the brand. Things change depending on the generation: the newer systems ...


8

On a linux box with an Intel CPU, lets say I compiled by binary with -fstack-protect-all. Since it is not explicitly stated, it will be assumed that this refers to ELF binaries compiled using GCC with the -fstack-protector-all argument. GCC Stack Protection Mechanisms -fstack-protector-all is an extension of -fstack-protector: -fstack-protector ...


7

A buffer overflow (of the "write" kind) gives any advantage to an attacker only if the attacker can arrange for the overflow to spill over other bytes that are used for something else. At any time, the process runs in an address space, most of which being unallocated. If the buffer which is overflown is at the end of the address space, or is followed only by ...


7

W^X and "Once-writable, never executable" are both sub-cases of DEP. DEP is about making read accesses, and execution accesses, distinct (a writable page is also a readable page). W^X is about using DEP to enforce a specific policy, which is that a given page can never be writable and executable at the same time. Compliance to the W^X policy can be required ...


6

It's primairly a question of cost-benefit analysis on the hardware manufacturer's side, and a question of risk analysis on the behalf of OS vendors. The x86 architecture has provided memory page access rights as far back as the 80386, but at that time such hardware enforcement would have been expensive to implement in the hardware, and wasn't seen as ...


5

ASLR involves randomizing the location of objects in memory. For instance, the heap might be moved to a random offset in memory. If you somehow manage to learn the address of an object in the heap, then you've gained a lot of information about the location of the heap in memory. This may be enough to enable you to predict the location of other objects in ...


4

Your example does segfault here (or cause the program termination if the stack protector is active). Maybe you should try to move the buffer overflow into another function. Perhaps your gcc version is converting return 0; from main into exit(0);.


3

Actually, I found the problem. This is about the fact that the address of this gadget contains 0a which corresponds to a \n


3

I have never debugged the kernel, so I may be wrong, but I believe that what you are seeing makes complete sense. Let's go through it: add BYTE PTR [rax],al why is that? is this because I'n in virtual machine? That is what I would actually expect from 0x0000. This is easy to test: [~]$ uname -a Linux haps 4.7.6-1-ARCH #1 SMP PREEMPT Fri Sep 30 ...


3

NX bit is for AMD architecture and XD is for Intel. You want to know if a page is executable, basically. vmmap <pid or partial process name> will list out memory chunks permissions. You can check for ASLR (PIE, to be correct) in OS X by using otool -hv <file_path> and checking out the "PIE" flag. For example my i386 Wireshark has no PIE flag (...


3

The text segment which is also called the code segment, contains the application's static functionality is not randomized by ASLR. An exploit can jump anywhere into this region of memory reliably, which permits an attacker to build a chain of ROP gadgets. The most common goal of a ROP chain is to setup a stable environment to run shell code, but that is ...


3

Yes, absolutely, of course it is possible to use gadgets that are from the executable itself. You can use any code that is mapped into the address space of the program in executable form (i.e., where it's possible to execute the code -- if the system is using DEP, this excludes anything that has the non-executable bit set). That includes the original ...


3

I believe the reason is "it's easiest to use instruction sequences from the libraries, because the libraries are so common and they've already been scanned." There are just a handful of Microsoft-provided C-runtime library files. If they provide a complete enough instruction set, why work harder?


2

http://www.exploit-db.com/wp-content/themes/exploit/docs/17505.pdf Using SEH to achieve exploitation defeats neither DEP nor ASLR. In particular, DEP will mitigate execution of shellcode off the stack memory page which, ultimately, it was what an SEH based exploit is trying to achieve. Without a non-ASLR module in the process spacing being used to locate ...


2

Exploit developers use ROP chains when there is no other option. ASLR limits where an exploit can jump reliably, as the heap and stack address will be randomized. However, some of the application's own functionality may not be randomized. When an attacker is forced into this position, they use a series of ROP gadgets to establish an environment that can ...


2

Update: see https://stackoverflow.com/questions/24984955/why-arent-glibcs-function-addresses-randomized-when-aslr-is-enabled Compile the binary using -fPIE or -fPIC -pie -fPIE: https://stackoverflow.com/questions/2463150/fpie-position-independent-executable-option-gcc-ld Binary compiled with default flags: user01@user01 ~/test $ ./test_ASLR printf ...


2

Assuming you're building a ROP chain that needs to manipulate the stack, you can always go for semantically equivalent gadgets, e.g. PUSH/POP, MOV ESP XXX, (SUB,ADD) ESP instructions to build the stack: https://www.corelan.be/index.php/2010/06/16/exploit-writing-tutorial-part-10-chaining-dep-with-rop-the-rubikstm-cube/#chainingbasics http://neilscomputerblog....


1

There are a few points to note: 1. The strcpy function stops copying stuff into the destination buffer as soon as it encounters a NULL byte. A NULL byte is 0x00 or \x00. In 64-bit machines, the length of an address is 8 bytes. Let us consider pop_rdi_ret = 0x00000000004005cb. This has NULL bytes. So, as soon as strcpy encounters the first NULL byte(the ...


1

I feel like I had the same issue but managed to get it working in my case. The module with the overflow had DEP enabled so I thought it wasn't going to work. All I did was point EIP to a JMP ECX in nSEH and SEH just to be sure but it wasn't working. After thinking hope was lost I realized in my case there was an irrecoverable exception and it wasn't ...


1

GCC's stack protection is software-based, and isn't related to DEP's hardware-based protection. When an OS enables DEP, all programs running on it (or some subset defined by the user) are automatically protected through hardware flags, regardless of any compiler flags used to build the binary. When the stack protection flags are enabled in GCC, it provides ...


1

Not all buffer overflows lead to remote code execution. It depends on how the buffer is allocated, and if the instruction pointer can be controlled by the attacker. There are many factors that go into whether or not remote code execution is a possibility.


1

Finding functions come in two flavors: Exported - Super easy. In Windows use HANDLE kernel32 = GetModuleHandle(L"kernel32"); FARPROC funcAddr = (FARPROC *) GetProcAddress(kernel32, "SetProcessDEPPolicy"); This will return the address of the function if it's exported by the module, in this case the module is kernel32. Non-exported - Annoying The first ...


1

It depends. DEP blocks you from just doing a jump to esp and executing code there. ASLR is your major important thing to bypass here. There are a number of ways that you might be able to do this: Modules loaded into the process which don't have ASLR enabled. There are a bunch of ways this might happen: DLLs that are a part of your application which were ...


1

Assuming that the shellcode is on the stack, we do not place the address of the shellcode in the address of the exception handler (what you called the "return address") because Windows has a some basic defence mechanism that prevents exceptions from jumping to addresses on the stack. SEH was abused commonly and repeatedly, and so it was created. Today, ...


1

The memory itself is agnositic. The operating system defines what each area is used for. So windows "knows" because it said it was so.


1

According to a similar question on StackOverflow, the error codes are architecture specific. The codes should be documented in arch/*/mm/fault.c as part of the kernel source code.


Only top voted, non community-wiki answers of a minimum length are eligible