Re: [GENERAL] PostgreSQL 7.2.2: Security Release
От | Bruce Momjian |
---|---|
Тема | Re: [GENERAL] PostgreSQL 7.2.2: Security Release |
Дата | |
Msg-id | 200208240438.g7O4c8225214@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] PostgreSQL 7.2.2: Security Release (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: [GENERAL] PostgreSQL 7.2.2: Security Release
Re: [GENERAL] PostgreSQL 7.2.2: Security Release Re: [GENERAL] PostgreSQL 7.2.2: Security Release |
Список | pgsql-hackers |
The issue is data-provoked crashes vs. query-invoked crashes. Marc's point, and I think it was clear enough, is that you can't just poke at the TCP port and hope to do anything bad, which was the thrust of the argument, I think. --------------------------------------------------------------------------- Neil Conway wrote: > "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 > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: