Re: libwww security advisory

Vic Bancroft writes:

> My intent was to check in the results of
> 
>     [bancroft@hilbert libwww]$ patch Library/src/HTBound.c < HTBound.c.diff
>     patching file Library/src/HTBound.c
> 
> Is there some modification to HTMIME.c that is needed for a complete 
> revision ?

Nope.  HTMIME.c is ok.

> It would also help to have some nice examples of these problematic HTTP 
> 1.1 byte range requests for testing . . .

The problematic HTTP requests are very timing-dependent.

Try sending an HTTP request for two byte ranges, with each range being 200 
bytes long, and somehow get the HTTP server to return the HTTP header and 
the first 100 bytes of the first byte range in one packet, and have the rest 
of the response follow a few seconds later.

You're trying to arrange for libwww's first read() on the stream to return 
the HTTP header and the first half of the first byte range.  Your goal is to 
have libwww() set up the entire protocol stack with HTBound below HTMIME, 
and have HTBound terminate and unwind all the way back up to the net stream 
layer to read() the rest of the stream, and push it back down.

If you can set up this kind of a test environment, I'm pretty sure you 
should be able to see some bizarre results.

If you do something like this:

HTRequest_addRange(htr, "bytes", (char *)"0-199,200-299");
HTLoadToStream(url, yourstream, htr);

then your stream should expect to receive 400 bytes (presuming that the 
document being requested is at least 400 bytes long).  If you can somehow 
arrange to get the HTTP server's response to have the header and the first 
hundred, or so, bytes in the first packet, and the rest to follow a few 
seconds later, then your stream is going to receive only 200 bytes.  That's 
the behavior I was seeing here.

On a local LAN, thanks to Apache's aggressive buffering, the entire HTTP 
response should fit into a single ~1500 byte packet by default, and you 
won't normally get hit by this.  Even larger responses will probably not 
trigger this bug, due to socket buffering.

If you can't jury-rig a delayed HTTP response, try asking for a pair of one 
megabyte byte ranges, something like: "0-999999,1000000-1999999".  I'm 
pretty sure the original HTBound.c is going to break here, although my 
eyeballs can only vouch for a pair of shorter byte ranges on a very, very 
loaded server :-)