Possible security hole

[jw schultz]

On Sat, Oct 04, 2003 at 11:38:48PM +0300, Timo Sirainen wrote:
> Maybe security related mails should be sent elsewhere? I didn't notice 
> any so here it goes:
> 
> sender.c:receive_sums()
> 
> 	s->count = read_int(f);
> ..
> 	s->sums = (struct sum_buf *)malloc(sizeof(s->sums[0])*s->count);
> 	if (!s->sums) out_of_memory("receive_sums");
> 
> 	for (i=0; i < (int) s->count;i++) {
> 		s->sums[i].sum1 = read_int(f);
> 		read_buf(f,s->sums[i].sum2,csum_length);
> ..
> 
> If I read this right, given high enough s->count makes the malloc() 
> parameter wraps around to a few bytes while still reading data past it.

You read that correctly.  In order to force that to happen
stat would have to report the file as being 21,743,270,000TB
in size or a fixed block-size would have to be specified
such that file-size/block-size > 119,304,600.

A sanity check wouldn't hurt.  Doing so would protect
servers from nuts spoofing an rsync client doing a send to
an rsync server where an admin was foolish enough to allow
public writes.  Also might make sense to do a double check
in generator.c where the values are calculated in the first
place.

> Exploiting is probably pretty difficult if at all possible. There would 
> have to be some interesting data after the returned pointer. I didn't 
> check if there is. Anyway, exit_cleanup() leads to at least a few 
> free() calls which could make it exploitable.
> 
> I think there's also some potential problems with 64bit systems. 
> There's a few arrays that assume it's size will fit into int. Normally 
> you'd get out of memory before getting that high, but in 64bit systems 
> with enough memory you won't. Of course this also requires sending 
> gigabytes of data, but internet is fast nowadays.

If you care to do an audit, ok.  I don't recall any such
arrays where the array member count would not fit into an
int. 

Do include tested patches in your reports.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt