Fix critical buffer overflow vulnerability in HTTP request parsing #757
Conversation
This fixes a critical off-by-one buffer overflow in the HTTP request handler that could lead to authentication bypass, information disclosure, or crashes. The vulnerability occurred in two places: 1. Line 4643: The buffer filling loop allowed writing up to index 251 (252 bytes) without leaving room for null terminator 2. Line 4704: Null terminator was added without bounds checking, writing at index 252 which is out of bounds Attack scenario: - Sending exactly 252 bytes would overflow into bPlaceInBuffer variable - This would reset the buffer index to 0 and create an unterminated string - Subsequent string operations (strcpy, strncmp) would read beyond buffer - Could bypass PASSKEY authentication or leak adjacent memory Fix: - Limit buffer filling to MaxArrayElement-1 to reserve space for null - Add bounds checking before writing null terminator - Ensure string is always properly null-terminated This prevents any writes beyond the buffer bounds and eliminates the authentication bypass vector. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
|
I would say that either of the two change locations suggested by Claude is sufficient, but having both changed won't hurt. I'd use the opportunity to clean up the code a bit:
...or just use this PR as is ... and leave |
|
P.s. Actually, I would just change this here:
|
…rsing" This reverts commit d103258.
Add +1 to cLineBuffer array size to prevent out-of-bounds write. The loop can write up to MaxArrayElement (252) characters at indices 0-251, then writes null terminator at index 252. Original size of MaxArrayElement caused buffer overflow when writing the terminator. This minimal fix (suggested by code review) uses MaxArrayElement+1 instead of hardcoding the size, maintaining consistency with the MaxArrayElement constant. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
The post-increment operator on bPlaceInBuffer after null termination serves no purpose since the variable is reset to 0 at the start of each request loop (line 4618). This change improves code clarity with no functional impact. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
|
Thanks for the thorough review, @DE-cr! I've updated the PR to use the minimal fix you suggested. Changes made:
The array now has 253 bytes (indices 0-252), so the null terminator at index 252 is always valid. Ready for another look when you have a chance! |
Disclaimer: When checking for security vulnerabilities, Claude Code found one for me. This PR fixes it. I let it walk me through the implications and the fix of this pull request. I am an absolute newbie in ESP32 programming and haven't written C in ages. Despite that, I considered opening this PR to be worthwhile, given that the problem description and fix that Claude Code explained to me sounded plausible. Following is the description of the actual problem and change.
This fixes a critical off-by-one buffer overflow in the HTTP request
handler that could lead to authentication bypass, information disclosure,
or crashes.
The vulnerability occurred in two places:
(252 bytes) without leaving room for null terminator
at index 252 which is out of bounds
Attack scenario:
Fix:
This prevents any writes beyond the buffer bounds and eliminates the
authentication bypass vector.
🤖 Generated with Claude Code
Co-Authored-By: Claude [email protected]