What is the concrete advantage of using random PIDs instead of traditional sequential ones?

Some times ago, I've read an article in the french magazine MISC (no. 74 - July/August, 2014) publishing a flaw affecting stunnel and libssh, article written by the discoverer of these flaw himself.

To make things short, this flaw relies on the fact that a hello cookie created by the server is generated using the current Unix timestamp (so up to the second) and the PID of the process handling the request. The exploit sends a high number of connections attempts in order to force the server to generate duplicated cookies. At the end this attacks aims to deduce the server private keys.

The author explains that such attack is not realizable on systems using sequential PID because it would require more than 65000 connections attempts to made in less than one second.

However thanks to random PIDs the author demonstrates that, with 20 connection attempts per seconds, there is statistically more than one chance over two to generate a duplicate in less than 5 minutes.

For me, this clearly shows that random PID creates new security weaknesses over sequential PIDs.

I was therefore wondering what was the exact threat that random PIDs are trying to solve. The answer I got from here, here, there and my personal experience do not satisfy me:

  • Poorly coded software are using the PID to generate "unique" temporary file names and as a main source of entropy: poorly coded software should remain limited to "Hello world" projects and minesweepers ports and should never be used for sensitive tasks. Moreover, weakening the whole OS just to bring a marginal security gain for such software seems really counter-productive. At last, the flaws above show that as long as entropy is concerned, sequential PID would be even more secure than random ones...
  • Protection against unknown future threats: I do not see the logic behind opening severe current and known threats to protect against potential future and unknown threats...
  • Race conditions: if it refers to the poor software using the PID to generate temporary file names, then I already covered this point. Otherwise, the flaw above shows how random PID is more prone to race conditions than sequential ones.
  • OpenBSD already uses it: this is indeed a good explanation regarding the fashion aspect of this measure, but it has nothing to do with security.
  • Yeah I don't really see the reasoning behind random pids. There is this vulnerability which made me think that if sequential pids were predictable maybe you could write to specific processes? But I feel like there are easier ways to learn about the system rather than attempting use use pids. – RoraΖ May 7 '15 at 14:17
up vote 17 down vote accepted

I complete my own answer after a more in-depth comparison between the OSes I am the more familiar with and which have taken quite surprisingly different directions...

PID randomization was popularized by OpenBSD which added it as soon as 1997. At that time it pursued two main goals:

  • Protect against PID prediction vulnerabilities affecting mostly software which use the PID value to generate temporary file names. This was a common concern at that time, but today I think it would be quite rare to encounter production-level software still not using a proper method.

  • As a general preventive measure, "If something can be random, make it random.", encompassing putting randomness at several places in the OS (from the IP stack to the memory allocation). While some of the protection resulting from this randomness proved to be useful and became more common, PID randomization has a more troubled history.

As detailed in my question, the cure may be worse than the disease. Due to faster PID reuse, fully random PID may allow remotely exploitable flaws, while sequential PID was mainly known to allow local-only exploits.

As a side note, in an ideal world, all this should not cause any issue (yes, I talk of this ideal world where software is free of bugs and vulnerabilities). In fact these vulnerabilities usually find their root in wrong usage of the PID. Wikipedia finely defines the PID as being a "number used [...] to uniquely identify an active process". Therefore:

  • A PID is not designed to build temporary file names. Temporary files are usually created in a shared place, and that means danger! Because of this, temporary files must be created using dedicated functions which will ensure that the three required actions (checking that the file doesn't already exists, create it and set restricted access permissions) are done in an atomic (uninterrupted) way. The C language proposes mkstemp() and tmpfile(), and most Unix environments offer a mktemp command to be used by shell scripts, etc.

  • A PID is not designed to seed a random number generator or generate session ID or cookies. Here again you must refer to your language or environment documentation to get a proper entropy source. On UNIX systems the /dev/urandom device file is there for this purpose.

  • It is not by accident that Wikipedia definition precises active process. On some language like C, you stay proprietary of the child process' PID until you wait for it, but this is not true for all languages (for instance in shell scripts...) and never true for processes which are not your child. In these cases the PID is just a shared resource, and you should remember that this "shared" notion implies "danger", so must therefore ensure that your take proper care and use the right functions designed to match your situation and needs.


Linux

Linux kernel main stream never implemented PID randomization, however this feature was commonly provided for several years through a security oriented third-party patch which finally decided to abandon it.

Around year 2000-2001, several people tried to implement PID randomization for the Linux kernel (examples can be found here and there), however none of these patches were accepted by the kernel development team who rejected them mostly as "security through obscurity".

However, since randomness may actually increase the global security posture of the OS and prevent some attacks, these kernel modifications finally reached their public through the third-party project: grsecurity.

This project started in 2001, bringing several new and advanced security features to the Linux kernel. It allowed to enable/disable randomized PID using a specific sysctl parameter: kernel.grsecurity.rand_pids. However, in the late 2006 (I guess - I hate news thread mentioning dates with no year!) they finally decided to drop randomized PID functionality:

grsecurity 2.1.10 was released today for Linux 2.4.34 and 2.6.19.2. Changes in this release include:

  • Removal of randomized PIDs feature, since it provides no useful additional security and wastes memory with the 2.6 kernel's pid bitmap

OpenBSD

OpenBSD having initiated randomized PID functionality, it is still present for historical purposes but has no real security scope nowadays. It is up to the application themselves to ensure they correctly handle fast PID reuse.

OpenBSD aim is to encourage good development practices and thorough code security auditing. That's why they consider that it is not the responsibility of the OS to protect their users against flawed application. On the contrary an application flaw should be detected as soon as possible and corrected in the application instead of remaining hiden by OS ("The sooner we can break it, the sooner we can fix").

As a side note, while such assertion justifies itself for the base OS which is under direct control of the OpenBSD team, this becomes more discutable with third-party software:

However, in this context OpenBSD team makes the assumption that, for a correctly developed and audited software, the PID generation algorithm chosen by the OS must have no impact (neither stability nor security) on the software behavior. If some software is vulnerable to an attack taking advantage of the PID being reused, then it's up to the software to be corrected, and not to the OS to ensure that the PID are not reused too quickly².


¹: A third-party commercial company, M:Tier, provides its own update system to reduce this issue.

²: For the curious, OpenBSD added in 2013 an hardcoded table storing the 100 lastly freed PIDs in order to limit reliability issues on low loaded systems. However, this does not constitutes a security measure since it quickly becomes effectless with higher loads, would this load be caused by genuine activity or as part of an attack.


FreeBSD

FreeBSD provides a sysctl parameter allowing the administrator to tune the PID generation algorithm from sequential to fully random. It is sequential by default.

FreeBSD implemented random PIDs in 1999 (FreeBSD 4), using OpenBSD as reference, and improved it to let the administrator set a balance between potential issues caused by sequential PID (mostly PID prediction) and potential issues caused by PID randomization (PID reuse and resource consumption).

In fact, FreeBSD design seems quite original since it is not actually the PID which is random, but the PID increment which is a random value taken between 1 and the kern.randompid parameter:

  • If PID randomization is disabled, then the increment will always be 1,
  • At maximum this parameter can be set to PID_MAX³, in this case the next PID will be fully randomly chosen.

By default PID randomization is disabled (PIDs are generated sequentially). To take effect, the kern.randompid parameter must be at least greater than 100.

If sequential PID remains a concern, I would personally recommend to set this parameter to a low value like a few hundreds: this should be sufficient to limit trivial PID prediction issues while avoiding more nasty issues caused by PIDs re-use.


³: For the purists it is actually PID_MAX - 100 to cover only non-reserved PID range, it can also be set by using the special value -1. Out of range values are corrected immediately when setting the sysctl parameter so no risk to cause any damage here anyway.

  • Would you consider making it more explicit at the start of your answer why using only PIDs as means to identify resources owned/accessed by unprivileged clients is a security issue? In particular could you clarify that security issues occur only when a client's identity is represented in terms of something that is not unique to this client over time and clients are mutually distrusting? Might help beginners understand what was wrong and not use something else than PIDs that is equally wrong. – Steve DL Jun 3 '15 at 13:12
  • @SteveDL: Thank you for your advice. I've added a side notes paragraph in the intro, feel free to send another feedback if something is missing or unclear :) – WhiteWinterWolf Jun 5 '15 at 15:08
  • Cool, thanks :-) – Steve DL Jun 5 '15 at 16:01

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.