Skip to content

pingpong: reject nul byte in server response line#21996

Closed
alhudz wants to merge 1 commit into
curl:masterfrom
alhudz:pingpong-response-nul
Closed

pingpong: reject nul byte in server response line#21996
alhudz wants to merge 1 commit into
curl:masterfrom
alhudz:pingpong-response-nul

Conversation

@alhudz

@alhudz alhudz commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Repro: point curl at an FTP/IMAP/SMTP/POP3 server that sends a response line with an embedded nul before the LF, e.g. a POP3 greeting +OK ready\u0000injected\r\n. Before this patch curl returns 0 and the line (nul and all) is handed to CURLOPT_HEADERFUNCTION; after it the transfer fails with CURLE_WEIRD_SERVER_REPLY.

Cause: Curl_pp_readresp() finds the line end with memchr on the LF only and passes each line to Curl_client_write(CLIENTWRITE_INFO), which is delivered to the header callback (the response lines are treated as a kind of header). The pingpong path has no nul check, so a malicious or MITM server can smuggle an embedded nul into the header callback. Regular HTTP headers are guarded against this by verify_header(); these control responses are not.

Fix: reject a nul byte in the response line before delivery. verify_header() itself is not reused here as it also enforces a trailing-CR/colon shape that pingpong lines do not have.

@testclutch

Copy link
Copy Markdown

Analysis of PR #21996 at 5350de8e:

Test 1282 failed, which has NOT been flaky recently, so there could be a real issue in this PR. Note that this test has failed in 419 different CI jobs (the link just goes to one of them).

Generated by Testclutch

@bagder

bagder commented Jun 13, 2026

Copy link
Copy Markdown
Member

How about adding a test case that verifies this as well?

@alhudz alhudz force-pushed the pingpong-response-nul branch from 5350de8 to 5ab99be Compare June 13, 2026 10:47
@github-actions github-actions Bot added the tests label Jun 13, 2026
@alhudz

alhudz commented Jun 13, 2026

Copy link
Copy Markdown
Contributor Author

Added test2108 for the FTP path. That also accounts for the test1282 failure the bot flagged: 1282 still carried the \x00 bytes from the old Kerberos 633-before-gss check, and the new rejection fires before the 633 login-denied path is reached. Dropped those vestigial nuls so 1282 keeps verifying the 633 behaviour, and 2108 covers the nul rejection on its own. Both pass here.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR hardens the pingpong (FTP/IMAP/POP3/SMTP-style) response parsing path by rejecting server response lines that contain embedded NUL bytes before those lines are forwarded to the client “header” callback.

Changes:

  • Add a NUL-byte check in Curl_pp_readresp() and fail the transfer with CURLE_WEIRD_SERVER_REPLY if found.
  • Add a new FTP regression test covering NUL injection in a control response line.
  • Update an existing FTP test case to avoid embedded NUL bytes now considered invalid.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
lib/pingpong.c Rejects embedded NUL bytes in pingpong response lines before callback delivery.
tests/data/test2108 New FTP test ensuring NUL bytes in server response lines are rejected.
tests/data/test1282 Removes embedded NUL bytes from an existing FTP server reply to match new validation.
tests/data/Makefile.am Registers the new test case.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread tests/data/test2108 Outdated
Add test 2108 covering the rejection over FTP. Drop the now-vestigial
nul bytes from test 1282; they exercised the removed Kerberos FTP
security buffer check and now trip this rejection before the 633
login-denied path is reached.
@alhudz alhudz force-pushed the pingpong-response-nul branch from 5ab99be to 1d4313d Compare June 17, 2026 08:55
@bagder bagder closed this in 2f8fb98 Jun 18, 2026
@bagder

bagder commented Jun 18, 2026

Copy link
Copy Markdown
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Development

Successfully merging this pull request may close these issues.

4 participants