Hot answers tagged

3

RoRaZ and 40F4 made some real good points. Another thing is, that especially in the health sector or finance sector, respectively in any enterprise that needs to use software specially crafted for their exquisite usage, it sometimes might not be possible to update the operating system without causing bugs in essential and expensive software that cannot be ...


2

Most modern systems have a Memory Management Unit, or MMU. The MMU is responsible for translating physical addresses to virtual addresses. This is used to give each process its own private virtual memory. One process' address X is not the same as another process' address X. This improves performance, security, and reduces the risk of crashes, but it also has ...


2

you can check if a binary is compiled with PIE stack protection fortify source RO relocations Immediate binding by using hardening-check. E.g. hardening-check $(which sshd) Package devscripts contains the hardening-check On Debian testing i get the following output: root@root:~# hardening-check $(which sshd) /usr/sbin/sshd Position Independent ...


2

ASLR relies on features of the memory management unit of the CPU to map a physical page (i.e. at the hardware level) to an address in the virtual address space (which is the memory layout as seen by the current process). Since this CPU feature only work at the page level it is not possible to get a finer granularity from the CPU. Finer granularity would ...


2

Yes, it is indeed a two step process. That means the target process must indeed provide some means for you to interact with it in multiple steps. Basic exploitation exercises are often limited in that they do not provide much in terms of interaction, but a real target will most often provide some means to establish a session or exchange messages. For example,...


2

I recommend reading Smashing The Stack For Fun And Profit by Aleph One, which includes some examples of how it is done. How does the hacker then get the address of where it is? By using a debugger and disassembly of the program, examining assembly instructions. One of the particular things of interest, as in the referenced article, is Stack Pointer: ...


2

Because you're not saying anything about RelRO, I'm assuming no RelRO (so no leaking of the address of strcpy because it isn't called yet). Yet, this doesn't matter much, here's why: You say PIE is enabled, which in combination with ASLR will randomize the location of the binary in memory and thus the location of the PLT and GOT. Hence you cannot leak from ...


2

It depends on your definition of "exploit", what piece of software you're targeting, and where the bug is. For example, if I found a bug in Chrome's renderer (i.e. the thing that draws webpages on your screen) that gave me code execution, I'd only have code execution in the sandboxed context of the renderer process that runs in low integrity mode. I'd then ...


1

ASLR randomizes the addresses of critical parts of the processes memory, i.e. stack, heap and where libraries are loaded in order to make it unpredictable where a specific piece of code or data structure is located. But this kind of knowledge is not needed in the first place to exploit Heartbleed. The Heartbleed vulnerability relies on an out of bounds ...


1

Assuming ASLR is disabled, an attacker could just open a disassembler and look for the address where the shellcode has been stored. This can be easily done by setting a breakpoint just after the user input and then printing the stack in order to find your payload. In gdb you can run: x/100xg $rsp or in 32 bit: x/100xw $esp. If you are having problems with ...


1

You have to grab your libc binary and compute the offset in bytes from __libc_start_main+247 to the function you want to call. ASLR randomizes the base address from where the module is loaded, but it cannot randomize internal offsets between elements inside the module itself. You can find this offset in gdb by executing print system - __libc_start_main+247 ...


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


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