Self-propagating heap memory crawler in x86-64 Linux Assembly(pastebin.com)
pastebin.com
Self-propagating heap memory crawler in x86-64 Linux Assembly
http://pastebin.com/rtGeDEmC
3 comments
In answer to your two questions:
1: Yes, you will eventually need to mmap more memory. Since you want to minimize the number of mmap calls necessary for things like heap allocations, you generally allocate in larger chunks then necessary and then malloc etc. allocates from these chunks. It doesn't matter too much in terms of memory waste, since in the back end, linux allocates physical memory lazily, so the extra allocated block of virtual memory doesn't get a physical allocation until something tries to access it. For this reason, it can sometimes seem like a malloc call completes successfully, but you run into an out of memory condition once you try to actually use your "successfully" allocated memory.
2. It turns out most kernels don't actually enable the NX bit automatically, with the reason given being that early processors have buggy implementations, so by default the NX flag is not honored. As a result, all memory is executable by default, unless explicitly set not to be (i.e. using memprotect), and this is only if the kernel is compiled to support NX, which it may not be. This is changing, and some systems such implementing SELinux or similar are supposedly stricter but I haven't actually tested this out myself.
1: Yes, you will eventually need to mmap more memory. Since you want to minimize the number of mmap calls necessary for things like heap allocations, you generally allocate in larger chunks then necessary and then malloc etc. allocates from these chunks. It doesn't matter too much in terms of memory waste, since in the back end, linux allocates physical memory lazily, so the extra allocated block of virtual memory doesn't get a physical allocation until something tries to access it. For this reason, it can sometimes seem like a malloc call completes successfully, but you run into an out of memory condition once you try to actually use your "successfully" allocated memory.
2. It turns out most kernels don't actually enable the NX bit automatically, with the reason given being that early processors have buggy implementations, so by default the NX flag is not honored. As a result, all memory is executable by default, unless explicitly set not to be (i.e. using memprotect), and this is only if the kernel is compiled to support NX, which it may not be. This is changing, and some systems such implementing SELinux or similar are supposedly stricter but I haven't actually tested this out myself.
1. Elaborate more on this, as this doesn't agree with my understanding of it. Glibc Malloc allocates differently depending on the size of the allocation -- glibc uses dynamic mmap thresholds, which as I previously stated starts at 128kb, but when blocks larger than the current threshold are freed, the threshold is adjusted to the size of the freed block, unless once again, you've set any of the slew of paremeters that disable the threshold in which case you'll go back to either "old school" brk() memory management by storing current and previous results of sbrk(0) or you will have arenas for small allocations managed through mmap().
2. If only this were true, I regularly pine for the days of EIP -> 0xc0c0c0c0. It is true that some compilers generate entirely RWE memory pages, but usually for much different reasons (Executable stacks for GCC trampolines, for example)
2. If only this were true, I regularly pine for the days of EIP -> 0xc0c0c0c0. It is true that some compilers generate entirely RWE memory pages, but usually for much different reasons (Executable stacks for GCC trampolines, for example)
At a guess: eventually, yes. I don't think this actually writes over the heap at all - it writes to the .bss section instead. In theory, if left to execute (without the INT3s) it'd probably segfault as soon as it hit the end of the page containing .bss.
malloc could be used to expand the heap, which conveniently appears after .bss. The pointer returned would probably still need to be followed, since heap allocations might not be contiguous (and mprotect needs to be used to mark the pages executable).
malloc could be used to expand the heap, which conveniently appears after .bss. The pointer returned would probably still need to be followed, since heap allocations might not be contiguous (and mprotect needs to be used to mark the pages executable).
Not necessarily, you can continually write until you hit the end of the uninitialized data segment, which is typically 128kb (or MMAP_THRESHOLD) after the last heap allocation (that itself was under 128kb, otherwise the memory will be, as you state, mmapped, which has no contiguity guarantees)
Done correctly, you don't even need to use assembly to do this sort of thing. http://stratiger.com/cpup4.c is a straightforward C member of the same category of programs.
For anyone trying this, there's a typo in the URL, it is actually http://stratigery.com/cpup4.c
A fork bomb will also reproduce a program until you run out of memory, and actually stand a better chance of crashing the system if that was your goal.
Did you even read what it does, or are you just spouting out other arbitrary ways to crash systems?
There are a host of ways to run out of memory and crash a system. Why not list every single example, if that's your intention, because the fact that it runs a machine out of memory is about the only thing it has in common with a fork bomb.
In fact, a fork bomb doesn't even imply the system runs out of memory, but only that the system runs out of a finite resource.
There are a host of ways to run out of memory and crash a system. Why not list every single example, if that's your intention, because the fact that it runs a machine out of memory is about the only thing it has in common with a fork bomb.
In fact, a fork bomb doesn't even imply the system runs out of memory, but only that the system runs out of a finite resource.
That wasn't his goal. He was teaching himself assembly on x86 Linux and this was more interesting to him than adding two numbers together...
Copy on write!
Also, it seems weird to me that the heap pages are marked as executable by default.