Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
От | Tom Lane |
---|---|
Тема | Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd) |
Дата | |
Msg-id | 1751.1029873911@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd) (Vince Vielhaber <vev@michvhf.com>) |
Ответы |
Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd) |
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: