Re: Random PID implementation and security
On 05/27/15 10:18, Simon wrote: Le 2015-05-26 16:25, Theo de Raadt a écrit : Le 2015-05-26 00:10, Miod Vallat a =C3=A9crit=C2=A0: It is not the responsibility of the operating system to protect its users against software which assumes using the pid as a random source= =20 is a bright and wise idea. =20 Isn't this the whole goal of random PIDs, to put a defense at OS level=20 protecting software against themselves when they make wrong assumption=20 regarding the PID and use it for wrong purposes? A 16 bit PID is suppsed to provide true safety? Please. The problem is people who believe that shoving a 16 bit value into a deterministic function gets them somewhere. So do you confirm that random PID is actually not a security measure? It is often presented as is, but it would not be the first time that some wrong rumors get widespread enough to become accepted as a truth by most people. I could also easily imagine that PID have been randomized just because it was allowed to do so and that it was interesting from the coding perspective as showing up software bugs that sequential PID would hardly uncover (I'm mainly referring here to Ted Unangst's talk: http://www.openbsd.org/papers/dev-sw-hostile-env.html, see randomization section, backed by the philosophy section: The sooner we can break it, the sooner we can fix it). Having PID's that are not easily predicable helps to reduce the attack surface. IMO that is a security measure, but YMMV. Fred
Re: Random PID implementation and security
Le 2015-05-26 16:25, Theo de Raadt a écrit : Le 2015-05-26 00:10, Miod Vallat a =C3=A9crit=C2=A0: It is not the responsibility of the operating system to protect its users against software which assumes using the pid as a random source= =20 is a bright and wise idea. =20 Isn't this the whole goal of random PIDs, to put a defense at OS level=20 protecting software against themselves when they make wrong assumption=20 regarding the PID and use it for wrong purposes? A 16 bit PID is suppsed to provide true safety? Please. The problem is people who believe that shoving a 16 bit value into a deterministic function gets them somewhere. So do you confirm that random PID is actually not a security measure? It is often presented as is, but it would not be the first time that some wrong rumors get widespread enough to become accepted as a truth by most people. I could also easily imagine that PID have been randomized just because it was allowed to do so and that it was interesting from the coding perspective as showing up software bugs that sequential PID would hardly uncover (I'm mainly referring here to Ted Unangst's talk: http://www.openbsd.org/papers/dev-sw-hostile-env.html, see randomization section, backed by the philosophy section: The sooner we can break it, the sooner we can fix it).
Re: Random PID implementation and security
On Tue, May 26, 2015 at 9:50 PM, Simon openbsd.li...@whitewinterwolf.com wrote: [...] Unless specific cases, I do not think that programmers assume that PID are especially sequential or not, but merely rely on the hypothesis that: - PID are unguessable, - PID will not be reused quickly. And yes, it seems possible to fulfill these two properties by providing unguessable and not quickly reusable PID instead of pure random PID. But not in 16 bits. To a patient remote attacker, the difference between 2 minutes and 2 days is not significant. 64 bit PIDs anyone? High 16 and low sixteen randomized and the middle 32 backwards sequential, just to really throw the unwary attacker off the trail? ;-/ -- Joel Rees Be careful when you look at conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself, as well.
Re: Random PID implementation and security
A 16 bit PID is suppsed to provide true safety? Please. Having PID's that are not easily predicable helps to reduce the attack surface. IMO that is a security measure, but YMMV. Random PIDs is that plastic part, not the padlock. -- May the most significant bit of your life be positive.
Re: Random PID implementation and security
On Wed, May 27, 2015 at 5:18 AM, Simon openbsd.li...@whitewinterwolf.com wrote: So do you confirm that random PID is actually not a security measure? It is often presented as is, but it would not be the first time that some wrong rumors get widespread enough to become accepted as a truth by most people. language isn't an exact thing. words can mean different things to different people, or different things to the same people in different contexts. I would consider PID randomization to be a security measure, although I would not consider it a solution or fix to the problem it addresses. rather, it is a mitigation that reduces the severity of a problem without actually fixing it. whether you think of it as a security measure depends on whether you define a measure as a fix, or a mitigation, or as either/both. where we get into trouble is when people mistake it for a fix and believe that they no longer need to worry about this problem. that is false. -ken
Re: Random PID implementation and security
Le 2015-05-27 11:53, Fred a écrit : On 05/27/15 10:18, Simon wrote: Le 2015-05-26 16:25, Theo de Raadt a écrit : A 16 bit PID is suppsed to provide true safety? Please. The problem is people who believe that shoving a 16 bit value into a deterministic function gets them somewhere. So do you confirm that random PID is actually not a security measure? It is often presented as is, but it would not be the first time that some wrong rumors get widespread enough to become accepted as a truth by most people. I could also easily imagine that PID have been randomized just because it was allowed to do so and that it was interesting from the coding perspective as showing up software bugs that sequential PID would hardly uncover (I'm mainly referring here to Ted Unangst's talk: http://www.openbsd.org/papers/dev-sw-hostile-env.html, see randomization section, backed by the philosophy section: The sooner we can break it, the sooner we can fix it). Having PID's that are not easily predicable helps to reduce the attack surface. IMO that is a security measure, but YMMV. Fred There is a difference between having random PIDs and having PIDs which are not easily predictable. For instance, dividing the 16 bits of the PID to make the 8 lower bits as a counter and 8 higher bits as a random value would provide both not easily predictible and not quickly reused PIDs. However, minor the 100 items array, OpenBSD uses random PIDs. While it indeed reduces the attack surface against PID predictions (mostly local exploits) it facilitates attacks relying on PID reuse (includes remote exploits, so attacks with higher risk than local exploits). So all in all I'm not convinced at all that using random PIDs reduces the attack surface, I was actually worrying if it may not be actually counter productive in terms of security.
Re: Random PID implementation and security
Le 2015-05-27 14:01, Janne Johansson a écrit : A 16 bit PID is suppsed to provide true safety? Please. Having PID's that are not easily predicable helps to reduce the attack surface. IMO that is a security measure, but YMMV. Random PIDs is that plastic part, not the padlock. You mean it's just decorative ;) ?
Re: Random PID implementation and security
Le 2015-05-27 14:29, Kenneth Gober a écrit : On Wed, May 27, 2015 at 5:18 AM, Simon openbsd.li...@whitewinterwolf.com wrote: So do you confirm that random PID is actually not a security measure? It is often presented as is, but it would not be the first time that some wrong rumors get widespread enough to become accepted as a truth by most people. language isn't an exact thing. words can mean different things to different people, or different things to the same people in different contexts. I would consider PID randomization to be a security measure, although I would not consider it a solution or fix to the problem it addresses. rather, it is a mitigation that reduces the severity of a problem without actually fixing it. whether you think of it as a security measure depends on whether you define a measure as a fix, or a mitigation, or as either/both. where we get into trouble is when people mistake it for a fix and believe that they no longer need to worry about this problem. that is false. -ken I agree with you Ken. I see PID randomization like stack protection for instance: in the best world a software should have no bug and should not be vulnerable to any buffer overflow, however in a real world there are still vulnerable software around and here such protection may help. The same principle also apply for PID generation method: normally it should not even matter if PID were sequential, fully random or pseudo-random, but the reality is that there are still bugs around and still vulnerable software around, and that the OS may implement systems mitigating such risks.
Re: Random PID implementation and security
On Wed, May 27, 2015 at 02:34:43PM +0200, Simon wrote: Le 2015-05-27 11:53, Fred a écrit : On 05/27/15 10:18, Simon wrote: Le 2015-05-26 16:25, Theo de Raadt a écrit : A 16 bit PID is suppsed to provide true safety? Please. The problem is people who believe that shoving a 16 bit value into a deterministic function gets them somewhere. So do you confirm that random PID is actually not a security measure? It is often presented as is, but it would not be the first time that some wrong rumors get widespread enough to become accepted as a truth by most people. I could also easily imagine that PID have been randomized just because it was allowed to do so and that it was interesting from the coding perspective as showing up software bugs that sequential PID would hardly uncover (I'm mainly referring here to Ted Unangst's talk: http://www.openbsd.org/papers/dev-sw-hostile-env.html, see randomization section, backed by the philosophy section: The sooner we can break it, the sooner we can fix it). Having PID's that are not easily predicable helps to reduce the attack surface. IMO that is a security measure, but YMMV. Fred There is a difference between having random PIDs and having PIDs which are not easily predictable. For instance, dividing the 16 bits of the PID to make the 8 lower bits as a counter and 8 higher bits as a random value would provide both not easily predictible and not quickly reused PIDs. However, minor the 100 items array, OpenBSD uses random PIDs. While it indeed reduces the attack surface against PID predictions (mostly local exploits) it facilitates attacks relying on PID reuse (includes remote exploits, so attacks with higher risk than local exploits). So all in all I'm not convinced at all that using random PIDs reduces the attack surface, I was actually worrying if it may not be actually counter productive in terms of security. Please go troll somewhere else. Software that breaks if a PID is reused too soon is inherently broken and the operating system should not try to protect these broken programs. Please put your effort into fixing those broken programs instead of spreading FUD here. -- :wq Claudio
Re: Random PID implementation and security
Sorry for interruption. I have sent the message by mistake, please ignore it. 2015ë 5ì 27ì¼ (ì) 23:17, yjh0...@gmail.comëì´ ìì±: hi
Re: Random PID implementation and security
2015-05-27 15:42 GMT+02:00 Joel Rees joel.r...@gmail.com: On Tue, May 26, 2015 at 9:50 PM, Simon openbsd.li...@whitewinterwolf.com wrote: [...] Unless specific cases, I do not think that programmers assume that PID are especially sequential or not, but merely rely on the hypothesis that: - PID are unguessable, - PID will not be reused quickly. And yes, it seems possible to fulfill these two properties by providing unguessable and not quickly reusable PID instead of pure random PID. But not in 16 bits. To a patient remote attacker, the difference between 2 minutes and 2 days is not significant. 64 bit PIDs anyone? High 16 and low sixteen randomized and the middle 32 backwards sequential, just to really throw the unwary attacker off the trail? ;-/ Having a part of the PID being sequential and a part being random is non-sense. The more bit you throw in the random part, the less chance you have to have collision. The more bit you throw in the sequential part, the more time you have before you start to have a chance to have a collision. Problem is, those bit turn into power of two. So going from 16bit to 8bit is the same as going from 65,536 to 256. OpenBSD found a way out of this problem. All the bits used in a PID are random and you have to wait for an arbitrary 100 PID before you start to have a chance to get duplicate. But like Theo said, the problem is that PID shouldn't have been used in the first place.
Re: Random PID implementation and security
hi
Re: Random PID implementation and security
Le 2015-05-26 00:10, Miod Vallat a écrit : It is not the responsibility of the operating system to protect its users against software which assumes using the pid as a random source is a bright and wise idea. Isn't this the whole goal of random PIDs, to put a defense at OS level protecting software against themselves when they make wrong assumption regarding the PID and use it for wrong purposes?
Re: Random PID implementation and security
Op Tue, 26 May 2015 11:07:06 +0200 schreef Simon openbsd.li...@whitewinterwolf.com: Le 2015-05-26 00:10, Miod Vallat a écrit : It is not the responsibility of the operating system to protect its users against software which assumes using the pid as a random source is a bright and wise idea. Isn't this the whole goal of random PIDs, to put a defense at OS level protecting software against themselves when they make wrong assumption regarding the PID and use it for wrong purposes? One can protect against programmers assuming sequential allocation and one can protect against programmers assuming random allocation, but not both. -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Random PID implementation and security
Le 2015-05-26 12:58, Boudewijn Dijkstra a écrit : Op Tue, 26 May 2015 11:07:06 +0200 schreef Simon openbsd.li...@whitewinterwolf.com: Le 2015-05-26 00:10, Miod Vallat a écrit : It is not the responsibility of the operating system to protect its users against software which assumes using the pid as a random source is a bright and wise idea. Isn't this the whole goal of random PIDs, to put a defense at OS level protecting software against themselves when they make wrong assumption regarding the PID and use it for wrong purposes? One can protect against programmers assuming sequential allocation and one can protect against programmers assuming random allocation, but not both. Unless specific cases, I do not think that programmers assume that PID are especially sequential or not, but merely rely on the hypothesis that: - PID are unguessable, - PID will not be reused quickly. And yes, it seems possible to fulfill these two properties by providing unguessable and not quickly reusable PID instead of pure random PID. Moreover, would I have to choose between random PID adding a protection against potential local exploits but opening potential remote exploits, and sequential PID opening potential local exploits but at least not causing remotely exploitable weaknesses, I would tend to consider sequential PID more secure than pure random PID (as long as one considers that remotely exploitable vulnerabilities have higher severity than local ones). Unguessable and not quickly reusable PID would be the third and most secure option, providing protection both against local and remote exploits (and keeping ports people hair (reference to Theo de Raadt answer in the current thread) in a more reliable way than the 100 items array which is effectless in loaded environments).
Re: Random PID implementation and security
Don't use PID for seeding ever, in fact don't use seeding. If you want a random integer use arc4random(), if you want a random buffer use arc4random_buf(). There is more even to arc4random(3) which is up to you to read in the manpage system. Sincerely, -peter
Re: Random PID implementation and security
Le 2015-05-26 00:10, Miod Vallat a écrit : It is not the responsibility of the operating system to protect its users against software which assumes using the pid as a random source is a bright and wise idea. Isn't this the whole goal of random PIDs, to put a defense at OS level protecting software against themselves when they make wrong assumption regarding the PID and use it for wrong purposes? A 16 bit PID is suppsed to provide true safety? Please. The problem is people who believe that shoving a 16 bit value into a deterministic function gets them somewhere.
Re: Random PID implementation and security
These software were using the child process PID + a Unix timestamp as seed. Such patterns are the problem. End of story, really. OpenBSD, as a security conscious OS, has already implemented a protection against such exploit (cool :) !), but I'm surprised by the technical choices made here (less cool :( ). The protection has been added in the revision 1.150 (mid-2013) of the file `src/sys/kern/kern_fork.c'. It adds a array of a fixed and hardcoded size of 100 entries storing the lastly freed PIDs (`pid_t oldpids[100];'). That is not a protection; actually more of a strategy to deal with badly written code so that the ports guys don't lose their hair as quickly. I was wondering why this has never been implemented? At the first glance, this seem to be the safe and best way to do, isn't it? The safe way is to avoid use of such deterministic non-random functions, and for the good of the community go on attack against the remaining places they are used. deterministic(seed) is not random.
Random PID implementation and security
Hello, I had a question regarding random PID usage and implementation in OpenBSD. Sorry by advance if my question may seem obvious, but I did not manage to find any really satisfying answer. I was reading an article (french magazine MISC issue 74) written by the author of CVE-2014-0016 (stunnel) and CVE-2014-0017 (libssh) affecting the random number generator used by the server to construct the hello cookie. These software were using the child process PID + a Unix timestamp as seed. The author demonstrated how, on systems using random PIDs, it was therefore easy to trick the system into generating two times the very same cookie (a very few minutes with an average of as few as 20 requests per second), thus giving the opportunity to deduce private keys thanks to some cryptographic magic out of scope here. On the other side, systems using a traditional sequential PID were practically not vulnerable to this attack since it would need to be able to remotely make the server cycle through all the available PID in less than a second. As per my understanding, random PID was implemented mostly in order to protect bogus application using the PID to generate temporary file names and other race conditions (cited by most sources without ever defining what kind of race condition they precisely mean). The example above show that it just does not prevent race conditions, actually it helps them, and while it protect against the locally exploitable temporary file name prediction it opens remotely exploitable flaws which seems worse. FreeBSD servers are particularly subject to such attacks because they generate really random PIDs, so it takes 3-4 minute in average with 20 requests per seconds to get the system generate two identical PID during the same second. OpenBSD, as a security conscious OS, has already implemented a protection against such exploit (cool :) !), but I'm surprised by the technical choices made here (less cool :( ). The protection has been added in the revision 1.150 (mid-2013) of the file `src/sys/kern/kern_fork.c'. It adds a array of a fixed and hardcoded size of 100 entries storing the lastly freed PIDs (`pid_t oldpids[100];'). So, blindly execute the 20 requests described in the article will indeed not work on a lowly loaded OpenBSD system. However, on a highly loaded system (whether the load results from genuine traffic or is part of the attack), this array will just become useless and OpenBSD falls as well as FreeBSD. Years ago (2003) Theo de Raadt wrote an email (http://www.monkey.org/openbsd/archive/misc/0301/msg00720.html) as part of a discussion related to PID randomization side-effects in which he mentions At best, we could use some sort of high-bit non-repeating trick like we do with dns and ip id's. I suppose he was referring to what has been implemented in `src/sys/netinet/ip_id.c' ensuring that an ID will not be reused for at least 32768 calls. I was wondering why this has never been implemented? At the first glance, this seem to be the safe and best way to do, isn't it? PID related security issues mainly seems to come from application wrongly assuming that: - PID are unguessable, - PID will not be reused quickly. IMHO PID full randomization as implemented in FreeBSD correctly addresses the first assumption, but heavily breaks the second one. A more clever partial randomization would address both aspects, effectively improving security for both local and remote attacks. The current small array of 100 entries seems quite weak to me, while the model based on IP id generation would seem more resistant but has nevertheless be left in profit of this small array... I suppose there must be a good reason behind this choice, but I do not manage to get it, would you help me to understand this? Thank you by advance, Best regards, Simon.
Re: Random PID implementation and security
It is not the responsibility of the operating system to protect its users against software which assumes using the pid as a random source is a bright and wise idea. That is only the beginning of it. The entire concept of merging a 32 bits of globally known data, with 16 bits which are less well known -- and this is called a seed, and given to an entirely deterministic function and then calling that random Where random must mean reasonably well guessable, I suppose. This is more than a meme. It is a plot. It must take a lot of maintainance to regurgitate that kind of bad practice back into the software ecosystem over and over again. We have all this fuss about bad crypto libraries, and governments sniffing... Then we have people who still believe it is possible to perturb the above 16 bit value and make some things even partly safe... Boggles the mind.
Re: Random PID implementation and security
It is not the responsibility of the operating system to protect its users against software which assumes using the pid as a random source is a bright and wise idea.
