BUG/MEDIUM: h1: Don't support LF only to mark the end of a chunk size

It is similar to the previous fix but for the chunk size parsing. But this
one is more annoying because a poorly coded application in front of haproxy
may ignore the last digit before the LF thinking it should be a CR. In this
case it may be out of sync with HAProxy and that could be exploited to
perform some sort or request smuggling attack.

While it seems unlikely, it is safer to forbid LF with CR at the end of a
chunk size.

This patch must be backported to 2.9 and probably to all stable versions
because there is no reason to still support LF without CR in this case.
This commit is contained in:
Christopher Faulet 2024-01-26 16:30:53 +01:00
parent 7b737da825
commit 4837e99892
2 changed files with 7 additions and 14 deletions

View File

@ -303,14 +303,12 @@ static inline int h1_parse_chunk_size(const struct buffer *buf, int start, int s
* for the end of chunk size.
*/
while (1) {
if (likely(HTTP_IS_CRLF(*ptr))) {
/* we now have a CR or an LF at ptr */
if (likely(*ptr == '\r')) {
if (++ptr >= end)
ptr = b_orig(buf);
if (--stop == 0)
return 0;
}
if (likely(*ptr == '\r')) {
/* we now have a CR, it must be followed by a LF */
if (++ptr >= end)
ptr = b_orig(buf);
if (--stop == 0)
return 0;
if (*ptr != '\n')
goto error;

View File

@ -693,11 +693,6 @@ static size_t h1_parse_full_contig_chunks(struct h1m *h1m, struct htx **dsthtx,
++ridx;
break;
}
else if (end[ridx] == '\n') {
/* Parse LF only, nothing more to do */
++ridx;
break;
}
else if (likely(end[ridx] == ';')) {
/* chunk extension, ends at next CRLF */
if (!++ridx)
@ -710,7 +705,7 @@ static size_t h1_parse_full_contig_chunks(struct h1m *h1m, struct htx **dsthtx,
continue;
}
else {
/* all other characters are unexpected */
/* all other characters are unexpected, especially LF alone */
goto parsing_error;
}
}