Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

Поиск
Список
Период
Сортировка
От Gavin Sherry
Тема Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Дата
Msg-id Pine.LNX.4.21.0208211611390.7175-100000@linuxworld.com.au
обсуждение исходный текст
Ответ на Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in  (Thomas Lockhart <lockhart@fourpalms.org>)
Ответы Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Список pgsql-hackers
On Tue, 20 Aug 2002, Thomas Lockhart wrote:

> ...
> > So I think that fixing the opaque problems in 7.2.x is simply
> > impossible. Given that, the question is whether we should make a 7.2.2
> > release with fixes for the other security holes (lpad(), rpad(),
> > reverse(), and the datetime overruns). IMHO, we should.
>
> Just a minor point: can someone actually show a symptom with date/time
> problems in 7.2.x?

template1=# select version();                          version
-------------------------------------------------------------PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC
2.96
(1 row)

template1=# select

'1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111'::date
server closed the connection unexpectedly       This probably means the server terminated abnormally       before or
whileprocessing the request. 
The connection to the server was lost. Attempting reset: Failed.
!#

ParseDateTime() isn't checking that str < MAXDATELEN -- which is the
problem you solved in the datetime.c fixes.

Gavin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: How to disable encoding validation during database restore
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: pgstattuple change using SRF