Fast-CGI standard not being implemented correctly for FCGI_GET_VALUES

[finnianr]

I am using Cherokee Web Server version 1.2.101 and noticed recently that my Fast-CGI application broker is receiving requests with the record type set to FCGI_GET_VALUES_RESULT. According to section 4.1. FCGI_GET_VALUES, FCGI_GET_VALUES_RESULT of the Fast-CGI standard, this should not be happening.

4.1. FCGI_GET_VALUES, FCGI_GET_VALUES_RESULT
The application receives a query as a record {FCGI_GET_VALUES, 0, ...}. The contentData portion of a FCGI_GET_VALUES record contains a sequence of name-value pairs with empty values.

The application responds by sending a record {FCGI_GET_VALUES_RESULT, 0, ...} with the values supplied. If the application doesn’t understand a variable name that was included in the query, it omits that name from the response.

[skinkie]

Could you maybe give some instructions how to reproduce it so we can make it easy for ourselves to improve the product? One thing we currently don't do is keeping a presistent connection with an FastCGI backend. This is also something that might have to be implemented.

[finnianr]

Hi Stefan,
sorry I don't have much information about it or a way to reproduce it. But here is how I noticed the problem:

I have a production servlet named "hacker_intercept", whose function is to handle any requests leftover from legitimate URL requests, and block IPs of hackers. It started crashing occasionally. After analysing the stack trace, I figured it was because my Fast-CGI implementation was incomplete. So I changed the code to drop the connection for any unsupported record types and log what the type was.

By monitoring the servlet log I found the trouble originated from a management request FCGI_GET_VALUES_RESULT. By looking at the next recorded hack attempt and comparing with the cherokee.access log, it seems that the request that caused the application value request was most likely the following:

37.191.82.186 - - [17/Dec/2019:02:20:16 +0000] "POST /editBlackAndWhiteList HTTP/1.1" 500 0 "-" "curl/7.29.0"

500 is "internal server error" so that is most likely it. There is some discussion about this attack on stack overflow and else where. It might give a clue on how to reproduce the behavior.