[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [patch #8097] httpd: Return failure if parsing Content-Leng
From: |
Fatih Aşıcı |
Subject: |
[lwip-devel] [patch #8097] httpd: Return failure if parsing Content-Length fails |
Date: |
Mon, 20 Jan 2014 12:25:49 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 |
Follow-up Comment #2, patch #8097 (project lwip):
Since I changed my job, I don't have an environment to reproduce the problem
quickly. I'll try to answer it as far as I remember.
The problem occurs when one of the following situations happens:
* Content-Length value has more digits than
(HTTP_HDR_CONTENT_LEN_DIGIT_MAX_LEN - 2) [1]
* Content-Length header does not exist
It is easy to reproduce the first one by posting a 4G file. If
LWIP_HTTPD_SUPPORT_REQUESTLIST is defined, then the function returns with
ERR_INPROGRESS. When this value is returned, pbuf is not free'd. After a
while, pbuf pool gets full and lwip is not able to process next requests.
It seems the current code does not use any other methods to get the size of
POST body. It also does not inform the application layer if Content-Length
header is not found. With this issue, it is trivial to make a device
inaccessible.
[1] It looks for a CRLF inside HTTP_HDR_CONTENT_LEN_DIGIT_MAX_LEN sized area
starting from the end of "Content_Length: ". For a size of 4G, CR and LF are
left outside of this range.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/patch/?8097>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/