Re: Change User on a pconnect
| From: | Sascha Schumann | Date: | Sat, 06 Nov 1999 19:40:44 +0000 |
| Subject: | Re: Change User on a pconnect | ||
| References: | 1 2 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-12184@lists.php.net to get a copy of this message | ||
On Sat, Nov 06, 1999 at 01:54:15PM -0500, Rasmus Lerdorf wrote:
> > On Sat, 6 Nov 1999, Rasmus Lerdorf wrote:
> >
> > > > > By the way, what prevents someone from guessing a persistent link
> > > > > identifier and using it without authenticating on it right now? I
> > > > > don't
> > > > > see the code that prevents this, but I should take a closer look.
> > > > > I'll
> > > > > play with this stuff this afternoon. I'll probably wait until after
> > > > > 3.0.13/4.0RC2 before I commit it though to avoid last-second breakage.
> > > >
> > > > hmm, in PHP 4 the link would be a resource and only c-modules can create
> > > > resources. in PHP 3 this could be a problem, and thinking a bit longer
> > > > .... i believe every script could guess a link-number - that's not good.
> > >
> > > Yeah, I was only looking at PHP 3 code where the thing is just an
> > > integer. I'd like to verify/fix this before 3.0.13 and will get right on
> > > it after lunch here.
> >
> > rasmus,
> >
> > that sounds non-trivial to me! in php4 we just need to make sure that only
> > c-modules can create resources.
> >
> > the only thing that comes to mind is to offset link-id's by an offset
> > that's randomly generated in the RINIT() function of the module (or
> > global). that way link-id's would be "harder" to guess...
> >
> > the whole thing is only an issue for ISP with evil customers, isn't
> > it? (one customer tries to steal data from another customers table in the
> > same database-instance)
>
> Actually, I am unable to actually write an exploit here. It is because
> the plist resource does not exist for the persistent link for the
> current request until we do a connect and create it, and we can't create
> this plist resource unless we authenticate. So, it doesn't look like
> there is a problem here.
I agree that auditing PHP is useful. If we find any
exploitable hole, we should fix it. PHP 3.0.13 has been in
pseudo-freeze for a long time; I'm convinced that it will be
the most stable release ever. Let people play with the new
version now.
--
Regards,
Sascha Schumann
Consultant