Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
От | Bruce Momjian |
---|---|
Тема | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
Дата | |
Msg-id | 200208202004.g7KK4Wk19641@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
Список | pgsql-hackers |
Nigel J. Andrews wrote: > On Tue, 20 Aug 2002, Tom Lane wrote: > > > "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes: > > >> I'd like to see something done about this fairly soon, but it's not > > >> happening for 7.3 ... > > > > > Does anyone have an idea about what other functions are affected by this? > > > > As a first approximation, every output function for a built-in > > pass-by-reference datatype will show this same behavior. cash_out is > > just getting picked on because it was the one mentioned in the first > > complaint. For that matter, every input function for any datatype > > has the same problem: > > regression=# select cash_in(2); > > server closed the connection unexpectedly > > > > ... > > But going back to the idea that it seems that the only problem being publicized > in the 'outside world' is the cash_out(2) version can we not do the restriction > on acceptable input type in order to claim that the fix? > > Obviously this is only a marketing ploy but on the basis that a real fix seems > unlikely before beta in 11 days time (I'm still trying to work out what Tom's > suggestion is) perhaps one worth implementing. If we wanted to hide the vulnerability, I wouldn't have put it on the TODO list. One of our styles is not to deceive people; if we have a problem, we document it so others know about it and so someday someone will fix it --- today may be that day. ;-) -- 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 по дате отправления: