Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in
От | Vince Vielhaber |
---|---|
Тема | Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in |
Дата | |
Msg-id | Pine.BSF.4.40.0208201609190.19197-100000@paprika.michvhf.com обсуждение исходный текст |
Ответ на | Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
|
Список | pgsql-hackers |
On Tue, 20 Aug 2002, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > Here's yet another. He claims malicious code can be run on the server > > with this one. > > regression=# select repeat('xxx',1431655765); > server closed the connection unexpectedly > > This is probably caused by integer overflow in calculating the size of > the repeat's result buffer. It'd take some considerable doing to create > an arbitrary-code exploit, but perhaps could be done. Anyone want to > investigate a patch? I think we likely need something like > > bufsize = input_length * repeats; > + /* check for overflow in multiplication */ > + if (bufsize / repeats != input_length) > + elog(ERROR, "repeat result too long"); > > but I haven't thought it through in detail. Where do we check that this: result = (text *) palloc(tlen); is even successful? Is it in one of the macros (VARATT_SIZEP or VARDATA)? It appears like it goes into the count and copy regardless. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
В списке pgsql-hackers по дате отправления: