It's systemd-daemon. The authors knew that systemd was so huge and opaque that it'd go unnoticed. It even has its own systemd unit file.
It doesn't even do "normal" rootkit level of hiding that rootkit detectors might notice; it just hides in plain site as an innocent root process, right out in the open.
Probably a good choice running as "systemd-whatever". People have lost track of all the systemd pieces as it's grown in scope, so it doesn't look immediately suspicious.
This technique is really effective when the attacker does a little bit of homework on the system: if it’s a web server, a lot of people (even security analysts) will miss that the 147 httpd process are 146 /usr/sbin/httpd and one /usr/local/sbin/httpd — or they’ll assume that was where someone installed a custom build.
Good point - I was thinking about persistence but I saw the argv trick in the wild in the early 2000s when someone hit a PHP script in one of our undergrad’s home directory and dropped something fun onto the system.
I think I used lsof back then but it’s been a while.
Hides the startup command line of the program by masking it with another value. In this example you wouldn't see that the perl program was started, you'll see this httpd thing.
It's not completely reliable but most people wouldn't look that deep anyway.
True, though systemd-* naming scheme provides a substantial amount of brush for mal-binaries/configs to use as persistent cover. Every system could be different, but distros are lazy it seems.
It's also piggybacking on dbus and gvfsd esque names for non root persistence.
They are common but small compared to systemd. there are lots of commonly installed deamons, most people can't keep track of all of their names through all revisions. Even if you did it's still going to be hard to spot with legitimate looking names like this.
This kind of thing is trivially detected with basic system integrity tools [0][1] but I think a lot of those kinds of sysadmin tools have gone out of vogue at this point.
Yes, it's very simplistic. It does not claim otherwise.
However, it did manage to detect a rootkit on one of my system once (many years ago, when I used to phpMyAdmin, which had some kind of RCE). So it's better than nothing, and it would probably have detected the backdoor from the article (which does not even attempt to hide itself).
I don’t hate SystemD and even prefer writing unit files over init scripts, but it really has usurped the whole system. It’s even usurped fstab on Debian 10 / Ubuntu 20.04 and it’s awful.
If you lose a disk on a modern system, SystemD will refuse to boot. Instead, it’ll try to drop to an emergency console, BUT there’s no root password on those systems because they use sudo. So it just runs in a loop and you’re SOL.
Losing a data disk shouldn’t prevent my system from booting. WTF?
I'm skeptical since you spelled it "herd" (or maybe auto-correct strikes again.)
But yeah, keeping your system free from the systemd cancer has always been a good idea.
In December 1991 the primary architect of the Hurd described the name as a mutually recursive acronym:
It's time [to] explain the meaning of "Hurd". "Hurd" stands for "Hird of Unix-Replacing Daemons". And, then, "Hird" stands for "Hurd of Interfaces Representing Depth". We have here, to my knowledge, the first software to be named by a pair of mutually recursive acronyms.
Just out of curiosity I did a simple search and found no mention of any of those domains, except for status.sublineover.net which is being reported here:
For those wondering why "RotaJakiro" the name, Jakiro is a reference to a Dota2 character, that is a dragon with 2 heads, thus why the double-behaviour got the name "Jakiro"
This is pretty noisy as backdoors go. I wouldn't call this stealthy.
It places a whole bunch of files in various locations, is running as a separate process, and doesn't do https properly.
It's surprising really - when LD_PRELOAD'ing your malware into an existing process is way stealthier. Preferably one that nobody will bat an eyelash at for making TCP connections.
The best ones will probably hide in (places such as) your initial ramdisk, be invisible when the system is running, and copy themselves into the new ramdisk whenever you generate a new one.
Anyways. This isn't 'stealthy'. Not at all. It's hardly the bare minimum.
On Windows, using the equivalent of LD_PRELOAD makes all the antiviruses go crazy.
One way around this if you insist is tricking another app into loading you, instead of you forcing your way in, this looks more legit.
But the best way to stay undetected is to behave as a regular innocent program and not use any tricks at all. These days, when computers have hundreds of processes running, nobody is going to notice another one.
For network communications there are ways of delegating this to other apps, so that you don't trigger the firewall. For example you can write something in the Chrome user profile directory which will make Chrome fetch data for you on the next start.
> On Windows, using the equivalent of LD_PRELOAD makes all the antiviruses go crazy.
There is no such thing on modern-day Windows.
There used to be AppInit DLLs, but that 'feature' was broken to a degree that no legitimate application would have used it anyways and it likely wasn't a malware author's first choice either.
Further, by the time you place a backdoor such as this, you would have neutralized any antivirus software. This used to be done by 'patching' them and turning their update process into something that did essentially nothing after any download. No idea what the state of the art is here for either.
This is a backdoor after all, not a vector. As a backdoor you mostly care about humans noticing you messed with their system. You have defeated and subverted the machine and now need to keep the meat ignorant. So you want to avoid having random suspiciously named files lying around or weird extraneous processes showing up. Even the most technologically illiterate users know to watch for weird processes.
There are a number of ways. For example shell extensions. Even Chrome, which took great care to not load them missed a few, which I used to get my DLL running inside Chrome without the antivirus complaining. This was some years ago, don't know if they fixed this (and is not really a bug, is by design, sort of).
> you would have neutralized any antivirus software.
That is extremely difficult and fragile. Much better to just not trigger it in the first way by behaving like a "normal" app. The user is also much more likely to notice a non-updating antivirus than some random process.
If the program is coded properly or compiled with a recent compiler/headers, it will search System32 (or SysWoW64) first before its own directory. In other words, it might or might not depending on how the program-in-question is compiled/coded.
It depends on what you consider stealth. This is the equivalent of someone social engineering their way into a building by looking like an employee. Are they using stealth? By the definition of the word, I think so.
> Anyways. This isn't 'stealthy'. Not at all. It's hardly the bare minimum.
It's using techniques to encourage people and systems overlook it when it's noticed. I think that qualifies.
Running something is as easy as hijacking one of those “copy and paste this line into your command prompt to install this package” things you see on many open source sites. The command always curls some bigger script down and executes it. Often times it even has you sudo to root.
While it would be prudent to examine the script rather than just blindly execute it... I imagine most don’t (myself included).
I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well. I hate the idea of any arbitrary, unknown side-effects happening to my system. Providing an archive `.deb`, `.rpm`, etc is at least more convenient and predictable so it can be installed like a normal package by your package manager (although it doesn't truly help in terms of security or side-effects as it can still run scripts, so although ultimately the issue is still running binaries not vetted by your distro's maintainers)
> I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well.
They're fine for security and super convenient. I get why it's so popular - packaging and publishing debs is often going to be a lot more work, and now you're in the world of either maintaining a package repo or having to deal with an official one.
When you set your CI/CD pipeline, creating packages, signing them and updating your repositories are all trivial tasks (been there, done that).
In this case, explicitly telling "this is my repository and this is the public key. gnupg the key, add this repository line, and get the packages" provides an end to end verified package pipeline. No .sh scripts to compromise.
If you keep your private keys on a network detached place and only plug your keys while signing stuff, things are pretty secure out of the box.
Actually it's not hard at all. All you need is a half-working build system and tar installed. You just create an additional build target and you're fine.
If you maintain the repository yourself now your setup instruction involves adding a custom apt repo, and then the installation. You also now have to handle multiple package managers, etc. A simple bootstrap script is pretty much as easy as it gets.
As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs.
Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.
> curl into sh is just as safe as any other software installation mechanism
It most certainly is not. Grabbing random code from some site is not the same as installing a package from a known repository which has been tested and inspected by a maintainer. Of course the latter isn't perfect, but it is way more assurance than the none whatsoever of a random script from an unknown source.
But, we’re talking about installing software from non-distribution sources. E.g. the Minecraft Launcher ships as a .deb that you install: there’s no benefit security-wise for that over curl … | sh
And, I doubt most people have the time or ability to read all the scripts that come with large software packages and ensure that they’re safe. For better or worse, executing code downloaded from the internet without verifying it manually is the norm these days.
curl'ing is not the same at all as running, say, a Debian apt-get install.
You apt-get signed packages coming from official mirrors (at least I do). Most of the Debian packages, by very far, are also fully deterministic and reproducible. If someone serves a backdoored package, that's probably incredibly noisy, leaving lots of traces everywhere and evidence can be gathered.
When you curl, there's no way to know if you're the "lucky" one to get served malware by the server on that one curl call.
Even if you aren't running official debs or RPMs, you're still quite a bit above running a build script off the web. A deb or RPM will include a manifest with checksums, which you can at a minimum use to confirm whether some post-isntall script or process changes an included file (such as removing or cleaning a malicious script that was included). In the case of RPM (at least, I'm not implying debs don't do this, just that I'm not as familiar with them) you can actually query any pre/post install scripts that were shipped with it as well:
# rpm -q --scripts bash
postinstall scriptlet (using <lua>):
nl = '\n'
sh = '/bin/sh'..nl
bash = '/bin/bash'..nl
f = io.open('/etc/shells', 'a+')
if f then
local shells = nl..f:read('*all')..nl
if not shells:find(nl..sh) then f:write(sh) end
if not shells:find(nl..bash) then f:write(bash) end
f:close()
end
postuninstall scriptlet (using <lua>):
-- Run it only if we are uninstalling
if arg[2] == "0"
then
t={}
for line in io.lines("/etc/shells")
do
if line ~= "/bin/bash" and line ~= "/bin/sh"
then
table.insert(t,line)
end
end
f = io.open("/etc/shells", "w+")
for n,line in pairs(t)
do
f:write(line.."\n")
end
f:close()
end
Even a downloaded package that's not signed is far more auditable after the fact than executing arbitrary commands from a remote source.
I can also pipe the script into a file and read it: it’s much easier to vet a simple shell script than an rpm or whatever anyways. But, my point just is that the vast majority are going to trust the package they downloaded to be safe: most people installing Minecraft on Linux from a .rpm they downloaded from Mojang aren’t going to audit the RPM, they’re just going to install it, maybe even with (it’s been a while since I’ve used RPMs, so my syntax is probably off here):
rpm -ip https://mojang.com/Minecraft-launcher.rpm
Which has all the same problems as curl | sh
The checksums don’t really matter here: if I can compromise the package, I can also compromise the checksums.
> I can also pipe the script into a file and read it
Except then it's not the same idiom. Piping curl to a shell is not the same thing as downloading and running an installer, even if that installer happens to be a shell script. Part of the main problem is that the installation steps are ephemeral. It's nearly impossible to confirm that what was run when you installed it is what you see when you check the installation URL now, where now may be a week, a month or a year later.
> Which has all the same problems as curl | sh
No, I just god through outlining some of the ways it specifically is different in the prior comment. At a minimum, you know what launcher was installed, and what URL it's set to check, and what version it is in case there's a bug in the launcher. It shares some problems with piping an online script to a shell, but not all of them. You may think the ways in which they differ don't matter, but that's an opinion, and I hold a different one. They are different in real ways though.
You are right. Adding third-party PPAs is not secure (it is because Linux distributions are not friendly to third-party software), that's why it is always better to download and unpack such software manually without running it as root.
White side effects does Nix have when you install a package? IIUC it just updates the programs that are symlinked into various locations (like a directory in your $PATH).
If you’re installing from a binary cache, that’s true, but a nix expression is just a build specification: it can run any program available to build and install a package. The “normal” way this works is you install the software to $out and $out gets copied into the nix store, but a malicious nix package can bypass this (and, assuming you’re not using nix’s sandboxing mechanisms, do arbitrary things to your computer).
Building without a sandbox is really pushing the definition of "just installing a package". Also the sandbox is enabled by default on at lest NixOS.
I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
We aren’t really talking about installing packages from official distributions, right? We’re talking about things like installing an interesting tool from GitHub using the ability of nix to download an build master.tar.gz. In most of these cases, there’s always going to be some amount of reliance on the assumption that the developer of the software is trustworthy.
Also, I mainly use nix on Mac, where the sandbox is disabled by default and doesn’t work as well as the Linux sandbox, by all accounts.
You say that like doing so is a negative thing. How do you think executable code gets on a system in the first place?
Either an Admin builds from source, an Admin installs a binary from a source they deem trustworthy, or you YOLO, download something sketchy to an older system and watch what your Network Analyzer/reverse engineering stack spits out.
App stores changed none of that in terms of fundamental activity one needs to do. They just lull users into a false sense of security because "someone else did it". I've run into too many devs who salivated over the idea of embedding cryptominers in game clones to believe it isn't done on a semi-regular basis.
> App stores changed none of that in terms of fundamental activity one needs to do.
This just isn’t true: app stores vary but they added some key changes — developers have a reputation to worry about, stores restrict what APIs you can call, and it provides a single place to force updates or pull malware. That’s not perfect, of course, but it’s better than just installing whatever you find online — Facebook et al. wouldn’t be upset with Apple if it wasn’t working.
> I've run into too many devs who salivated over the idea of embedding cryptominers in game clones to believe it isn't done on a semi-regular basis.
Reminds me of early days in my career when my mentor and I were discussing user issues with a library we maintained. I didn't realize it at the time, but he was messing with me by suggesting we add some hooks to report usage statistics back to us and use that to improve things.
I was young and naive so excuse that I got really excited at the genius of the idea. If not for his wry smile, I would have happily run off and implemented just that.
It's telling that you got grayed out that fast for what I don't think is an uncommon programming life lesson to try to instill.
What people run on their machine is no one's business but theirs. Undisclosed/non-consensual information leakage is unethical, and immoral. Period. I'm also not entirely on the status-quo of "accept the EULA or F off" form of disclosure or consent facilitation either. If someone reaches out, by all means, get the detailed info you need, but don't pull it. Let them push it. Other folk's machines don't become yours by virtue of executing some version of a computation you wrote once, no matter how badly Microsoft, IBM, Intel, and the FAANG's wish that were the case.
Note, this would be considered anti-thetical to most corporate or for-profit interests in the computing space; so don't be surprised if you get blowback or static for it.
“Trust” is something you can give, though, as long as it’s not to the whole world.
Do you trust the Debian project? I mean, there’s reasons to trust them but if you don’t, then don’t run Debian.
If you do: the package repositories carry their chain of trust, since they’re signed by Debian maintainers- not the application developers themselves.
That’s a large distinction.
App stores didn’t give us trust; they have developers direct access to users and, crucially, the ability to charge for software- which was not a consideration for package managers before.
And Apple for the most part has been trying to carry the “burden” of ensuring trust, at a high cost.
Or just copying a command with a hidden `<span>` in the middle, then pasting it into a terminal which allows multiline pastes (which most terminals do).
This isn't my area of expertise but ... where did they find this?
>On March 25, 2021, 360 NETLAB's BotMon system flagged a suspiciousELF file (MD5=64f6cfe44ba08b0babdd3904233c4857) with 0 VT detection, the sample communicates with 4 domains on TCP 443 (HTTPS), but the traffic is not of TLS/SSL. A close look at the sample revealed it to be a backdoor targeting Linux X64 systems, a family that has been around for at least 3 years.
They saw it communicating over the network? But ... where was it? On their linux system? Someone else's? Any idea how it got there?
BotMon is a "DDoS botnet C2 command tracking system". So I guess they're doing some kind of traffic analysis. https://ddosmon.net/faq doesn't say much.
"0 VT detection" means that no virus scan on VirusTotal detected it.
360 is a huge, and I cannot emphasise how huge, antivirus company in China. It is also widely known for slowing down consumer Windows, hijacking IE (with the grace to add an identical logo but in green), and adding spyware to 'keep you safe'. They also pay well and employ some pretty competent people.
PSA: when communicating known malicious FQDN/URLs in good cause, either add [.] before TLD or use hxxps URL scheme(e.g. example[.]com or hxxps://example.com).
Modern websites/browsers recognize these and disable autolinking.
It’s not clear to a non-systems person, me specifically, whether this is something that was added to Linux code base itself, or as a virus-like file that was added and has spread.
The article didn't say anything of it being added to any code base, so no.
It's just another "backdoor" which had been installed by a hacker or malware. (Backdoor doesn't mean it's build into existing systems, it means it gives you access to a system through a unintended path. Most backdoors are installed by hackers or other malware to allow the attacker to again gain access at a later point. Most viruses bundle a backdoor, but it totally can be a separate thing).
Pardon me if it's a stupid question, but a backdoor to what? I don't really understand what it's about. In my mind a backdoor is hidden feature built into another _useful_ piece of software.
Is this "just a backdoor"? Like, its sole purpose is to give remote access / exfiltrate information? If so, how does it end up on systems? What is the vector?
The term "backdoor" kind of has two commonly used but somewhat different meanings: an embedded backdoor and an access backdoor. (Or perhaps "application backdoor" vs. "system backdoor".)
The first meaning is what you describe: something malicious stealthily implanted into an otherwise-legitimate or thought-to-be-legitimate application or appliance.
The other meaning covers any method of secret access persistence on a compromised system (generally a host, like a server). This could be something like a bash script that launches a reverse shell when you login, a malicious kernel module that extracts and executes arbitrary C code if a specific pattern is detected in network traffic, or just about anything imaginable. And you could also achieve it with the former definition.
I think among the infosec community, it's indeed more common for "backdoor" to refer to the former and a general term like "persistence" / "persistence mechanism" (though that can potentially refer to anything malicious that persists), or sub-categories like "foothold", to refer to the latter. "Backdoor" for the latter wouldn't be a misuse, though.
There's also a possible looser third definition, where lazy / fearmongering anti-virus companies sometimes like to label almost any kind of malware a "backdoor" or "backdoor trojan", perhaps because that carries more frightening implications for end users than a term like "virus" or "malware". It somewhat overlaps with the second definition, but I think it's rare a technical person would use it that way; it's less rare that a technical person might use the second definition.
This is what you drop on a system after it's compromised for use later, it's a RAT.
It gets there via some kind of compromise, either an insecure application, some drive-by exploit for some missing patch, owning a sysadmin and pushing it out via ansible/salt/etc.
it's a virus. lol. there are many ways to get them onto systems. file download site, typosquatted apt/pip package names, buying/hacking a download mirror website, 0-day browser exploits, etc.
I think the computer term for the thing that most resembles how a meatspace virus behaves and propagates is "worm". Most worms can probably be classified as viruses, but most viruses nowadays (thankfully) aren't worms. (It can also generally refer to anything that's malicious and recursively self-propagating, like Samy's infamous Myspace XSS worm [1].)
Meatspace viruses are like computer worms, though computer viruses and computer worms aren't like meatspace worms; for that and a laundry list of other reasons, "malware" has superseded a lot of those terms among the infosec community.
> I think the computer term for the thing that most resembles how a meatspace virus behaves and propagates is "worm".
A compuyter virus self propagates with human intervention. A worm self propagates without human intervention.
I think the biological item that most closely resembles a work would be a parasite that is self-mobile. E.g. a botfly.
Various computer virus' in the past propagated through floppy drives and infected floppies, but you were safe as long you didn't initiate the action that caused the infection (use the floppy in your computer). Also, you can get a virus by visiting a website, which is also initiated by the uninfected.
Worms used infected host resources to actively seek out and infect other hosts without any initiating action by those other hosts.
In this way, meatspace viruses are NOT like computer worms. They don't cause their hosts to seek out people to infect. Infection is either coincidental or requires some allowance by the candidate (close contact, use of shared resources, etc).
That's true. Biological viruses are kind of in between computer viruses and computer worms.
I still think a worm is a decent analogy, though. For example, the first thing a worm will often do is scan the local network and try to infect each "living host" it finds in its vicinity. In some sense it can be seen as having some kind of willpower or intention, but it's a little more like a blind, unthinking process of trying to constantly fire itself in all directions, not unlike how a virus is unthinkingly regularly emitting itself into the air around it to infect those in its vicinity.
How does it help them? If you find file with this MD5 on your system, you have either the virus, or a colliding binary crafted by the attackers - bad in either case \o/
It's not quite clear to me, but is this Malware part of any of the popular Linux distributions, or was it part of an infection on that particular machine through some installation after the fact?
This is why Linux firewall is terrible at blocking systemd’s access to a network port.
Yeah, I had a corner case where I wanted to use ISC DHCP client (due to Juniper DHCP server at my ISP) where I wanted to block all network access to systemd.
Alas, no can do. So i’ve since moved over to Denuvan distro where SysV unit can still be used while having Debian APT repo.
This is a plus for OpenBSD which can firewall by-PID (PID 1, systemd).
The user (perhaps running as root) was tricked into installed it. It has nothing to do with the kernel installation.
The file name is chosen by the attackers to look like a legit executable - systemd-daemon if installed as root, $HOME/.gvfsd/.profile/gvfsd-helper if installed without root privileges. That way victims who are looking at file names won't be alarmed because they look like an expected file e.g. hiding in the forest of legit "systemd-*" files.
"Based on" is a little imprecise. IIRC, the two were developed simultaneously and cooperatively, until Kubrick deviated at the end in some ways that made Clarke mad.
The kernel repository, i.e. where the kernel code comes from is source-only and didn't had anything todo with that ;-).
The kernel any OS including linux runs is not source only at all, it's compiled, maybe by the user from source or by a redistributor which then passes it in compiled form to your system.
Furthermore this malware seem to not mess with the kernel, but pretend to be a normal system service.
ELF means Executable and Linkable Format, it's the executable format which Linux binaries use (and not just them). E.g. a shared library (Linux version of DLL) is in elf format. A variation of ELF is also used by UEFI but that doesn't seem to matter in this article.
So basically someone or something hacked their system and installed this malware or they where tricked into installing it themself.
The fact that the involved files where named in ways which totally could be normal parts of the system didn't help (but is also common, so I wouldn't say it made it harder).
I know you are not supposed to blanket block foreign IP's, but I often do that and it seems to knock down a fair bit of crap. Also saves you from inadvertently messing up GPDR.
Attribution of malware can be difficult and the lack of details like who was targeted and missing plugins don't leave enough information to guess who might have been interested in developing this.
This is pretty cool, but I keep waiting until someone finds a horribly malicious version of bash that hides processes, directories and so on unless you have a specific env var set.. It could even detect when you do a update and just copy itself back over the new version, since almost all updates are being applied under a shell somewhere (may need a malicious python also then..)
Back in my younger days... I’ve had boxes hacked through bugs in bind or sendmail. The hacker would cover their tracks with replacements of “ps”, “ls” and such that attempted to cover their tracks. Good times.
Replacing coreutils used to be a semi-common persistence strategy on Linux, you either swapped out the actual tools or a common library with one that had a hook to start up your RAT or whatever other malicious payload. It had the advantage of almost certainly getting it started very quickly after boot without necessarily leaving anything in an "obvious" place (e.g. cron, profile scripts, etc). I haven't seen this in a while, I would guess the increasing use of antivirus/rootkit detection (these things would be pretty easy to signature) and auditing package managers are both factors.
Actually, last time I saw it the cracker (really a script) had replaced a couple of libraries with 32 bit versions on a 64 bit machine, which lead to most of the coreutils no longer working. Very subtle. 64-bit machines were becoming common by that point but maybe not so much on Linux servers, but still it was a clear sign of low effort!
Some of my containers run for weeks between deploys, I’d like to know what changes in ‘em just as much as thay oldskool iaas db server marketing uses ;)
I don't think anyone bothers to backdoor a shell in that way. Why not just target libc via LD? That tricks bash, sh, python, etc; but you can use setuid to check for the existence of malware that is evading through LD_PRELOAD.
Cat : So my guess is the point where the virus author slipped is not making the traffic to port 443 look like genuine HTTPS. The moment a firewall notices 443 and NOT HTTPS it is tell-telle sign of something.
Why can’t Linux keep track of parent-child relationships and visualize them when you look at running processes? You could instantly identify this virus. And why can’t Linux apps have a universal and straightforward install directory?
> Why can’t Linux keep track of parent-child relationships and visualize them when you look at running processes?
Linux does keep track of parent-child process relationships. Linux, however, is just a kernel. It's not your operating system and it's definitely not your GUI.
It does. You're mistaking reparenting with another concept: the concept of an absolute parent PID.
The concept of an absolute parent PID is nonsensical. Having an absolute parent PID would reduce the maximum number of processes effectively infinitely by creating a linked list of parent IDs even if the original parent process is gone.
Imagine if PID 2 is a parent process. It spawns a child. The child spawns a child. That child spawns a child... all the way down to the maximum number of PIDs... the final child is PID n. Then, all of the intermediate processes exit.
The final child process with the maximum PID wants to look at its parent process... but it's gone. Now, what do you want the kernel to do?
Should the kernel tell you about that PID n-1? What if another process has been created and has inherited PID n-1? Does your check now think that the process's parent is still alive? Your check is incorrect and will lead to very aggrevating bugs. Should the kernel prevent PID n-1 from being reused? Congrats you've basically just reinvented zombie processes.
No. The solution is to just reparent PID n onto PID 1 and tell you that process is the parent now. Then you, as a developer, have to actually deal with an aspect of computer science: lifetime management of your objects processes. And the kernel is therefore more efficient for the vast majority of processes who don't need or care about their parent.
It can't fully work. The kernel forgets parent-child relationships when processes die. Every orphan is adopted by init, and the kernel doesn't bother to remember the original parent. I've always hated this.
Anybody want to fix it?
The simple fix, kind of bad, is to simply remember the number and report it. The trouble here is that the number might get recycled. Adding a boolean to indicate "my original parent died" would help.
The proper fix is to keep some PID values allocated. Do not free a PID value until all the children of it have died. This would mean that every living process without a living original parent would have a ghost parent that gets reported to ps.
Sadly, for compatibility reasons, the getppid() call would need to report the adoptive parent. The fix for this is to add a new system call that reports both the original parent PID and a flag to indicate adoption.
> The proper fix is to keep some PID values allocated. Do not free a PID value until all the children of it have died.
Any fork bomb at all will exhaust the pid graveyard, wouldn't it? You could change pid_t to 64 bits but then the pid graveyard would take a lot of memory in the kernel.
For an actual fork bomb, nothing ends up in the PID graveyard. No process ever dies. The fork bomb by itself is a problem, even without a PID graveyard. Process limits are required to stop a fork bomb.
For other situations, just keep the direct parents. Worst case, that doubles the PID usage.
It doesn't even do "normal" rootkit level of hiding that rootkit detectors might notice; it just hides in plain site as an innocent root process, right out in the open.