Re: arbitrary memory allocation

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 1, 2015, 00:17 UTC
Message-ID: <xmqqmvtv6n0b.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1a012fc79a55cae8b948b28d1259be0c.squirrel@sdfeu.org>

ytrezq@sdf-eu.org writes:

Show 16 quoted lines

> line_list="0032want "+obj[1][:40]+'\n'
> while len(line_list)<65430: # Get the ideal tcp packet size for fastest bandwidth (64Ko)
> 	for i in obj:
> 		if (i==obj[0]) or (i==obj[1]) or ("pull" in i):
> 			continue
> 		line_list+="0032want "+i[:40]+'\n'
> 		if len(line_list)>65480:
> 			break
> ...
> line_list_len=line_list.count('\n')*56 # Line lengths of the pkt-line format won t fill the ram, so remove them from the size counter
> count=line_list_len
> while True:
> 	sys.stdout.flush()
> 	sockobj.send(line_list) # for each line, the git-send-pack process allocate append a member to a struct objects array
> 	print("\r%.2f Mo of ram filled" % float(count/float(1048576))),
> 	count+=line_list_len

This seems to be attempting to throw "want XXXXXXXX" that are outside the original server-side advertisement over and over. Even though the set of distinct "want" lines you can throw at the server is bounded by the server-side advertisement (i.e. usually you won't be able to throw an object name that does not appear at the tip), by repeating the requests, you seem to be hoping that you can exhaust the object_array() used in upload-pack.c::receive_needs().

But does that attack actually work? After seeing these "want" lines, the object name read from there goes through this code:

		o = parse_object(sha1_buf);
		if (!o)
			die("git upload-pack: not our ref %s",
			    sha1_to_hex(sha1_buf));
		if (!(o->flags & WANTED)) {
			o->flags |= WANTED;
			if (!is_our_ref(o))
				has_non_tip = 1;
			add_object_array(o, NULL, &want_obj);
		}

So it appears to me that the requests the code makes in the second and subsequent iterations of "while True:" loop would merely be an expensive no-op, without bloating memory footprint.

It does waste CPU cycle and network socket, though.