-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash with esp_http_client Digest without qop (IDFGH-11876) #12962
Comments
Further investigation shows that the nc must also be included in this issue.
Currently, the nc is included autmatically in the response in http_auth.c irrespective of whether it is required. The upshot of this is that if the qop is removed from the response when it is not required (i.e. null), the inclusion of the nc is in violation of the standard, and for me resulted in a 400 bad request response from the server. The following http_auth.c code fixes the problems:
Note that I have included the nc++ here, and it should be removed from the esp_http_client.c file. It is only necessary to increment nc when it is used, and if qop is not provided, nc is not required. |
Hello @trumpton Thanks! |
Hello @trumpton |
I can confirm that the application no longer crashes, and when capturing the output with Wireshark, I now see a correctly formatted header.
I am seeing a timeout from the other end, but I suspect that this is caused by something else - I could only get the patch to work on the master branch, and I previously did the test originally on v4.3 through platformio, and on v5.1 direct with esp-idf. I'll manually apply the patch to v4.3 and confirm that that works fine ... |
Answers checklist.
IDF version.
v5.1
Espressif SoC revision.
Chip is ESP32D0WDQ5 (revision 3)
Operating System used.
Linux
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32 WROVER KIT 1
Power Supply used.
USB
What is the expected behavior?
When accessing a website that has a Digest challenge with no 'qop' field in the Authorization header, the expected behaviour is to continue with the login, providing the responses to the challenge and ultimately load the web page.
The excerpt below is acquiring a remote status via Google Chrome (which works), not through the ESP32 device (which does not):
What is the actual behavior?
The application crashes with a Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled when the following http transaction is performed:
This is caused by the following line in http_auth.c:
Note: auth_data->qop is null, which is what actually causes the crash.
qop is specified in RFC7616 in a section which identifies a series of parameters which MAY be supplied:
qop - Indicates what "quality of protection" the client has applied to the message. Its value MUST be one of the alternatives the server indicated it supports in the WWW-Authenticate header field. These values affect the computation of the response. Note that this is a single token, not a quoted list of alternatives as in WWW-Authenticate.
This effectively says that if the parameter is supplied, it must be in a specific format - it does not mandate that the parameter is there.
Steps to reproduce.
Connect to a Digest authenticated web server that does not provide 'qop' fields in the Authorization header, and attempt to retrieve the web page - I used a Prusa MK4 printer status query.
Debug Logs.
No response
More Information.
Irrespective of whether the input request is correctly formatted or not, the library should not crash - i.e. all %s submissions to printf should not pass null strings.
If a request is incorrectly formatted, the library should handle in a sensible way, either by reporting that processing has been rejected, or make an assumption with regards to the missing parameter.
The text was updated successfully, but these errors were encountered: