Tag Info

Hot answers tagged

34

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


16

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


10

Although the details greatly vary between architectures, what I say here applies equally well to 32-bit x86, 64-bit x86, but also ARM and PowerPC: faced with the same issues, about all architecture designers have used similar solutions. There are (roughly speaking) four kinds of "accesses", at assembly level, which are relevant to the ...


8

ASLR is a hide-and-seek game: in case the attacker succeeds in overflowing a buffer and overwriting pointers, the OS loads the application code (the main executable and its DLL) in randomized locations, so as to make it harder for the attacker to actually hit a meaningful location. By construction, it works better when the playground is larger. The extended ...


7

ASLR on 32-bit is rather limited, but I think what you're seeing is an artefact of the system ASLR bias value. Upon boot, a bias value is randomly generated for that "instance" of Windows running. Although parts of the address may seem to be the same across instances of the same process, they're actually just fed from the bias value, and that value will ...


7

HiASLR is a term that represents the improved ASLR in Windows 8. The "hi" part refers to the improvement in entropy generated by the increased number of random bits that the stack and heap can be offset by. Microsoft also included randomisation to various system heaps, system tables, etc. to make the possibility of using a NOP sled or information leak more ...


6

When debugging some C code, especially tracking down after-free-accesses bugs, address space randomization is quite inconvenient, because it makes bugs non deterministic. By turning it off, you can much more easily reproduce the issues. That's a good reason to turn it off on development machines (as opposed to production systems). As for the slowing down, ...


6

There is some good information here. Apparently, a DLL can be subject to ASLR only if it is tagged as such, because of "backward compatibility issues". Although a DLL is, by nature, meant to be relocated, I can imagine that some (poorly) written software may do some tricks which rely on the DLL ending up in a relatively small range of the address space (a ...


5

In addition to what @Polynomial explains (which may or may not apply, depending on whether you are running Windows or some other operating system), ASLR swaps around pages: that's what the MMU knows about. A page is 4 kB (on x86 processors) so the low 12 bits of addresses are not impacted by ASLR. This leaves at most 20 bits for ASLR to play with. Address ...


4

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


4

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


4

If you just want to know if one DLL supports ASLR, then load it into CFF Explorer, go to the Optional Header section, then click on the DllCharacteristics row. If "DLL can move" is checked, then it's ASLR-enabled, otherwise it's not. If you want to do a lot of them, I would write a Python script that enumerates all DLLs in a target directory, then checks ...


4

One reason why some Linux distributions may be hesitant to compile all executables as Position-Independent Executables (PIE), so the executable code is randomized, is because of concerns about performance. The thing about performance concerns is that sometimes those concerns: sometimes people worry about performance even when it's not an issue. So, it ...


3

Thanks to @Polynomial for that excellent pefile module suggestion. I threw together a quick python script to do this. There is probably room for improvements but it seems to work decently enough. import argparse import os import pefile class DllCharacteristics(): def __init__(self): self.IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE = False ...


3

You do not call functions inside the kernel. The kernel resides in another privilege level; its memory pages are not accessible from normal code. To jump into kernel code, application code performs a system call which entails using a specific doorway which handles the temporary privilege escalation. On a 32-bit x86 system running Linux, this is done with int ...


2

The globalbuf variable is an uninitialised static variable, so its virtual address is not randomised. I know that uninitialized global and static variables are part of BSS section; and therefore I assume that BSS, Text and Data sections are not being randomized by ASLR. The BSS section is not randomised because it is marked as uninitialised data. This ...


2

CWE doesn't enlist lack of ASLR explicitly as an entry, but I believe it definitely comes under "Security Misconfiguration" CWE-815 as Rook has stated above. Additionally, I wanted to add that Buffer Access Using Size of Source Buffer CWE-806 clearly recommends it as one of multiple necessary measures for system hardening against overflow based attacks. The ...


1

Fairly obvious why the position-dependent executables aren't randomized. "Position dependent" simply means that at least some addresses are hardcoded. In particular, this may apply to branch addresses. Moving the base address of the executable segment moves all branch destinations as well. There are two alternatives for such hardcoded addresses: either ...


1

Despite having thousands of entries, the CWE system is not granular enough to express this specific violation. However, there are more general CWE families that could help. CWE-2: Environment looks like the right parent node, or perhaps CWE-815 Security Misconfiguration would be more exact.


1

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


1

No. ASLR is an important part of kernel security. Non-root users are not supposed to be able to turn off ASLR. The only way you're likely to be able to do it is to exploit a privilege escalation vulnerability to get root (as @Polynomial says), or exploit some other vulnerability in the system.


1

There's not too much to be gained in actually exploiting it just for a demo. You should be able to demo making your system crash from a phone borrowed from your audience, and that should adequately appall your viewers. If you really want the dogs and ponies to bark and trot, you could rig the demo using rebase on your module. That will let you move the ...



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