You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Great library. Saved me a lot of time on a recent project 😄!
Description
During implementation, I discovered a bug causing excessive resource consumption. A client can send an ICAP request with an arbitrary offset set in either the req-hdr or res-hdr Encapsulated header values. This arbitrary offset causes the application to allocate n bytes of memory, where n is the value specified in the req-hdr and/or res-hdr.
Evidence
The bug occurs in the ReadRequest function, which is responsible for parsing the ICAP request.
When the function encounters the Encapsulated header, it reads the various values supplied in the header. The first part of the issue arises during the initial iteration of the loop. Since prevKey is empty, initialOffset is set to the value extracted from the first entry in the Encapsulated header:
returnnil, fmt.Errorf("%s must be the last section", prevKey)
}
switchkey {
case"req-hdr", "res-hdr", "null-body":
case"req-body", "res-body", "opt-body":
hasBody=true
default:
returnnil, &badStringError{"invalid key for Encapsulated: header", key}
}
The second part of the issue occurs when the library attempts to position the cursor at the start of the Encapsulated HTTP header by reading initialOffset bytes. During this process, a byte slice named junk is initialized to read up to the beginning of the Encapsulated HTTP header. Since initialOffset is arbitrary, the make call can allocate an arbitrary amount of memory. Both reqHdrLen and respHdrLen are also arbitrary and are affected by the same logic. This can lead to excessive resource consumption and result in a Denial-of-Service.
Hallo 🍰,
Great library. Saved me a lot of time on a recent project 😄!
Description
During implementation, I discovered a bug causing excessive resource consumption. A client can send an ICAP request with an arbitrary offset set in either the
req-hdr
orres-hdr
Encapsulated header values. This arbitrary offset causes the application to allocate n bytes of memory, where n is the value specified in thereq-hdr
and/orres-hdr
.Evidence
The bug occurs in the
ReadRequest
function, which is responsible for parsing the ICAP request.When the function encounters the Encapsulated header, it reads the various values supplied in the header. The first part of the issue arises during the initial iteration of the loop. Since
prevKey
is empty,initialOffset
is set to the value extracted from the first entry in the Encapsulated header:icap/request.go
Lines 85 to 114 in ca4fad4
The second part of the issue occurs when the library attempts to position the cursor at the start of the Encapsulated HTTP header by reading
initialOffset
bytes. During this process, a byte slice namedjunk
is initialized to read up to the beginning of the Encapsulated HTTP header. SinceinitialOffset
is arbitrary, themake
call can allocate an arbitrary amount of memory. BothreqHdrLen
andrespHdrLen
are also arbitrary and are affected by the same logic. This can lead to excessive resource consumption and result in a Denial-of-Service.icap/request.go
Lines 121 to 142 in ca4fad4
Below is a small PoC. I've also attached the payload along with this Issue
icap-crash-0.txt
Run and build:
Cheers mate 🍻,
~ k00l-beanz
The text was updated successfully, but these errors were encountered: