Re: Re: CVE id request: php5

["Steven M. Christey" <coley () linus mitre org>]

That was me.  This basically came through a separate effort to catch up on
a backlog of CVEs from 2008, and I forgot about this discussion (that was
literally 3,700 CVEs ago).  There is a disclaimer in the CVE desc that
says how limited the scope is.  It's definitely on the edge of inclusion
CVE-wise.

- Steve


On Thu, 27 Aug 2009, Tomas Hoger wrote:

> On Thu, 29 Jan 2009 12:20:14 -0500 (EST) "Steven M. Christey"
> <coley () linus mitre org> wrote:
>
> > On Thu, 29 Jan 2009, Joe Orton wrote:
> >
> > > If the script is taking untrusted input data and passing it
> > > unsanitized as the "key" argument to a dba_replace() call, it can
> > > override arbitrary keys in the ini file anyway.  Truncating the ini
> > > file to zero length seems like a less severe problem than being
> > > able to write (arbitrary?) data to arbitrary keys.
> >
> > We don't have any formal criteria for this kind of thing, but in
> > general, we ask whether there are realistic scenarios under which an
> > attack can succeed, and if any additional privileges are gained
> > versus normal methods.  These questions are particularly applicable
> > to language interpreters and compilers.  Given this scenario, it
> > seems unrealistic that an app would perform a dba_replace() with
> > user-controlled input - and if it does, then it's a vuln in the
> > application, not PHP itself.  So it doesn't seem to require a CVE.
>
> Just for posterity, this got CVE-2008-7068 after all.
>
> --
> Tomas Hoger / Red Hat Security Response Team