4 ms·

I'm writing a POP3 service (http://billpg.com/POP3/ http://billpg.com/POP3/) and I stumbled upon this as a bit of a forehead-slapping moment. Once I read about

by billpg 4y ago

I'm writing a POP3 service (http://billpg.com/POP3/ http://billpg.com/POP3/) and I stumbled upon this as a bit of a forehead-slapping moment. Once I read about it, I tried attacking my own server by sending in "STLS\r\nCAPA\r\n" in a single TCP package and it responded to CAPA after the encrypted channel had been established because those bytes were still in the buffer. One hasty bugfix to clear the buffers after establishing TLS later and I thought about how to exploit this bug. The only thing you can do at this point is log in and an attacker isn't going to know the user's credentials. (If they do, you don't need to exploit the bug.) Despite this, I wonder about what what if HTTP had a STARTTLS command instead of using port 443 and handing over directly to TLS. SNI (identifying the names host the client wishes to connect to prior to certificate exchange) took years to get established, mostly (I think) because it was inside the black-box of TLS. If the certificate exchange happened with HTTP before handing over to TLS, the request might have looked like: GET /.well-known/tls-cert HTTP/1.1 Host: the-actual-hostname Accept: certificate/format, et/c When the hand-over to TLS (in this parallel universe) takes place, the certificate exchange has already happened. TLS's job is now to confirm the cert is valid (or not) and exchange session keys.

daneel_w 4y ago
I never could understand why POP3 service providers don't just insist on enforcing POP3S. We're no longer in the early 2000s. https://github.com/stolendata/little-peepo/blob/master/little_peepo.pl#L8 https://github.com/stolendata/little-peepo/blob/master/littl...
- lbriner 4y ago
  My understanding is that it is always historical. There are still people out there who are "I built my own email tools" or "this was setup in 1992 and still works" etc. These aren't a tiny fringe group but asizeable number of sometimes very influential people. As soon as you make a serious breaking change, it brings out all the complaints of "centralisation" of "being forced into something" into "I don't need tls whatever you say" etc. Google try these sorts of things occasionally but although in most cases it is short-term pain for long-term gain, it rarely goes that way.
  - daneel_w 4y ago
    The case of POP3 and STARTTLS vs POP3S is different, because practically all POP3 providers these days require encryption before the e-mail client is allowed to transact. It's the same encryption method/protocol and the same requirement, it's just that POP3S goes straight for the TLS handshake while STARTTLS (with the security concerns detailed in the article) begins talking on an unencrypted channel before getting on with the mandatory handshake.
knome 4y ago
>One hasty bugfix to clear the buffers after establishing TLS Discarding bytes seems like the wrong thing to do as well. If your starttls just takes the socket and no "initial bytes", as I would expect, you would need to either read off the socket a byte at a time til then or better to use MSG_PEEK to not read past the next \r\n.
- billpg 4y ago
  I thought about that but I didn't want to be stuffing bytes back into the incoming stream and I didn't want to be reading the stream byte-by-byte either unless I really had to. I had a nice bit of code that read blocks of bytes and looked for the CRLF separating lines - even handling the case where the CR is one block and the LF is in the next one - and I didn't want to dismantle that. I read the relevant RFC and there was a clear exception to the rules of PIPELINING that meant a conforming client doesn't send the "ClientHello" until the server has responded to the STLS command. I felt justified in clearing the buffer at that point.
deleted 4y ago
[deleted]
tsimionescu 4y ago
That needlessly ties the session layer (TLS) with the application layer (HTTP). The much better solution is the one taken by QUIC, moving encryption itself at the transport layer (well, or it would be if QUIC itself weren't piggybacking on UDP). It's an unfortunate accident of history that encryption was tied to some application protocols, and is not part of the standard TCP/IP stack provided at the OS level entirely. This same accident led to bad ideas like STARTTLS, unfortunately.
hannob 4y ago
How to exploit: For imap or smtp one can construct commands that will lead to a mail with the login credentials being sent to the attacker (assuming the attacker has an account on the same server). For POP3 we were unable to come up with such an attack, as it has no way of storing or sending mails.
- billpg 4y ago
  Yep. While I did fix the bug as soon as I found it, I consider myself fortunate I chose POP3 to write my first server.

by billpg 4y ago

daneel_w 4y ago

I never could understand why POP3 service providers don't just insist on enforcing POP3S. We're no longer in the early 2000s. https://github.com/stolendata/little-peepo/blob/master/little_peepo.pl#L8 https://github.com/stolendata/little-peepo/blob/master/littl...

lbriner 4y ago
My understanding is that it is always historical. There are still people out there who are "I built my own email tools" or "this was setup in 1992 and still works" etc. These aren't a tiny fringe group but asizeable number of sometimes very influential people. As soon as you make a serious breaking change, it brings out all the complaints of "centralisation" of "being forced into something" into "I don't need tls whatever you say" etc. Google try these sorts of things occasionally but although in most cases it is short-term pain for long-term gain, it rarely goes that way.
- daneel_w 4y ago
  The case of POP3 and STARTTLS vs POP3S is different, because practically all POP3 providers these days require encryption before the e-mail client is allowed to transact. It's the same encryption method/protocol and the same requirement, it's just that POP3S goes straight for the TLS handshake while STARTTLS (with the security concerns detailed in the article) begins talking on an unencrypted channel before getting on with the mandatory handshake.

knome 4y ago

>One hasty bugfix to clear the buffers after establishing TLS Discarding bytes seems like the wrong thing to do as well. If your starttls just takes the socket and no "initial bytes", as I would expect, you would need to either read off the socket a byte at a time til then or better to use MSG_PEEK to not read past the next \r\n.

billpg 4y ago
I thought about that but I didn't want to be stuffing bytes back into the incoming stream and I didn't want to be reading the stream byte-by-byte either unless I really had to. I had a nice bit of code that read blocks of bytes and looked for the CRLF separating lines - even handling the case where the CR is one block and the LF is in the next one - and I didn't want to dismantle that. I read the relevant RFC and there was a clear exception to the rules of PIPELINING that meant a conforming client doesn't send the "ClientHello" until the server has responded to the STLS command. I felt justified in clearing the buffer at that point.

deleted 4y ago

[deleted]

tsimionescu 4y ago

That needlessly ties the session layer (TLS) with the application layer (HTTP). The much better solution is the one taken by QUIC, moving encryption itself at the transport layer (well, or it would be if QUIC itself weren't piggybacking on UDP). It's an unfortunate accident of history that encryption was tied to some application protocols, and is not part of the standard TCP/IP stack provided at the OS level entirely. This same accident led to bad ideas like STARTTLS, unfortunately.

hannob 4y ago

How to exploit: For imap or smtp one can construct commands that will lead to a mail with the login credentials being sent to the attacker (assuming the attacker has an account on the same server). For POP3 we were unable to come up with such an attack, as it has no way of storing or sending mails.

billpg 4y ago
Yep. While I did fix the bug as soon as I found it, I consider myself fortunate I chose POP3 to write my first server.