[arch-general] Zombie Processes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 To all, I was wondering regarding the killing of a zombie process. As far as I know, a zombied process is inherited by root when it's parent is killed. The kernel periodically calls wait() which reaps the zombie process and frees its memory. I was wondering if a possible attack could be mounted by the zombie process when it is inherited by root. Regards, Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlP9HiYACgkQZ/Z80n6+J/aSXwEAgrFI8dEuDrtqJhBUtSm+HuVO OMqMDsy/UN4DdcZJHjUA/3PYKpsgBBg11avnhTolV1+KLijgG16gGGPM8XSKhNxd =A2N2 -----END PGP SIGNATURE-----
On 26/08/14 07:54 PM, Mark Lee wrote:
To all,
I was wondering regarding the killing of a zombie process. As far as I know, a zombied process is inherited by root when it's parent is killed. The kernel periodically calls wait() which reaps the zombie process and frees its memory. I was wondering if a possible attack could be mounted by the zombie process when it is inherited by root.
Regards, Mark
Orphaned processes are inherited by init (pid 1). A modern init like systemd uses an event loop and handles the signals (SIGCHLD) in a non-blocking fashion. Linux also provides the ability to turn other processes into sub-reapers, and has a concept of process namespaces where the first process in the namespace is treated as init for those processes. I don't think this is a viable attack surface.
On Wed, Aug 27, 2014 at 1:54 AM, Mark Lee <mark@markelee.com> wrote:
I was wondering regarding the killing of a zombie process. As far as I know, a zombied process is inherited by root when it's parent is killed. The kernel periodically calls wait() which reaps the zombie process and frees its memory. I was wondering if a possible attack could be mounted by the zombie process when it is inherited by root.
No, since a zombie process is dead and cannot execute any code. Also, "root" in this case refers to the process hierarchy root (PID 1; init or systemd) and not the user "root". Not the kernel but PID 1 is responsible for reaping.
On 27 August 2014 02:03, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:
No, since a zombie process is dead and cannot execute any code.
To expand more on that: zombie process in not really a process anymore. In fact, it's not anything more than a little bundle of data (basically just an integer containing the exist status of the process and some flags) that are processed by wait(). Lukas
On 27 August 2014 02:03, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:
No, since a zombie process is dead and cannot execute any code.
To expand more on that: zombie process in not really a process anymore. In fact, it's not anything more than a little bundle of data (basically just an integer containing the exist status of the process and some flags) that are processed by wait().
That's very interesting, I have always been taught that zombies are bad because they take up resources like memory and CPU cycles, hold locks etc. Are you saying that is wrong and the only thing being taken up is just a tiny bundle of data? Andy
Are you saying that is wrong and the only thing being taken up is just a tiny bundle of data?
Exactly.
On Wednesday, August 27, 2014 02:48:55 PM Andy Pieters wrote:
On 27 August 2014 02:03, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:
No, since a zombie process is dead and cannot execute any code.
To expand more on that: zombie process in not really a process anymore. In fact, it's not anything more than a little bundle of data (basically just an integer containing the exist status of the process and some flags) that are processed by wait().
That's very interesting, I have always been taught that zombies are bad because they take up resources like memory and CPU cycles, hold locks etc.
Are you saying that is wrong and the only thing being taken up is just a tiny bundle of data?
Andy
It doesn't make sense that zombie processes would take up anything more than a few bits (possibly a bit more) somewhere if you understand what exactly they are. Zombie processes are just processes that have finished doing everything they need to do. The only reason they're still around (even though they're not, the result of their execution is stored along with a few things and the process just sits idle) is because their parent process hasn't checked to "reap" the child process yet (hence the term "zombie process", the process is actually dead, but it partially isn't treated as such since the parent still needs to get information from it). Since the process isn't actually active it wouldn't make sense for it to be taking up CPU cycles (if it is given a cycle, it will just pass it off), memory (it's done executing, there's nothing left to store in memory except the result), locks (again, nothing is running if it's holding a lock there's a problem), or anything else of that nature.
Kevin Ott wrote:
It doesn't make sense that zombie processes would take up anything more than a few bits (possibly a bit more) somewhere if you understand what exactly they are. Zombie processes are just processes that have finished doing everything they need to do. The only reason they're still around (even though they're not, the result of their execution is stored along with a few things and the process just sits idle) is because their parent process hasn't checked to "reap" the child process yet (hence the term "zombie process", the process is actually dead, but it partially isn't treated as such since the parent still needs to get information from it). Since the process isn't actually active it wouldn't make sense for it to be taking up CPU cycles (if it is given a cycle, it will just pass it off), memory (it's done executing, there's nothing left to store in memory except the result), locks (again, nothing is running if it's holding a lock there's a problem), or anything else of that nature.
Thank you Kevin that makes it perfectly clear to me :)
participants (7)
-
Andy Pieters
-
Daniel Micay
-
Jan Alexander Steffens
-
Kevin Ott
-
Lukas Jirkovsky
-
Mark Lee
-
toerb