Re: arbitrary memory allocation
- From
Stefan Beller <sbeller@google.com>
- Date
- Dec 1, 2015, 01:03 UTC
- Message-ID
- <CAGZ79kaqSOeK4E6+yKLCP63bK6Fd4XmP=8XcMqMqP_fMLTsbAA@mail.gmail.com>
- In-Reply-To
- <xmqqmvtv6n0b.fsf@gitster.mtv.corp.google.com>
On Mon, Nov 30, 2015 at 4:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 39 quoted lines
> ytrezq@sdf-eu.org writes:
>
>> 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);(Looking quickly), I do not see a deduplication in add_object_array, so you could send the same want line again and again, to inflate the want_obj array.
If you happen to know a large object in a well known project (some linux blob maybe?), it would be held a lots of times in memory, which may trigger the OOM killer in linux?
Show 12 quoted lines
> } > > 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. > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html