11 Characters That Crash Any PC: the Fork Bomb!
Вставка
- Опубліковано 27 сер 2024
- Dave explains fork bombs, what they are, how they work, the damage they can do, and why they're called fork bombs. By using infinite parallel recursion a fork bomb can bring any Windows, Linux, or Mac machine, and Dave explains which machines can be easily protected against fork bombs and which remain vulnerable.
For information on my book, "Secrets of the Autistic Millionaire":
amzn.to/3diQILq
My other channel, join now so you're there for episode 01 of my AudioBook!
/ @davepl
Discord Chat w/ Myself and Subscribers: / discord
Primary Equipment (Amazon Affiliate Links):
* Camera: Sony FX-3 - amzn.to/3w31C0Z
* Camera Lens: 50mm F1.4 Art DG HSM - amzn.to/3kEnYk4
* Microphone: Electro Voice RE 320 - amzn.to/37gL65g
* Teleprompter: Glide Gear TMP 100 - amzn.to/3MN2nlA
* SD Cards: Sony TOUGH - amzn.to/38QZGR9
Weighing in here: One of July's most informative videos on the entire UA-cam platform. it's a pity that Dave doesn't have more followers, his work is really good.
It's a niche audience so sharing it really helps!
Come on, for that kind of advanced tech stuff - over 250k is plenty of people. For most computer users what Dave talks about is a pure black magic ;)
@@leyasep5919 512k, unless you are a power user.
@@leyasep5919 Nice reflection on the conscientiousness of proper language segmentation.
@@leyasep5919 Even though you made me laugh hard, twice today, and made me think of Futurama. The reference disappeared and should no longer be found in config.sys. god.img is a function of pure coincidence, so i apologise and say thank you.
We had a guy back in college (in the 80s) accidentally code a fork bomb in C. His was due to lack of error checking. He had a loop that was supposed to wait for a message, fork and have the child process exec another program passing it that message. What he failed to do was 1. check for an error condition on the exec causing the child process to loop back instead of exiting with the other process. It tried to call another program that he hadn't written yet so that failed. and 2) check for an error on the socket receiving the message. Once 2 processes were trying to listen on the socket, one would fail because the socket was in use. But he ignored that and forked anyway. There were a bunch of us in the computer lab trying to pull an all-nighter on a project, but this guy brought down the VAX and nobody had admin rights to fix it so we just all went home.
@Wooden Door Garage Guess that means their system wasn't well managed then lol
I knew you weren't lying, 'cause VAX nights in the computer lab was the way for CS students at my school.
A friend of mine actually made a script in python that opens cmd about 10 times every second. Not too dangerous but still deadly. At least that thing could be stopped before it did any damage.
I remember in CS119 at Princeton in 1988 that the mainframe computer kept going down the night before the assignment was due. This went on for about 6 weeks in a row, until some admin realized that there was a memory problem that only became evident when everybody in the class was logged on at the same time.
Had a professional dev (Dr. in computer science, master in maths) working for a common customer who refused to fix a piece of code which when one database statement failed (several full table scans due to statements that couldn't possibly use an index, thus timeout; pro tip: concat several fields ≠ AND) basically DoS'ed the DB: open a new connection, forget the old one, fire same failing statement.
His explanation: that's how one does it. Customer's explanation to not replace him: he's a PhD. -_-
Workaround: stop auto-restarting the software, force kill the DB, delete all non-essential data such that the full table scans are quick enough again, restart SW. Caused an outage every couple of weeks, hours of down time and manual work each time.
I always love it when you see people talking about issues like this, you always get the people telling you not to make video's about it. But they don't understand that anyone with a little time can find the information on issues like this and how to deploy it. It's just sad that people think that if you don't talk about it people can't figure it out on there own. The more that we talk about issues like this the more our systems can be programed to keep them from being hit by bad actors on the net.
It is done with any controversial topic. Like lockpicking, or hacking ect. People always complain that you are sharing how it is done with x amount of people without realizing that the people that would attempt these attacks would acquire this knowledge with or without said video. It actually helps to spread awareness of the weaknesses of said systems and gives people an idea how to protect themselves.
But hey, what you don't know about can't hurt you right. /s
The issue isn't that you cannot find it on the internet, what happens is that when it is brought up, someone may not have known about it until they see the video or maybe someone will see the video and then want to try it on a work or school pc or something. Yes, if you wanted to find out about it you can on your own. It has been years since i have heard about fork bombs and watching this video did actually bring up something that i had pretty much forgotten about. Not everyone may have known what a fork bomb is so they would not have known how to look it up prior to this video but now you might have more people curious that might want to mess with it. I do believe knowledge is power and actually agree that it is better to discuss it and show it than leaving people to have to look it up... I think Dave did the right thing talking about it and the video was pretty good. 👍
That approach is a double edged sword.
On one hand it educates us and raises awareness about about this issue,on the other hand it will be a new tool in the arsenal of malicious actors who have not known about it until they saw the video.
The real issue is prevention or mitigation. Using this in an attack or maliciously requires a low level of knowledge and a low level of effort. Prevention or mitigation, on the other hand, requires a higher level of effort and a higher level of knowledge. On the balance, then, this one is one that’s better not to talk about widely.
However, while Dave’s videos are always interesting and go into technical details, the kinds of low effort, low knowledge people we’re talking about who would make life hell for an admin aren’t going to find his videos interesting enough to stick with them or to find them in the first place. So the risk of him sharing this here is lower, over all.
Yeah I totally agree, it’s trivial to do this even without bash so long as you have access to spawning threads, bash is just a simple interfaxe to it. It’s not a magic "cheat code" and it’s far less dangerous than almost anything else you can do with access to running arbitrary unsandboxed code. The worst that can happen from mentioning it is a couple of junior high school computers need to be restarted but nothing worse.
For extra fun, make the program exit after forking itself and not start a second copy. It won't take down your system, but you'll end up with an "unkillable" task that runs around memory, possibly upsetting the scheduler.
Could you insert malicious code into that with progress tracked from run to run somewhere on disk so you have an Unkillable malicious process? Sorry if that’s a silly question i’m only a hobbyist programmer.
@@citywitt3202 Yes
So all you'd end up with is a single bash process calling a recursive method endlessly without spawning new processes?
If that's the case I'd assume it to be easily killable, assuming you're aware that the process is running.
The more malicious stuff you start doing, the more obvious the process becomes, and remember, the process itself does not have any special rights.
You're effectively just calling a bash function in a background process.
@@m4ster_root No, you make something like "while(1) fork();". This will create new copies of itself in an endless loop and every copy will create copies of itself in an endless loop which all will...
You can even do this by accident (that's how many people learnt about it). Make some forks in a loop (e.g. to spawn 5 worker processes), but mess up the check for "am I the new copy?"
@@HenryLoenwind I simply commented on this "...make the program exit after forking itself and not start a second copy. It won't take down your system..." if the system is not "taken down" then the forked process must not be creating copies either. You'd only have that initial forked process doing whatever it's written to do.
Still, unless the system is completely unresponsive you'd still be able to kill all the bash processes. Just because the main process has terminated doesn't mean that all the forked processes can't be terminated too.
Back when Sun Microsystems made big machines, we had some code that the Sun reps swore would scale but our experience suggested otherwise. It took some work to get a sanitized version of the data to test with (the real data was TS SCI) but we eventually got an unclassified test case. It stalled every machine we tried it on when that machine was running Solaris Trusted Zones, but on the older system running Trusted Solaris it completed just fine, even on really old hardware with little ram and small, slow drives. Eventually someone swore it had to work, we just had not thrown enough hardware at it yet and offered a run on an E15000 (which is essentially an entire data center). At about 20 minutes error messages began to appear and the console began to lag. After 30 minutes it was unresponsive and most of the cores were maxed out. The cores were all swapping memory to disk. At about 8 hours the disk arrays began to fill up. At 12 hours it halted. All disks full, all memory allocated. The same program took about 45 seconds on a Sparc 5! Implementation details matter a lot!
This is what i say about videogames
Just spend the time optimising and you can get better quality than AAA today on older hardware
People being lazy and going "it's good enough" is the bane of performance
@@angrydragonslayer I've managed to get PS3-like visual quality on an Intel HD Graphics 4000 in a MacBook Pro in Unity at a decent framerate for the hardware it's running on
@@TorutheRedFox i am impressed by your efforts but also disgusted by the mac
@@TorutheRedFox damn so they didn’t need custom cell CPU’s after all huh? Lol
Cool project!
*"damn so they didn’t need custom cell CPU’s after all huh? Lol"*
They could have written optimized code. Instead they made hardware optimized for their shitty code practices.
I did something like this back in the early 2000's in programming class in High School. I was bored with the programming assignments, they were very easy, and the teacher told me to write whatever I wanted. I told her to run it on the isolated test machine in the lab. She was impressed but not happy. lol.
Lmfao 😂
I wish we had modern Linux/BSD PCs back during my high school days. Back then we had programmable calculators, and I played with the PDP-11/34 at the adjacent community college where my father taught English. These days, even a cheap PC off eBay is plenty capable to run classic high level languages such as Lisp or Smalltalk. Even most mainframes back when I started weren't even close to that power.
Brings back memories. Back in the early ‘70s I wrote a simple CP/M batch file to test disk drive reliability. It copied one entire 8” floppy disk to another, then deleted the original and repeated the process endlessly - or until the computer crashed, which many did. It earned me the nickname Mad Bomber :-)
I remember an IBM engineer telling me about this concept in the 90's when I was an admin for their RS6000 platform. I wrote a shell script on one of the test servers that recursively forked copies of itself as background processes. It had the same effect as this, but your version is so much simpler and is more elegant. I love it!
Dave, I want to let you know your videos are not only interesting but the part that I love the most is the fact you take the time to explain how things work. It truly sets apart your videos from others, and why things are the way they are. Thanks!
Thanks for the kind words! I try to include as much explanation as I think folks will tolerate :-)
@@DavesGarage You include just enough to create an army of dangerous minions!
@@DavesGarage
The legends are true. RLE compression CAN increase memory requirements in a circumstantial way. Its mostly hit rather than miss though.
I have to second this comment. You always present things in a masterful way in your videos, and it is a breath of fresh air compared to all of the jittery jump-cut videos which abound on UA-cam these days. Thanks for sharing so much valuable information with us all, and keep up the great work!
Watching Dave's videos is like watching your old friend to tell you wonderful stories about his life.
That got me smiling because it's true. Your autistic yet smart uncle. :)
He is!
On modern Linux, systemd places each session into a separate cgroup, and the kernel is now pretty good with preventing processes from different cgroups starving each other from resources. However, WSL is not a full modern Linux system based on systemd. It is just the kernel and bash, and none of the other user-level system management glue code (e.g. systemd's out-of-memory kill daemon) that make up bare-metal installed Linux distributions. So there is still a lot of infrastructure missing in WSL2 compared to a native install, and therefore you can't really learn how e.g. Ubuntu 22.04 behaves in such situations from playing with it in WSL2.
so ironically it might have been better either on a VM or Bare metal but this one situation was worse? Lol
The out of memory kill process predates systemd by several years.
In this case though, I don’t think the OOM is the problem you would trigger. The kernel is just too busy running a backgrounded user process, at a higher priority. OOM killer would trigger if the memory was low, but only if there were the spare cpu cycles to trigger and process the kill commands.
However, systemd as mentioned, has the concept of control groups. I think you might be able to do something with systemd reexec to get the kernel/systemd running outside of the former process hierarchy. If you can do that, and either move your htop window terminal login session to the new control group, or use it to kill the fork bomb control group you might have a chance. The key I think is to get the fork bomb out of the running systemd/kernel process tree control group to bring resources back to the core system in order to perform heavier tasks like managing the fork bombed cgroup.
This is all theoretical as I don’t have access to a Linux device at the moment, but a work project is involving a similar process to get out of CentOS and running Ubuntu 22.04 under the old CentOS kernel.
I just tried it on a native install of Ubuntu 20.04. systemd didn't help me.
My plan was, once the fork bomb was running in window A, to switch to window B and "exec kill -9 -1" to see if it'd kill off the fork bomb. (I'd pre-launched a bunch of terminal windows, so I'd have several chances at it in case I screwed up once or twice.)
Result: a few seconds after the fork bomb began to complain that it couldn't fork any more, I stopped being able to switch windows. I guess the window manager wasn't getting enough CPU cycles to respond to my mouse clicks. Even CTRL-ALT-F3 wasn't responding (normally, that would give me a character-mode login prompt). Perhaps if I'd waited long enough, I'd have gotten a shell into which to type that kill command -- as often happens when the system is page thrashing, though it can be an excruciatingly long wait -- but I got impatient and did a hard power off. (Of course I'd made sure the system was quiescent, with nothing important running, before I started the test.)
EDIT: that "exec kill -9 -1", run *not* as root, would have killed off my whole X-Windows session, but again, that was a sacrifice I was prepared for.
Interesting. I just tried it again on the same system, but using character-mode shells, not terminal windows. I'd done the usual graphical login, but wasn't using that for the test. I was also quicker to type the "kill" command; presumably if I'd waited longer, I'd have again been unable to switch screens to get to a working shell.
Observations:
- I didn't need the "exec"; somehow the shell was able to fork a "kill" process, even after printing an error message to the effect that it couldn't. Hypothesis: if the fork() fails, bash retries it
- As expected, "kill -9 -1" killed off my X session and all character-mode logins. *Except* the one I ran that command from. That exception is the only bit that surprises me
- Once I logged in again, I couldn't launch a terminal window. It hung somewhere in my .profile, and gnome-keyring-d was pinned at 100% CPU. I had to reboot to clear that (a clean "sudo shutdown" this time, yay!)
- During the shutdown, something hung (I forget what), with a 1:30 timeout before systemd hard-killed it and proceeded. Presumably related to the previous point...
Alt-Sysreq-K to kill everything on the current TTY. As a kernel-level interrupt it *usually* works (unless you have a USB keyboard and the USB system has crashed). If you can invoke loginctl, on an (e)logind system, you can kill the session that way.
Problem is not dealing with it locally, there's a risk that some curious teenage idiot given access to Linux for the first time will try it over ssh. And I'm not even sure if it's enabled by default or xserver crashes the whole kernel (sometimes I tried when I had black screen) or if it works on virtual box.
@@pavelperina7629 If you catch the problem remotely quickly enough, you can `echo k > /proc/sysreq-trigger`. Obviously, while the after effects of writing `k` to that handle is kernel-level, actually opening the file for writing and writing it would be done by bash, so you've got a couple seconds to do it before the fork bomb will choke the system off enough that a reboot is faster. Also, that echo won't help if the fork bomb was *also* dropped remotely. For that, a `killall sshd` can help, as that will trigger a sighup (depends on how bash was configured). If you are running an (e)logind system, loginctl kill-session $ssh-session-number will do the job.
Can't speak to virtualbox, but the xserver can't intercept sysreqs. It is possible you are running a kernel with sysreq disabled (check if /proc/sysreq-trigger exists). Also, if your keyboard is USB you can have the USB input get screwed up (more likely with X in play).
@@pavelperina7629 You could try using the following command to see if SysRq was enabled when your kernel was compiled:
zgrep -i CONFIG_MAGIC_SYSRQ /proc/config.gz
If you get a no such file or directory area it could be that your kernel doesn't have the configs module loaded if so try the following command then try again:
modprobe configs
If that still doesn't work you may also be able to find the config file for the current kernel in /boot it will generally be /boot/config-[Output of uname -r]-generic so the following command should work:
grep -i CONFIG_MAGIC_SYSRQ /boot/config-`uname -r`-generic
Either way you need it to be CONFIG_MAGIC_SYSRQ=y if it is n then the support was not compiled into the kernel at all. If it is y it could still be that specific feature isn't enabled for whatever reason but you can change this by echoing a value to /proc/sys/kernel/sysrq. Using 0 disables all, 1 enables all, higher values allow you to selectively enable certain ones. Word of warning don't enable all on a shared system it allows things like sending signals (including kill and term) to all processes on the system. Search sysrq values to learn what the different values mean, to enable multiple functions simply sum the values you want together.
@@lperkins2 after almost 30 years using Linux, I knew, and used sysreq locally, but I didn't know about /proc/sysreq-trigger. Thank you :)
As a kid I didn't have access to any programming language that could compile into a real .exe. So, I experimented if I could just change the extension of a .bat file to .exe and run it. The result - MSDOS 7 would just restart. The first line of the batch file was - @echo off. I then found out that it was enough for a text file to have a @ at the beginning, save it as .exe and it would restart the PC if run from the prompt.
Awesome!
I remember in college our campus HP-UX machine would go down about once a semester and you’d think, “Guess the OS class is writing their shells this week.”
Back when I was a student around 2000, I remember writing something similar in a Windows NT command line to see if I could cause a BSOD. Instead, the PC just locked up, requiring forcing power off/on as I couldn't bring up task manager, log out, etc. The batch file is short also, e.g. named "c.bat" containing these 3 lines:
:rep
start c.bat
goto rep
This basically launches endless new instances of itself. From Windows XP onwards this just bricks the current user session as it's possible to press ALT+CTRL+DEL and log out, which I remember was not possible in Windows NT.
I recall seeing functionally a similar idea on the Original Star Trek episode “Wolf in the Fold”. Filling the computer's processes and all forms of storage with the digits of Pi, instead of infinite clones, an single program with no known limits on its needs. Different method, yielding a shared result, an over demand for system resources.
Funny; I'm reading this on Friday 22/7. Happy Piday!
What a creative way to bomb a system
I do believe that windows has an automatic "nice" system where processes that are not in the foreground are deprioretized over others. This is to prevent lockups on heavily abused systems and the like. Windows task scheduler is magic I would say.
@Linus Fu Well stopping vs, mitigating are different issues entirely. if you can make a task scheduler that doesn't let process trees hog the entire system or you can limit clock cycles with priority access. if you can maintain system responsiveness, dealing with a miss behaving app is very much a possibility.
Actually there is at the hypervisor level known as the "Scheduler", and the various states the scheduler can be placed in: Classic, Core and Root, Where Classic has an SMT Disable variant
Both Linux and macOS have such schedulers too, but unfortunately there's no way to adjust the scheduler in macOS (at least easily). But, macOS is a BSD derivative. However, macOS/Darwin is so far removed from BSD that I don't think any scheduler tricks that work with the BSDs would work in macOS.
The scheduler can be changed/adjusted in Linux. I believe Deadline is the default scheduler these days.
Windows have a foreground process boost called "dynamic thread priority boost" that basically triple it's existing priority.
@Linus Fu I believe I have run fork bombs on Windows 10 in the past (on a machine with 16 GB of RAM), and eventually the OS gets to a point where it just force logs out the bad user, killing all their processes
What's interesting is that the Windows version of this doesn't have the same impact on Windows 10 Mobile, it still creates many "CMD.exe" processes but the system suspends all the processes after a few seconds.
Update:
It does cause all running apps to slow down and restart, but doesn't crash the system straight away, it takes a very long time for it to cause enough processes to halt everything
WOW !!! I am 68 and have been building My own water cooled PC's for many years now. 1982ish I purchased a Commodore 128. 1988 I took a train to NYC and underneath GCS or somewhere, I bought a Amiga 500 with the side
adapter that was a one meg HD and space for more sticks of RAM.
I have never heard of fork bombs in all this time, and ya learn something new every day.
Clear Skies
Mike
When will you turn 69?
As someone who's been running servers shared by my multiple clients for over 15 years, I'm glad you've covered this. My first experience was a learning curve to say the least.
Nice vid Dave it really makes me ponder what other quirks are still out there in modern OSes which can throw the system a curve.
Not a modern OS, but the 1977 vintage TRS-80 had an interesting quirk. You powered it on, pressed and got the prompt. If you pressed or you also got the prompt, but if you pressed it lost its mind. Never knew why.
Don't hold down Win+E on any system older than Windows 10 or a patched 7 unless you wanna see one.
FWIW, ulimit doesn't exactly get along with Systemd. The Systemd documentation explains this better than I can off the top of my head, but the TL;DR is that they implemented new tools as part of the cgroups build-out. They didn't remove ulimit, it just no longer rules in quite the same way. (Something you find out when a vendor wonders why their program's start script no longer works as intended.)
Nice/renice was also altered in effect.
I had fun with this as a system programming student, back in the day.
Some steps (in the wrong order) to reproduce this in a home (but still POSIX) environment that recovers itself:
- Write the thing direct in C
- create a signal handler on SIGALARM. Signal handler should exit the program. 30 seconds is a good time
- once it's created, do the fork bomb thing. fork() is the key function here.
- machine gets hung up with processes
- when alarm goes off, it just all miraculously recovers.
- if you have another terminal window, or run screen, watch uptime.
In computer engineering, I used to spend extra hours learning from online manuals. The system I was using was an Ultrix running a 1 MIPS cpu. I discovered the 'fork' command, read how to use it and decided that I should promptly write come C code. Wrote it, compiled it and executed it. About 1 second later I had the realization of what I'd actually done. Never knew until today what it was called but, I wrote a fork bomb in 1987. Whoops. Lucky it was Sunday night so I went home. Monday morning back at school, the first thing my friend said to me was: "What the f..k did you do to the VAX?" Long story short - system administrator had to reboot the system and all went back to normal. My code worked very similarly with an end result being one in the same. Thanks for the video Dave. Brought back memories.
You didn't by any chance go to UNL did you? I was there in 87 and we had a VAX running Ultrix. I remember something like this happening.
@@davidwilliss5555 I'm a Canadian from Toronto. I did computer engineering in Toronto. Cheers!
I was browsing the comments and thought to tag David, but he already found you. :D
just about every programmer has done that on a UNIX system at one time or another.
I remember Windows XP being particularly susceptible to a similar kind of DoS attack, the handle bomb.
For readers that don't do much Win32 API apps, you might have never heard of handles before. They are basically the same as pointers, but across separate memory spaces, usually between the kernel and userland. For instance, if you've seen the HWND type somewhere, that H stands for Handle. It's a reference to a window object that's owned by the OS and not by your own code.
So how do you make a handle bomb? You hold down Win+E for a few seconds...
Yep! That's it! It's a shortcut that will open a new Windows Explorer window, which creates a whole bunch of handles along the way. The funny thing is, Windows XP used to process that shortcut as fast as it could, flooding the screen with tons of new windows until the entire handle table would get filled. At that point, funny stuff would happen. Some processes would just hang or crash. Others would have missing UI elements here and there or turned completely blank. Most of the time, you couldn't even open the start menu anymore. Fun stuff! I remember getting Windows Vista to crash that way as well, but it took a lot longer. I wonder if it still works today...
I once crashed an UltracSPARC 1 system (running Solaris 2.5) by simply running Windows 3.1 in Soft PC. It triggered a file system/kernel panic. It took about 30 minutes for fsck to run.
Did that happen in the later SP versions or only in original release? I think I may have once crashed am XP machine pressing Win+E too long accidentally with no idea at the time how it had happened nor how to repro in order to submit a bug report.
@@MWGrossmann I think it was in the RTM release. Nimba and Code Red was in the wild still when XP was released.
@@MWGrossmann oh it was at least in the SP2 days. It even worked on Vista.
@@eyevou no address space doesn't really impact it. The amount of available handles is a fixed value in Windows and, as far as I am aware, there aren't 64bit handle types, even for apps built with 64bit pointers in mind. I actually think they are shared between 64 and 32 bit apps, so they would have to fit in a 32bit space either way.
Cool! Reminds me something OS/2 fans would do on Windows machines to show how OS/2 could better handle bad processes; I forget the actual code now, but it required using DEBUG to clear interrupts (CLI) and then starting a infinite loop. Windows would lock up hard, but OS/2 would keep chugging away and you could easily kill the locked up process. Cheers!
Formatting a floppy disk at the same time you played music was another way to demonstrate W95's inferiority.
The fact that you were able to execute privileged instructions such as CLI and access kernel memory from user indicates that Win 9x was never meant for security. If you try to execute a series of x86 instructions like:
sgdt [some_user_memory]
mov cx, [some_user_memory]
mov ebx, [some_user_memory + 2]
Now you have an address in EBX which points to the GDT (Global Descriptor Table), and its length in CX. Under normal circumstances, this wouldn't be a problem, but Win9x maps this address to a USER page.
On NT, a fault occurs if an attacker tries to reference the memory pointed by EBX in any way.
On 9x, this access is allowed and gives the attacker full control of the system, meaning that they can do ANYTHING. They can crash the system by filling the table with garbage. They can gain kernel privilege (ring 0) by setting up a call gate in the table and calling it, and after gaining kernel privilege it is pretty much game over, there is nothing that an attacker can't do.
@@andreimiga8101 "indicates that Win 9x was never meant for security". Users don't care; they just don't want to lose all their work when then machine locks up, and need to reboot.
(Really what they care about are *features* and *ease of use).*
OS/2 was a good OS with bad timing. When IBM started to make noise about it the HW requirements, or more specifically the memory requirements were not in line with what people thought were reasonable. It could run on 4MB but needed 8MB to actually be useful, 16MB to shine. At the same time the average PC sold had 1MB or 2MB standard, and some times 4MB. 8MB was EXPENSIVE and 16MB most people couldn't imagine what they would do with.
But it was just five or so years early, that's all.
It's a pity that MS and IBM couldn't work out their differences about the direction of OS/2 or we'd had a true 32bit OS with preemptive multitasking on every PC a lot earlier. Still I got to install some MS Exchange servers running on Microsoft OS/2 1.3...
@@RonJohn63 That's true. Users don't care about security. Until a virus gains kernel access and overwrites the BIOS, bricking the machine (I'm sure you've heard of CIH).
Magic SysRq notwithstanding, you may be able to get back into Linux as root via the console. It does have special considerations for uid 0 in the resource allocation. Windows' task scheduling is a little different to Linux (it's more real-time-ish), which may be the reason you could break out - especially if Task Manager had a higher priority than your fork bombs. On that note, process scheduling algorithms would be a fun video series!
process scheduling has been the subject of a number of PHD thesis.
Not until after login.
This reminds me of when I first figured out how to make a web page open a popup of itself infinitely. You could only save it if you were REALLY quick with the task manager! Remember when pop ups were a thing? LOL!
I've pranked many a friend's computer with that trick
For doing something helpful, I once created a program which calculated prime numbers.
First process just counted from 2 upwards and sent the value to a pipe.
Last process just printed the value from the pipe.
Intermediate processes forwarded the first number read, and then filtered out everything divisible by it.
After a few hundred results the process table was full. Not a real bomb, it could be killed with SIGPIPE.
You can gracefully shutdown Linux using the magical sys request key route if you configured it, alt + sysreq, reisub; alt + sysreq, reiso depending on your configuration.
You should probably also try unmounting before powering off, too.
@@BrianRonald that is part 8f the key sequence
@@mmcv1987 It was part of the first one, which rebooted. Wasn't in the second.
@@BrianRonald ... Well I see what you mean reisuo it should be.
Ah, it has a name. I accidentally froze my pc twice this way during labs that wanted us to make a recursive program that run recursion using fork.
I remember at Uni when the second years were due to submit assignments demonstrating their understanding of forking programs.
As a first year, the lecturers all sternly warned us that not being able to submit our program because the submission server was fork bombed meant a late penalty.
Then it was second year and guess who managed to do just that 😅
This reminds me of a stupid simple DoS attack I sort of figured out when I was doing Unix/Solaris training for the Army.
I would create a banner that would call to a banner that called to the banner that called to it. Running the first banner would hard-lock the system instantly. I crashed the Solaris server that was managing our Unix network for our tests. I had no idea what would happen, but I did it anyways. Almost got removed from the training cycle and recycled to another group for it.
Rather than fixing the problem, they considered killing the messenger.
@@unclesmrgol Situation Normal, Army Fucked Up.
Great explanation Dave. I would guess that if this function included some kind of disk i/o action (like maybe "touch" a random filename) it would saturate the disk i/o channels or run the filesystem out of entries?
I have conducted a lot of new product testing in the past, and alpha test third party products which use some kind of device driver or driver update/install - esp on Unix systems but also on Windows - fairly frequently had issues where something unintentionally recursed and ate all the i/o or memory, usually only under specific sets of circumstances. I had forgotten about the shared page replicate-on-write thing too, so thanks for the reminder on that - made me realise how much I miss dabbling in OS internals!
I recall doing something similar on an IBM 360 (mainframe) in a class back in 1980, in Fortran on punch cards...
Thanks for the memories...
sometimes, you're beyond me, but this time, wow. You always make things clear enough to us who have never programmed. As a pedestrian I always appreciate when you show locations and perform actions within the code. I'm always pleased to hear from you. Thanks
Perhaps one way to recover a Linux system is by using SysRq (usually mapped as Print Screen): Alt-SysRq-R, Alt-SysRq-E, Alt-SysRq-K, Alt-SysRq-S, Alt-SysRq-U, Alt-SysRq-B. This effectively tries to do a safe reboot.
unRaw (take control of keyboard back from X11,
tErminate (send SIGTERM to all processes, allowing them to terminate gracefully),
kIll (send SIGILL to all processes, forcing them to terminate immediately),
Sync (flush data to disk),
Unmount (remount all filesystems read-only),
reBoot.
I've seen these key sequences not allow me to reboot an old K6-2 350 that had an infamous Diamond Stealth 3D 4000 (S3 Virge GX2-based AGP card) though... Said system had a serious XFree86 3.x, 4.0x bug involving that S3 chipset that would cause the Moire2 xscreensaver module to hard lock the machine. Even, xdaliclock would hard lock my machine with that video card.
I doubt SysRq would have any effect on WSL though, but who knows.
Just Alt-SysRq-I (maybe K works too, haven't tested) is enough. Ignored terminate for me, but kill did the job
Try Alt-Sysrq-f first to try and kill the most memory hogging process.
Dave, a big bow on your videos. Your (and your colleagues') work makes our everyday easier.
1. I have learned fork bomb (on purpose) on during my Computer Science studies. It was one of the very first tasks on Operating Systems curriculum, we did it on Linux. Later on, we tried the same on Windows NT 4.0 or Windows 2000 (I don't remember which NT version was then, the computers were upgraded during my studies).
2. I have just tested the shell fork bomb on MacBook Pro with M1 Pro, running macOS 12 Monterey - system did not even slow down and it was so easy to stop it as just to close the tab of Terminal application.
3. I also did `ps -ax | grep zsh` on this MacBook and saw an interesting result:
1768 ttys001 0:00.01 login -pfl michalj /bin/bash -c exec -la zsh /bin/zsh
1773 ttys001 0:00.08 -zsh
12133 ttys001 0:00.00 grep zsh
33340 ttys002 0:00.08 login -pfl michalj /bin/bash -c exec -la zsh /bin/zsh
33789 ttys002 0:00.05 -zsh
(`michalj` is my logon name) - this suggests that `login` process starts Bash, which in turn starts `zsh` shell.
Funnily enough, pulled the same stunt as many of the other readers here. As a junior dev in the early 90s, on a Friday afternoon I wrote an endless loop in C with a fork and sleep. In my infinite wisdom (read: ignorance) I chose to run it with "nohup myprogram &" on the production Data General AViiON. When the system chose to terminate my interactive shell and I couldn't get back in, how my stomach sank. Especially when the admin couldn't terminate them and had to force a hard shutdown. Luckily no data loss. Some joking and ribbing at my expense by a couple of colleagues helped ease the tension - but I sure had my doubts that I would still be employed come Monday (I was :))
I remember back in tech school using Win NT and setting up domains and networks and one of my class mates decided to send a NET message with infinite loop to all PC's on the network and took down the campus network and supposedly reached out to other campuses in the state. Lucky for him, the message was not offensive but he did get a warning.
Bringing down numerous production systems through negligence is a prank. Saying something offensive is a crime. Aim high!
Love these episodes. Dave the great geek entertainer! 😊
Last time I was playing with fork bombs (on my own PC, of course) Linux killed the thing in a matter of seconds. If I remember correctly it was running in a sandbox (playing with dangerous code was on the menu, but nuking my system wasn't) and the system dumped the whole sandbox when it started taking too many resources, which killed the interpreter.
Dave's garage. Your one stop shop for learning about things you didn't know you wanted to know anything about.
I recall being told of a use of a fork bomb back in 1988 against Bath University. It was written in C using "while(1) fork();". The student who did it lost his undergraduate degree after sysadmins worked out which terminal on JANET he had logged in from and what door access key had been used for that terminal room at that time.
I did that in about 1983 at Bell Labs. I don’t remember if it was a PDP 11/70 or a VAX 11/780. I dabbled with system administration, and was friends with the administrator. I wondered if the system had protections against the DoS, and the admin said try it. Then, the result was a panic when it ran out of swap space. It was lunchtime, so not too many people were upset, and Unix was sufficiently unreliable that the cause of this crash never came out.
It seems that losing a degree for doing it once was a bit harsh.
@@johnhaller5851 Yes, was a bit harsh, but he did it using guest login from a terminal room in another university, so you can imagine how pissed they were with him.
Is this what Jeff Goldblum used in Independence Day?
I seriously want to meander up to your place on a Friday early afternoon with a cold 6-pack and sit and learn software development from you. As a 44yo electromechanical engineer that, after 18 years, has reached his limit at his current employer. I took a C++ course last semester and now really fallen in love with programming. So much that I am considering changing careers to EE + software. Finding a place where you can learn the in's and out's though and not be an "Intern" or "Junior" is a challenge, if it even exists.
Hate to break it to you but you are an "Intern" or "Junior" 18 years of EE+ does not magically mean you can transition to Senior. If you seriously want to switch careers you will either need to take a serious pay dock and work as a junior for a while. Or to start your own company / open source project that becomes popular so you can use that as reference.
On top of that you are competing with a generation who is more or less forced to work at about 25$ / hour for that type of job as an average across the USA. Excluding places like silicon valley. Why would I hire you who has the exact same amount of real world software experience as a college student or some random dude who taught himself to code for 3x the price when the market is flooded with alternative options?
@@ZephrymWOW maturity?
I love the serenity of the thumbnail image with a fat nuke going off and a happy Dave next to it 😁
Not just any nuke, either: it's the Tsar Bomba!
I was wondering how I was going to remember that, but once you explained it, I can write it any day of the week without reference to anything.
What a diabolical little thing.
Video is temporarily paused but I’m looking forward to knowing how this can hurt any data. Seems like a simple reboot would clean everything up.
Windows doesn't have a real fork, so the likes of cygwin, msys2, git bash, strawberry perl, etc are using an emulated fork (vfork()) which is going to be slower than a true fork(), which is part of how Windows can manage to remain responsive.
actually it was running under wsl so it has native fork(), it responded well because wsl is a virtual machine and isnt allowed to bring the system down
@@IANSYT dave tried it under git bash (windows native)
How is forking() the current process better or worse than creating a new one? Other than sharing the read-only pages of the original, and maybe skipping process startup, I don't see much of a real difference?
@@DavesGarage
Dave I promise to be good except for every blue moon. Youve been hit by, been hit by a parallaxed saint.
@@DavesGarage it only affects process scheduling and the size of the kernels process table.
while(1){fork();} ? I remember that being explained in my OS course in University. Had every student's attention.
Is that java?
@@oliogamer3975 C
and still i managed to deploy a script years later on a production system going crazy and recursively starting processes together with messing up .ssh and clogging home, effectively shutting me out completely. having no ilo, i ashamedly had to request physical access to the data center, lol
@@fatalfallacy Or the script that remembers the PID's of processes it started but author doesn't seem to understand that those processes with those pids can exit and the PID reused. Then the script starts killing those pids it cached .... Seen that in production at a well known company that will remain nameless. It took weeks to track down the culprit with lots of VERY ANGRY customers to boot. To be clear, it wasn't one of mine :)
I like how you explained what was going on in detail then immediately related it to something far beyond my scope of knowledge.
Amazing content as always Dave. I discovered by accident a kind of fork bomb in Windows during the XP days. It is still an issue with server 22 and windows 11 today.
So the below command will echo a number starting at 0, incrementing by 1 and finishing at 10.
for /l %a in (0,1,10) do echo %a
But if we change just one parameter to increment by zero then the command will run forever in a loop
for /l %a in (0,0,10) do echo %a
So to expand and this is the fork part. We can call another command instead of Echo to stretch the system and spawn an infinite number of new processes.
for /l %a in (0,0,10) do start
Essentially the above will spawn a new command prompt indefinately.
Now to use this encoded into dial tones to see if robo-callers properly sanitize the input of the system.
Using GNV on VMS, the fork bomb just reports a pipe error: exceeded byte count quota. VMS has always been paranoid about a process having unbounded access to system resources, with default limits appropriate for a 11/780 with .5 MB of memory. I could probably up BYTLM on the account to make it fail with a PRCLM exceeded error instead.
I remember the time in college the admins sysgen'ed our RSX 11-M to include type-ahead support in the terminal driver. I held down the arrow key for several seconds and crashed the system as all the system pool got consumed.
Windows NT core was supposed to be modeled after VMS. Sounds like that wasn’t ported over.
And just on the thumb nail for this video - kind of makes Dave look like a despot warlord - nice work!
Heh, I made one without knowing what it was called when I was 10 in elementary school. The only thing I didn't know back then was the fact that all PCs were actually thin clients running from one desktop. Crashed not only my own, but also the 3 other workstations my classmates were using. The IT-teacher was NOT happy with me...
I've been working in IT for 28 years... first time ever seeing this. Never stop learning, eh? Thank you for posting this!
Loving that your simplified analogy of the fork bomb is describing nuclear fusion. 😂
Fission
Oops that's what I meant!
Back 25 years ago, a workmate of mine, who thought 3-1/2" diskettes were "Hard Drives", he tried to copy a disk. I have no clue what he did, but any time you inserted it into a drive, the second the read light came on, the computer locked up. I bought it from him and put a label ... "The Disk Of Death" on it. It couldn't be copied of course, and when XP came out, it did nothing, and showed itself to be blank in file manager. That disk got borrowed by so many people as a practical joke, that I don't know if I still have it. All you could do is shut it down and restart it - but if the disk was still in the drive, it could go on for hours. Loved your video. I faintly remember in the days of dial up Internet access, to a local club, that you could send a fax string and put some kind of square bracket in the line, to change a receiving computer's fax, into an access the computer scenario. Never did it, but the insight of some people was amazing
My AI prof in university talked about a natural language program he wrote that worked fine, albeit slow, on the limited hardware available in the frozen north of Manitoba. However, it crashed the big servers found on more well funded US campuses. Turns out the program was allocating a negative amount of memory, which when cast to unsigned was such a massive number the local machines returned a terse "go fish", the program got nothing, handled that rejection, made some adjustments and tried again with a reasonable request and carried on. The BIG servers in the US, _HAD_ that much memory (barely) and would attempt to allocate it and fail hard!
This reminds me of something similar but not quite the same I did by accident on a Decsystem 10 back in the late 70's/early 80s at UTK. A friend of mine a Kent O. and I were playing around and I noticed you can use the console assign command (not sure of the exact command now, maybe "assign" or "assgn") to assign/attach (maybe it Was "attach") a Device to your login session. While this was primarily for assigning a printer or tape drive to a job or session so you could exclusively output to it, I found the neither command nor OS discriminated; any valid (open) device could be assigned. For fun I tried 'assign'ing a nearby (unused) terminal (TTY). It worked. Grin. I tried on that someone was already logged in on and got an error saying the device wasn't available (or something like that). As I said, playing with my friend who was on another TTY and found that yes, after assigning it, I could output to the TTY. In fact I could (forgot the command), mirror everything on my screen to the assigned TTY. Well that was all fun, but Kent wanted to login himself. But he couldn't while I had it assigned. Grin. He eventually figured out he could hit Cntrl-C to "break" the assignment and get a login prompt. The fun then was me running the assign command again before he could log in. LOL. This continued for half a minute or so before I thought, of the easy fix. It took me about 30 seconds to write a simple script to loop the assign command for that TTY. I ran it. I don't know how many times he hit Cntrl-C, but my script would reassign the TTY Long before he could log in. So after a min or so he gave up. My script is still running. I didn't realize, but once he stopped breaking it, the script kept reassigning the TTY; and apparently on that system there was a pool of assigned devices; not a very big pool either...my script started getting errors "?assign limit exceeded-no available space" or something to that effect. Suddenly all around the computer lab I hear "Hey my terminal's locked up!" "Mine too!" "What's going on?" I sheepishly tried to keep my cool. I realized I didn't know or remember the "deassign" command. But I thought, if I log out, all my resources should be returned to the OP pools, including all these device assigns. Fortunately that worked. Kent & I had a good laugh over that later.
In VAX (and later Alpha) VMS, the command is ATTACH.
Interesting, it seems Apple has lowered the default ulimit on MacOS 13 (Ventura). It's now 5333 out of the box on my machine and running the fork bomb will not lock up the machine. In fact your video just keeps playing and i can still launch apps. Running killall bash eventually stops the fork bomb altogether
It could be system dependent. It's 2666 for me on a ten core M1 Pro running Monterey.
@@jamesweatherley9215 Could be memory dependent? I'm running with 32GB (M1 Max), perhaps Dave has 64GB on his M1 Ultra with ulimit 10666
@@arjanscholl Sounds plausible - I'm on 16GB.
@@arjanscholl no
Good one! I wonder what determines the limit, or if they really did lower it for Ventura?
If I remember correctly the PDP-1 computer had a related problem that was a design error in the hardware. The front-panel "stop" switch would stop the processor after the completion of the current instruction. But the machine allowed multiple indirection of addresses. The three states of any instruction were fetch (get the instruction from memory), defer (calculate the address intended if indirect) and execute. Any instruction referring to its own location indirectly would not complete, but instead remain in the "defer" state while it tried to locate the infinitely deferred address. Pressing the stop switch did nothing. Instead the power had to be shut off.
Hi Dave, I would love for you to have a look at the state of modern Linux Desktop Environments: GNOME (both Vanilla and Ubuntu), KDE Plasma, Cinnamon, etc.
You could also in theory limit the CPU time of any given user so it only ruins them.
I am really enjoying your videos. a look at the deep dark (well maybe not so deep or dark) secrets of MS stuff. I actually used MS dos when a 10 Meg hard drive was $300.00 in 1980. Thanks for your videos
Same here. I remember my first HDD being almost the same size as a modern PC power supply!
I encountered one of these in 2006 when I was working on a project in Ruby 1.8 on a G4 iMac and experimenting with fork(). I could get 643 recursive instances of the Ruby runtime to launch before the machine locked up. It was my first serious encounter with *NIX systems level behaviour (I had about a decade on Windows and various embedded hardware) and lead me to give a series of conference talks in subsequent years on kernel scripting in Ruby. Fun times.
The alt+sysrq key combo might save you in linux.
alt+sysrq, then k will kill all the running processes on the console. the e key will kill all except for init.
The most Linux distributions disable ALT + SYSRQ key combinations by default
I always forget that even exists
on NT task manager always runs with a higher priority and cpu affinity. Probably it is enforced by the kernel itself, outside if win32 api. In other os's there is no such thing by default.
On linux systemd-oom tries do that but only kicks in when system is low on memory. But earch bash/zsh has very low memory usage. So it does nothing to them.
On this very channel there is a video dedicated to the Task Manager. He touches on how it was made to work even on degraded aystems, tolerate memory corruptions, and be responsive even if hell broke loose.
What a great explanation!
The lighting makes your hair look pretty magical.
@Daves's Garage From the console or SSH before ssh blocked direct root logins by default. (remember if its running X is a thing) Just "killall -s SIGSTOP -u " a couple of times as root (to make sure you got all the buggers) then "killall -s SIGKILL -u " Uni students learning about fork in the 90's on a shared SunOS box.... this was a daily thing when they got to that project.
I once recovered a production machine running Solaris which had a fork bomb set off by sending SIGSTOP to all the working processes before actually killing them with SIGKILL.
I still don't really understand how my "ps aux | grep ..." managed to run (it took many tries before it worked), but eventually I managed to freeze all the forking processes and only then tried to killed them off. Directly using SIGTERM or SIGKILL just freed up slots in the process table that were immediately filled by new forked processes, but freezing them with SIGSTOP prevented more forking and I managed to get them all frozen before terminating them.
At least this is what I believe happened. Maybe Solaris had some magic sauce that did the real fix while I was messing about thinking what I was doing actually helped.
Hi Dave, while everything you stated is true, I wanted to re-test this on Mac OS 12.4 since there are security changes in this release. After about 2 minutes of running a fork bomb via Terminal, the XProtect Service killed every instance of zsh as it seems to identify a fork bomb as malware activity.
Weird, I thought I was up to date, but only on 12.2! I'll have to try it after I get the update!
@@DavesGarage I tested a bit more and here's what I found: A fork bomb inside a script (done as a function) is trapped by security. Manual fork bombs from the command-line work as expected.
@@DavesGarage
On the topic of the video you could make a bot that on loop could do exactly what you are doing in the UI to preemptively maintain against attack tho. Buying REAconverter since its batch TGA conversion is non RLE compressed. I can just make it work, since the CPU overhead is laughably trash. Also it should be against the laws of the universe to RLE compress assets which absolutely make zero difference in the end result OR MAKE IT WORSE.
Elon Musk=Starship
Add to that, mac seems to set the number of procs lower. I checked a few different machines and they are not actually all the same ... the the higher-end machines had higher limits.
well, technically it is.
I’m surprised your channel doesn’t have well over 5 million subs. You’re just a wealth of information
In linux, you can recover from a forkbomb, by using a higher priority shell, like the console (It has the top priority). Just login to console and perform the kill
But I couldn't log in once it had started, that was the issue.
@@DavesGarage That used to work back in the day on the VGA or Serial consoles... But today with so much virtualization and so lack of a need, who knows. I presume distros stopped worriyng about that loong loong time ago.
I guess we need to test it on OpenBSD. It has a lot of mitigations, but I can´t remember seeing a process count limit either in sysctl or login.conf (from the top of my head).
On my OBSD box, 512 file descriptors, 128 processes, 4MiB stack, 512MiB data, 2.5GiB mem
But on reflection that may not be default, I've been a shared system admin for a loooong time, so changing those is second nature.
From /etc/login.conf, the defaults are
default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,8:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:
4.4BSD derived systems (NetBSD, OpenBSD, FreeBSD) all have "login classes" (see /etc/login.conf), where normal users have ulimits that are applied to user's logins. ("hard limit") means the user cannot increase beyond that value, "soft limit" means they can increase it up to the "hard limit").
@@lastfm4477 but the question is whether the defaults are "sensible" or not - Linux has the limits, but follows the same "it's a personal computer, the user can do what they think best" mindset that MSDOS and Windows does.
They certainly used to have sensible ones, but I don't know for sure now.
0:12 - does this version work? wow, it does. TIL you can override the builtin : command with a user-defined function! Still, curious why you have that version there, and then later (2:16 et al) use A instead of : ... anything in particular behind the switch? oh, perhaps because that works in zsh, but not bash (ref 9:58)?
As for solving it (5:30), I don't feel like trying to be sure, but I wonder if a bit of fg and ctrl-z and/or ctrl-c might at least help. But, it might not. Maybe sometime when I'm feeling more adventurous, I'll set up a vm or something and try it there, but... anyway... fuser -k on the tty that launched things might help ... IF you can fork an fuser process, of course. Usually builtins are the way to go in resource-constrained situations like this, though, because one often can't fork and/or exec new processes... Also depends, of course, on whether or not you have another active shell, etc. etc.
Hmm, 2:41 makes me wonder if ctrl-S might also possibly be helpful? If you freeze the output long enough, maybe it'll stop trying to fork, because it's waiting to write to its output buffer, which fills up?!?? Something to try.
Oh yeah, and re 5:40 - yeah, if you had htop already running, if you can find the right bash, enter tree view (t), tag it (c) then (k)ill, and you might be able to get rid of it. Not sure.
Magic SysRq Sync first then SIGTERM, then SIGKILL
@@SkylerLinux What, exactly, will you SIGTERM and SIGKILL, though? And how?
Dave's such a badass.
I love throwing on random videos and learning new stuff.
It was interesting to learn that a rabbit is a type of fork bomb.
I'm familiar with the concept of a rabbit and how it replicates to consume system resources but had no idea its what its technical term was.
In college I studied CS, and I had a friend that I'd mess with sometimes. I wrote a script that would remotely search all the lab computers for a certain user (my friend) that was logged on, and would fork bomb the computer. So when we were in lab, I could run my script and instantly lock up whatever machine he was on. The look on his face after it happened 3 or 4 times in a row was just priceless. It took him a while to figure out what was going on. I would sometimes periodically run it from my dorm just to see if I could randomly get him across campus lol. Fun times.
I just tried this in Mint on a PC i.e. not WSL. Got those messages and just clicked the green cross at the top right of terminal and all back to normal.
What an anticlimax.
Given that a “fork bomb” rapidity reproduces itself, could it essentially be considered a type of virus, even if it only replicates processes and not files?
Either way, it’s interesting to me that such a simple line of code can bring even the most powerful system to its knees.
To me, it’s a type of a DoS attack.
@@ted356 That’s a fair assessment.
I'm not positive this is what you're asking but a good physical analogue would be "gray goo" -- it's just like a fork bomb but with self-replicating nanobots instead of system processes.
@@CFSworks The one thing a virus does is spread to other systems, and this doesn't really do that.
IT is also relatively easy to stop. I used to do it by dropping the priority of the process, then killing all of them. which sometimes allowed a new process to get by the "killing all of them" but now it is at a lower priority. so kill all of them again.
About the third time they will all be dead (even on 128core computers). The main issue is that it takes a long time to do.
We used to call such programs "cancer" and had options to direct which resource was being aimed at (one was RAM, so multiple calls to malloc, and then writing the pid to the chunk of memory allocated - without writing the pid, the kernel wouldn't actually allocate any pages - as it used a copy-on-write to determine if the page is actually needed. This causes a crash on systems that didn't have reasonable limits for user virtual memory. A good diagnostic for tests is to have the cancer program check inode stats on every loop - if the protection mask changed, exit.
One of the best computing channels on yt! Thanks Dave!
I wrote one in high school C++ class. It was a C++ program that ran in an infinite loop where each iteration used system("start ...") to run a batch file that ran in an infinite loop where each iteration used "start ..." to run the C++ program.
So if I am, for example, not doing anything at all in Windows, sitting idle not doing any work, can I perform this fork bomb thing without any loss of anything on my computer? The context is that I've saved any and all data beforehand so as to not suffer any data loss.
Of course. Just turn the machine off and on again.
@@RossNixon unless some buffer wasn't written to disk. Having an OS crash, always results in a small chance of disk corruption.
@@mjouwbuis I made explicitly sure that anything and everything I was doing was saved to my OS and storage drives. Then I ran the Windows 10 equivalent of the fork bomb, and sure enough my computer came to a halt. lol I didn't lose anything, but I only will ever run it once.
Who is writing the ducky script?
As always, entertaining and informative. You always touch on some of the deep information that most people glaze over. Thanks.
I love this channel, Dave’s content and presenting style are so informative and entertaining, thank you Dave!
A question! Two of my desktops were shut off and left off for quite awhile. Now they are black screen and say no vga, no hdmi no something else. Anything I can do what’s wrong?
Are they plugged in?
Replace the CMOS battery
They were and are now , they just weren’t turned on for a long time maybe a year!
Check some things:
Is the computer getting power?
Are the fans spinning?
Are any cables looses?
There could be two sets of ports for connecting a display because of dedicated and integrated graphics, try both.
Try another display
The main causes for such failures are power supply and motherboard... or just a loose connection. Pull everything out, and plug it back in.
Would like to offer a correction: the analogy of a nuclear reactor reaching criticality is wrong. Criticality is the desired self-sustaining output of a reactor working normally. Supercriticality is where you get the runaway chain reaction where more neutrons are produced than desired, but that too doesn't necessarily mean it's automatically turned into a bomb, it might fall back to proper criticality, just at a higher power level and consequent temperature than desired.
Okay, second correction upon continuing to watch: 8:19, page combining, isn't enabled by default in client versions of Windows. To enable it, you have to do Enable-MMAgent -PageCombining in an elevated PowerShell console. Similarly, Disable-MMAgent -PageCombining disables it, and Get-MMAgent shows its current state (among other things).
Another interesting watch.
I came across this a long time ago, and was interested, but it faded away, my knowledge then isn't what it is now....finding your video on this reminded me of that, and I learned more here than I knew before, a lot more...making a lot more sense now than it did then.
Thank you for posting this.
Recursive kill has been a saviour more than once dealing with messed up services, thanks Jim for requesting it.
A friend of mine was training for Marine cyber warfare. We were in a Walmart and he went over to the computers and asked me if I wanted to learn how to crash a system and entered a fork bomb. I had no idea it was so destructive.
Dave is that Father that i never had but wished to have! What a great great Man!
Thank you for sharing your knowledge to us! Thank you Mr. Dave
When working on Burroughs Medium systems running under MCP (B2500 - B3500 - B3700 - B4700 systems) many years ago there was a program called HBomb when run would do a call to run another version of itself. The system would lock up as you could not purge the programs fast enough. Recovery was to reboot the system.
Oh god I have the same two versions of bash on my windows machine as Dave. I feel so empowered right now.
Thank you for creating the recursive kill option... it's great for dealing with runaway Chrome tabs...
Good one Dave Thanks Mate
Best UA-cam channel hands down.
I tried your 'fork bomb' script on this system, and it does render it temporarily disabled, but a reset clears things-up in a minute with a re-boot. I'm running an obscure version of Linux as a VM and it's pretty bulletproof. I get hit with similar 'bombs' several times a day, so it was fun to test my system.
3:40 linux hypervisors do this too btw. when running linux, windows, or even macos in a linux type 1 hypervisor, the cpu and memory use can be seen in htop.