Nmap Development mailing list archives

Error in http.lua's chunked encoding


From: Joao Correa <joao () livewire com br>
Date: Tue, 18 Aug 2009 13:54:19 -0300

Accidentally I have only replied the e-mail below to Ron. Here follows
the e-mail with a patch that fix the problem attached. Ron have
already confirmed that this patch fixed the problem for him also. It
would be nice if more people could test it, mainly with requests to
chunked response servers, in order to verify if it does not introduce
any problem.

Thanks.
Joao.

Follows, the e-mail.

I've made some superficial reading on the RFC 2616. It seems that,
even the request being a HEAD, the server is returning the CRLF
(carriage return, line feed) chars, that are supposed to close a
chunked response. I've added a small check inside the loop, comparing
the response to see if it is only equal to the body delimiter
previously checked.

I think that this patch is a little bit better than the previous, but
maybe it is not the silver bullet yet.

It is working fine here!

On Tue, Aug 18, 2009 at 9:39 AM, Ron<ron () skullsecurity net> wrote:
Still getting issues. Sorry! :)

NSE: http-enum against 72.14.213.147:80 threw an error!
./nselib/http.lua:120: Chunked encoding didn't find hex at position 1; got
"\
".
stack traceback:
       [C]: in function 'error'
       ./nselib/http.lua:120: in function '(for generator)'
       ./nselib/http.lua:834: in function 'parseResult'
       ./nselib/http.lua:682: in function 'pipeline'
       ./scripts/http-enum.nse:169: in function <./scripts/http-enum.nse:42>
       (tail call): ?


I don't personally know anything about chunked encoding. It may be
worthwhile to learn, though. I don't know how common this is, but Google
does it, and I was using them to test.


On 08/17/2009 11:03 PM, Joao Correa wrote:

Ron,

The problem happens because the server is returning an extra \n. Do
you know if this is a usual thing? Maybe under the conditions of
making HEAD requests under a pipeline to a server that responds with
chunked encoding, this is the default way of answering.

The patch will fix the problem, but probably there is a better way of
solving this issue. Maybe it worths taking a look at the RFC to see if
there is an expected behavior to this situation.

If you have more problems, please, let me know.

Thanks,
Joao

On Tue, Aug 18, 2009 at 12:01 AM, Ron<ron () skullsecurity net>  wrote:

Sure, I attached a -d3 output as well as a pcap.

On 08/17/2009 09:52 PM, Joao Correa wrote:

Ron,

Would you mind sending the output of a scan with -d3?

Thanks,
Joao

On Mon, Aug 17, 2009 at 11:30 PM, Ron<ron () skullsecurity net>    wrote:

Hmm, that didn't fix it for me, although it did change the error. I now
get:

./nselib/http.lua:164: Didn't find CRLF after chunk-size [
chunk-extension ]
at position 2; got "OF\
".
stack traceback:
       [C]: in function 'error'
       ./nselib/http.lua:164: in function '(for generator)'
       ./nselib/http.lua:834: in function 'parseResult'
       ./nselib/http.lua:682: in function 'pipeline'
       ./scripts/http-enum.nse:169: in
function<./scripts/http-enum.nse:42>
       (tail call): ?


Sorry for not looking into this myself. :)

On 08/17/2009 09:24 PM, Joao Correa wrote:

Hi Ron,

The problem happens because the request made was a HEAD request, where
no body exists. The following patch fixed the problem for me. Thanks!

Joao Correa

On Mon, Aug 17, 2009 at 10:57 PM, Ron<ron () skullsecurity net>
 wrote:

http.lua seems to have an issue with certain hosts. I can reliably
cause
an
error when I scan google with http-enum.nse:

-
$ ./nmap --script=http-enum -p80,443 -T4 -d www.google.ca

Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-08-17 20:55 CDT
--------------- Timing report ---------------
 hostgroups: min 1, max 100000
 rtt-timeouts: init 500, min 100, max 1250
 max-scan-delay: TCP 10, UDP 1000, SCTP 10
 parallelism: min 0, max 0
 max-retries: 6, host-timeout: 0
 min-rate: 0, max-rate: 0
---------------------------------------------
NSE: Loaded 1 scripts for scanning.
Warning: Hostname www.google.ca resolves to 6 IPs. Using
72.14.213.105.
Initiating Ping Scan at 20:55
Scanning 72.14.213.105 [2 ports]
Completed Ping Scan at 20:55, 0.06s elapsed (1 total hosts)
Overall sending rates: 31.58 packets / s.
mass_rdns: Using DNS server 4.2.2.1
mass_rdns: Using DNS server 4.2.2.2
Initiating Parallel DNS resolution of 1 host. at 20:55
mass_rdns: 0.12s 0/1 [#: 2, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1]
Completed Parallel DNS resolution of 1 host. at 20:55, 0.12s elapsed
DNS resolution of 1 IPs took 0.12s. Mode: Async [#: 2, OK: 1, NX: 0,
DR:
0,
SF: 0, TR: 1, CN: 0]
Initiating Connect Scan at 20:55
Scanning pv-in-f105.google.com (72.14.213.105) [2 ports]
Discovered open port 443/tcp on 72.14.213.105
Discovered open port 80/tcp on 72.14.213.105
Completed Connect Scan at 20:55, 0.06s elapsed (2 total ports)
Overall sending rates: 31.47 packets / s.
NSE: Script scanning 72.14.213.105.
NSE: Starting runlevel 1 scan
Initiating NSE at 20:55
NSE: NSE Script Threads (2) running:
NSE: Starting http-enum against 72.14.213.105:443.
NSE: Starting http-enum against 72.14.213.105:80.
NSE: http-enum against 72.14.213.105:80 threw an error!
./nselib/http.lua:120: Chunked encoding didn't find hex at position
1;
got
"".
stack traceback:
       [C]: in function 'error'
       ./nselib/http.lua:120: in function '(for generator)'
       ./nselib/http.lua:834: in function<./nselib/http.lua:783>
       (tail call): ?
       ./scripts/http-enum.nse:97: in
function<./scripts/http-enum.nse:42>
       (tail call): ?

NSE: http-enum.nse: Warning: Host returned 302 and not 200 when
performing
HEAD.
NSE: http-enum.nse: Host returns 302 instead of 404 File Not Found.
NSE: Total number of pipelined requests: 41
NSE: Number of requests allowed by pipeline: 40
NSE: Number of received responses: 42
NSE: Finished http-enum against 72.14.213.105:443.
Completed NSE at 20:55, 1.57s elapsed
NSE: Script Scanning completed.
Host pv-in-f105.google.com (72.14.213.105) is up, received syn-ack
(0.061s
latency).
Scanned at 2009-08-17 20:55:40 CDT for 2s
Interesting ports on pv-in-f105.google.com (72.14.213.105):
PORT    STATE SERVICE REASON
80/tcp  open  http    syn-ack
443/tcp open  https   syn-ack
Final times for host: srtt: 61415 rttvar: 26591  to: 167779

Read from .: nmap-services.
Nmap done: 1 IP address (1 host up) scanned in 1.98 seconds
-

Hope that helps!

I think I found another one, too, but I'm having trouble reproducing
it.
Will get back to you on that one.

--
Ron Bowes
http://www.skullsecurity.org/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org




------------------------------------------------------------------------


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


--
Ron Bowes
http://www.skullsecurity.org/


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


--
Ron Bowes
http://www.skullsecurity.org/



--
Ron Bowes
http://www.skullsecurity.org/

Attachment: http-chunk-2.diff
Description:


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

Current thread: