Fix: Remote Denial of Service (Infinite Loop) in TelnetAppender #583
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
I identified a critical robustness issue in
TelnetAppenderwhere logging a message shorter than 4 characters (e.g., "OK", "404") triggers an infinite loop, causing 100% CPU usage on the worker thread.Technical Analysis
The vulnerability is caused by a logic mismatch between the memory allocation strategy in
TelnetAppenderand the safety requirements of theUTF8CharsetEncoder.telnetappender.cpp):The buffer is allocated dynamically based strictly on message length:
For a 2-byte message ("Hi"), the allocated buffer is 4 bytes.
charsetencoder.cpp): TheUTF8CharsetEncoderenforces a safety check requiring at least 8 bytes of remaining space:If the buffer is smaller, it returns
APR_SUCCESSwithout consuming input or advancing the iterator.TelnetAppenderreceives a success code but detects the message hasn't been fully processed (msgIter != msg.end()). It retries the loop indefinitely with the same insufficient buffer, creating a deadlock.Remediation
This patch modifies
TelnetAppender::appendto enforce a minimum buffer allocation (1024 bytes). This ensures the buffer always satisfies the encoder's requirements, preventing the infinite loop regardless of the input message length.Threat Model Context
While this requires an untrusted log event, it results in a high-severity availability impact (Thread Hang).