The majority of my cyber security background comes in the form of web application vulnerability testing, and whilst I do have a degree of prior experience in studying and performing application exploitations it has been several years since I last looked at the topic. Things have inevitably changed since then.

I was about to jump into the world of buffer overflows, stack overflows etc... with the numerous tutorials available online, and books like the Shell Coder's Handbook or Hacking The Art of Exploitation.

However, these seem relatively old, and I was wondering if the attacks are still possible today? To clarify, obviously there will always be vulnerable software which forgets to properly check input data's length, or uses vulnerable functions incorrectly, but given Windows 10 enforces DEP, ASLR and numerous other security features are these attacks still possible? Do any changes need to be made to the payloads, or other considerations?

This question is in regards to Windows only, and I am not as worried about antivirus software as that can be evaded easily with obfuscation.

  • it's a dying artform as things move further and further from "bare metal" into virtualized environments.
    – dandavis
    Aug 12, 2021 at 19:31

2 Answers 2


Unfortunately, yes, buffer overflow and similar attacks are still possible. Microsoft has found approximately 70% of security vulnerabilities are various forms of memory unsafety, including buffer overflows.

The techniques you've mentioned (DEP, ASLR, stack canaries, etc.) do definitely make exploitation more difficult, and in some cases, can prevent it entirely. But in many cases, it's still possible to craft exploits that can succeed.

If you're interested in learning about how to exploit these types of vulnerabilities, that skill is still valuable today and likely will be for a long time. The best way to prevent these types of attacks is the use of languages that are memory safe or nearly so, such as Rust or Go, which can almost entirely eliminate this class of vulnerabilities.

  • 1
    Do you have any programs + instructions for exploiting them, so I can see an exploitation working on Windows 10?
    – questioner
    Aug 12, 2021 at 22:35
  • Shellcode and buffer overflow exploits are typically not my skill set; I'm more interested in the prevention aspect, but hopefully someone else can provide a helpful response.
    – bk2204
    Aug 13, 2021 at 7:26

Yes, memory corruption vulns (buffer overflows, null pointers with large offsets, double-frees, arithmetic overflows used with a pointer, format string vulnerabilities, etc.) are still a thing, and are often still exploitable. There are a few ways, even on a system that enforces both DEP and ASLR and other modern protections. First of all, DEP (more generically, NX) has been defeated on its own for many years, through return-to-libc and more generically through return-oriented programming exploits. ASLR aims to defeat these by preventing malicious code from knowing the correct address to "aim at" for ROP gadgets or library functions. It's a strong protection, provided that it's enforced for all executable code in a process, but it's not always sufficient. A few ways around it:

  • Leak the ASLR mask from a known address. Suppose your exploit involves controlling a pointer offset from a heap variable, as many do. Suppose further that there's another heap variable a known distance away - say, 16 bytes earlier - that points to a specific function or data structure in a library is. You know what, absent ASLR, the value of that other variable would be. If you can leak the value of the other variable back to the attacking code (which ASLR doesn't prevent, because relative offsets on the heap will still be as expected), then the actual value of the other variable can be XORed with the expected value to derive the ASLR mask, which can then be XORed with the offset to the target(s) you would normally aim for to find their actual locations under that system's ASLR. Obviously this is more complicated, requiring a multi-step attack and a way to both read and write at least a little memory, but it happens.
  • Brute-force the ASLR mask. Until a few years ago, and even today on 32-bit processes, Windows used only fairly small masks (I believe just a single byte) for ASLR, which meant there were relatively few possible values by which addresses could be randomized. In other words, it was low entropy (8 bits, meaning 256 possible values). In the case that a process can be attacked many times (either it recovers from the memory failure, or more likely automatically restarts), the attacker could simply brute force all possible ASLR masks until they hit upon the correct one, at which point their payload runs instead of the vulnerable program getting an access violation exception and probably crashing. This doesn't work with 64-bit binaries linked with the (now-default) /HIGHENTROPYVA linker flag, which marks the binary as supporting 64-bit ASLR masks (a level of entropy that is almost certainly completely impractical to brute-force).
  • The attacker might already know the mask. All processes on a given machine run with the same ASLR mask. While this protects against attacks from remote computers, or fixed attacks that don't take the mask into consideration, it doesn't work if the attacker is another process on the same machine (perhaps trying to elevate privileges by attacking another user's process, or break out of a sandbox). It's trivial for a process to learn its own ASLR mask - just hard-code the default value of a function pointer or similar, and XOR it with the actual value - and it can use that to automatically patch an exploit to aim at the masked addresses in the target process.

These are just examples; there might be other classes of attack, and there are definitely other implementation methods (for example, the first class is especially easy with format string vulnerabilities, since the attacker can generally observe the resulting formatted string and can use that to inspect the value of arbitrary offsets on the stack, before launching an attack that attempts to actually overwrite a value). ASLR drastically raises the bar, and can make a previously-practical exploit impractical. It's not guaranteed to do so, though.

Also, of course, any such memory corruption vulnerability is a denial-of-service risk, because a DEP violation, or just landing on the wrong address due to ASLR, will almost certainly crash the process (it's technically possible to catch the exception, at least for an access violation, but the program will be so corrupted it's not usually worthwhile). DoS is not as bad as arbitrary code execution, but in some contexts (like a server, or a kernel-mode component) it's still potentially a very big deal! So that's a way that you can definitely attack a system with buffer overflows and similar.

  • When was DEP and/or ASLR enabled by default on Windows? IIRC it was Windows 8. Also, are you saying older programs from the days of Windows Vista will not have compiler flags to enable DEP and ASLR, which means older software is still vulnerable? I always thought Windows did this to all running programs, and not that programs had to enable this protection themselves. Last question, is how would I know which programs are running on my computer without DEP and/or ASLR?
    – questioner
    Aug 13, 2021 at 15:51
  • I remember reading in The Antivirus Hacker's Handbook that a Spanish antivirus company called Panda forgot to enable a security feature on just one module, this in turn allowed people to hack the AV and bypass it LOL. So I think both ASLR and DEP are enabled by the program, not the OS, but that book is so old.
    – questioner
    Aug 13, 2021 at 15:57
  • @questioner DEP was added to Windows with Windows XP and Windows Server 2003. I believe it was XP SP2 specifically that added support for the NX bit ("hardware-based DEP). DEP is opt-in (via a linker flag) by default, but has been set by Windows compilers by default for a very long time, and can be forced on. ASLR was added with Vista and Server 2008, and enhanced with additional protections in subsequent versions notably including Windows 8 and 10.
    – CBHacking
    Aug 14, 2021 at 3:09
  • @questioner DEP is process-wide setting, controlled first by the OS and then, if the OS doesn't force it on or off, by linker-set flags on the executable. ASLR is per module (that is, EXE or DLL or SYS or so on), although it is possible to force it on for all modules in a process or all processes on a system. It's enabled in the linker by default since 2010, but some very old libraries don't have it and, if mandatory ASLR is not active, then loading just one of those libraries in a process will enabled ROP exploits.
    – CBHacking
    Aug 14, 2021 at 3:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .