|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Sec Bug #80008 stream_socket_enable_crypto() allows plaintext injection
Submitted: 2020-08-22 11:49 UTC Modified: 2021-09-21 08:20 UTC
From: hanno at hboeck dot de Assigned:
Status: Open Package: Sockets related
PHP Version: 7.4.9 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: hanno at hboeck dot de
New email:
PHP Version: OS:


 [2020-08-22 11:49 UTC] hanno at hboeck dot de
The function stream_socket_enable_crypto(), which is often used to implement STARTTLS functionality within PHP (e.g. in widely used mail libraries), is vulnerable to plaintext injection.

The problem is that when there is still data in the receive buffer and an application calls stream_socket_enable_crypto() further attempts to read from the connection will read the remaining plaintext data.

The code should either clear the buffer after transitioning to an encrypted connection or use the remaining data for the TLS handshake.

This bug class was originally found in Postfix in 2011 [1].

The impact depends on the protocol used. The bug can appear both on the server and the client side, but the server side is usually more severe.

I know this is a bit tricky to understand, if there's a need for further explanation I am happy to be available in a chat or call.

We discovered this in a larger research effort to investigate STARTTLS vulnerabilities, we will soon publish a scientific paper about these.



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2020-09-01 05:20 UTC]
-Status: Open +Status: Feedback
 [2020-09-01 05:20 UTC]
Not sure what the threat model here is. Could you describe a full sequence of actions that would lead to a security problem? I am feeling like missing some context here.
 [2020-09-05 07:07 UTC] hanno at hboeck dot de
-Status: Feedback +Status: Open
 [2020-09-05 07:07 UTC] hanno at hboeck dot de
The easiest scenario to understand is a vulnerable SMTP server. Now I'm aware that it is unlikely that people will implement SMTP servers in PHP, but I think it gets the idea across:

* Let's assume we have an authenticated (submission) SMTP server vulnerable to STARTTLS injection, a user and an attacker both have accounts on that server.
* The user tries to log into that server via STARTTLS.
* The attacker injects an additional EHLO command, an authentication with his own credentials and the start of an email to himself into the STARTTLS command.
* The server will interpret those and prepare sending an email.
* All further commands sent by the client/victim will be part of that email, including the authentication credentials.

A likely more relevant scenario for PHP may be spoofing of the content of an IMAP mailbox. Assume:
* A client with a STARTTLS injection vulnerability connects to an IMAP server with STARTTLS.
* The attacker injects commands into the (still unencrypted/unauthenticated) server answer to the STARTTLS command that already answers the upcoming commands the client will send to list the mailbox content. (This requries the attacker to know the exact chain of commands the client will send after STARTTLS, but with knowledge of the client software this is usually known information.)

The key issue in all of this is that content that is sent unencrypted and unauthenticated will be interpreted by one connection partner as if it was part of the encrypted/authenticated connection.

We have a scientific paper prepared on these attacks, I can share this with the PHP security team if you agree on keeping this confidential until we publish the paper.
 [2020-09-05 08:06 UTC]
Not sure I understand your scenario - are you assuming the attacker and the victim share the same TCP connection? 

Would be glad to see the paper (of course, won't disclose it, would be better to send the link to my email rather than post it here) but would like to also get an idea how the attack could be achieved practically.
 [2021-08-12 07:08 UTC] hanno at hboeck dot de
Our research is now public:

Maybe we can unrestrict this bug?
 [2021-09-20 05:59 UTC]
I am still not sure what threat model is assumed here. In my understanding, if the attacker and the victim share TCP connection and the attacker is able to inject arbitrary content into it, then all the data the victim is sending would be compromised in this scenario. However, I am not sure how it is possible that they would share the same connection?

That said, if somebody proposes the fix for this - that makes it clearer - I am ready to look at it.
 [2021-09-21 08:20 UTC] hanno at hboeck dot de
The threat model is a classic man in the middle attacker, i.e. a person that can modify a TCP connection on the network.

The key issue is: With mechanisms like STARTTLS we have a transition between a plaintext protocol (where we expect that manipulation is possible) to a TLS-protected connection (where we don't expect manipulation to be possible).
The gist of this bug is that an attacker can modify the plaintext part of that protocol, but it will modify what the application thinks is the TLS-protected part.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Fri Sep 30 19:05:53 2022 UTC