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/
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.
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.