Re: [GENERAL] PostgreSQL 7.2.2: Security Release
От | Neil Conway |
---|---|
Тема | Re: [GENERAL] PostgreSQL 7.2.2: Security Release |
Дата | |
Msg-id | 87sn14anri.fsf@mailbox.samurai.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] PostgreSQL 7.2.2: Security Release ("Marc G. Fournier" <scrappy@hub.org>) |
Ответы |
Re: [GENERAL] PostgreSQL 7.2.2: Security Release
|
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: