"Marc G. Fournier" <scrappy@hub.org> writes:
> On 24 Aug 2002, Neil Conway wrote:
> > If the application is accepting datetime input from the user ('what's
> > your birthday?', for example), and isn't doing some non-obvious input
> > validation on it (namely, checking that the input string isn't too
> > long), you can crash the backend. Gavin says executing arbitrary code
> > using the hole would be extremely difficult, but it's at least
> > conceivable.
>
> Right, but you have to get a connection to the backend in order to crash
> it ... no?
You need to be using an application accepts datetime input from the
user, and at some point inserts it into the database. For example, if
you wrote a webapp that accepted datetime input of some kind (to use
my previous example, the user's birthday), any user of the webapp
could enter bogus data that would crash the backend.
In this case, the user does not make a connection to the backend (the
web app does), and does not have the ability to execute arbitrary SQL
(i.e. it's not a "shared" or "open" system) -- but a security problem
still exists.
This is in contrast to the other security holes (repeat(), lpad(),
rpad(), SET TIME ZONE, and TZ env var), in which the probability of
someone without SQL access being able to exercise the bug is
negligible.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC