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 по дате отправления: