Fast-CGI standard not being implemented correctly for FCGI_GET_VALUES

Question

Fast-CGI standard not being implemented correctly for FCGI_GET_VALUES

finnianr opened this issue 5 years ago · 2 comments

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.

Answer 1 · 2019-12-19T13:47:07.000Z

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.

Answer 2 · 2019-12-19T18:09:16.000Z

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.