Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/retr0kr0dy/malloc-bomb

Presenting the latest Linux bomb exploit: not a fork but a malloc-based threat. Delve into the intricacies of this novel vulnerability.
https://github.com/retr0kr0dy/malloc-bomb

coding cybersecurity denial-of-service dos exploit forkbomb hacking infosec linux malloc pentesting security system-exploitation vulnerability

Last synced: about 1 month ago
JSON representation

Presenting the latest Linux bomb exploit: not a fork but a malloc-based threat. Delve into the intricacies of this novel vulnerability.

Awesome Lists containing this project

README 

        
# malloc-bomb



![](mehh.jpg)



# Summary



- [What is this?](#What-is-this?)

- [Why?](#Why?)

- [How?](#How?)

- [Remediation](#Remediation)

- [Usecases](#Usecases)



# What-is-this?



Do you remember `:(){ :|:& };:` forkbomb?  funny indeed but  not as much as what we could do.



This forkbomb defines a shell function that recursively calls itself creating an exponential number of child processes until system resources are exhausted.



What if we used the following malloc bomb instead?



```sh

while true; do echo $(*    | Return content of file.                                                             | `echo < a.txt`          | `AAA`                                                  |

| */dev/zero*      | Kernel special device file that provides an endless stream of null bytes when read. | `cat /dev/zero`         | no output (only `\00` so it's not printed in terminal) |



Now that we are good with what each individual command does we can now try to understand the malloc bomb and why it's a malloc bomb.



When the `<...` try to read the `/dev/zero` content to return it to the `$(...)` statement it first needs to allocate memory before reading it.



When the kernel tries to allocate memory it comes to a point where no more memory can be allocated, therefore, stalling any new process attempting to be created.



If you are a player you can still kill the process that initiate the bomb, it will also stop every child process thus ending the denial of service. 



> [!NOTE]

Technical explanation could be either partially wrong or not fully accurate, if you want to rephrase and/or improve it, feel free to **PR**.



# Remediation



Blocking this bomb on your system is pretty easy and straight forward.



Simply use `ulimit` command to block the maximum virtual memory allocated by a process and the maximum number of processes that a user can create.



```sh

ulimit -v 1048576 # Limit virtual memory alloation for each process to 1GB

ulimit -u 10000 # Limit user created processes to 10,000

```



Or



Removing read permission on `/dev/zero` (not advisable). But, if something other than root needs `\00` to be returned, it **WILL** cause issues. It should be funny to see.



> [!WARNING]

This is a really bad fix. Do this only if you are dumb.



# Usecases



#### Whenever you have access to linux shell



Just slap the command in the prompt no permission needed, no weird bin needed, only linux shell syntax abuse.



#### Boot?



You could modify the init script of a system to execute this malloc bomb during the boot sequence, thus, stalling the system without easy/verbose debug axis (beside viewing diff in init script...) and never breaking a the same moment.



---

*Discovered with fun by akpalanaza*



##### References :



- https://docs.kernel.org/admin-guide/cpu-load.html

- https://docs.kernel.org/admin-guide/device-mapper/zero.html