Looking more at the Heatbleed

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Looking more at the Heatbleed

mclellan, dave

We are looking more deeply into Heartbleed to determine the risk to our proprietary, non-open application.

1.       Background summary: Our proprietary client/server protocol is protected by TLS with OpenSSL 1.0.1c and 1.0.1e.   We do not respond to http or any other standard protocols.  The session initiation and RPC-like communication between client and server is encapsulated inside an API library which an application can’t influence directly.  Neither the physical socket nor the SSL object that represents the channel is directly accessible to the caller of the API library.

2.       Question: Heartbeat negotiation: Is there anything automatic in TLS session negotiation that causes the heartbeat protocol to be used by peers without application awareness? Our application does nothing explicit to  negotiate the Heartbeat Extension; we do nothing to prevent it.   

3.       Question: Heartbeat use: once negotiated, is there anything automatic in the protocol that causes one side to request a heartbeat from the peer?   Our peers communicate at the application level in a strict synchronous request – response method; a client thread sends a request and waits for a response; no secondary threads are involved.

 

Since we enclose the application client and server applications and we do no heartbeat work ourselves, what is the risk?  We recognize that reverse engineering our protocol is possible, but we believe that the difficulty of the exploit in the context of our server application is very high.  We also recognize that we could be surprised by very clever attackers, so we want to do the right thing.

 

+-+-+-+-+-+-+-+-+-

Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St.

Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749

Office:    508-249-1257, Mobile:   978-500-2546, [hidden email]

+-+-+-+-+-+-+-+-+-

 

Reply | Threaded
Open this post in threaded view
|

Re: Looking more at the Heatbleed

Viktor Dukhovni
On Thu, Apr 10, 2014 at 05:02:17PM -0400, mclellan, dave wrote:

> We are looking more deeply into Heartbleed to determine the risk
> to our proprietary, non-open application.

Based on the below, it is vulnerable, and needs to be linked against
a patched OpenSSL library, or one built with -DOPENSS_NO_HEARTBEATS
(IIRC).

> 1.       Background summary: Our proprietary client/server protocol
> is protected by TLS with OpenSSL 1.0.1c and 1.0.1e.   We do not
> respond to http or any other standard protocols.  The session
> initiation and RPC-like communication between client and server is
> encapsulated inside an API library which an application can't
> influence directly.  Neither the physical socket nor the SSL object
> that represents the channel is directly accessible to the caller
> of the API library.

The attacker will not use your RPC library, she will connect with
a custom SSL client that is designed to slurp-up sensitive data
from memory.  Since your RPC is encapsulated in SSL/TLS, the attack
will work even if the attacker has no knowledge of your RPC protocol.

> 2.       Question: Heartbeat negotiation: Is there anything
> automatic in TLS session negotiation that causes the heartbeat
> protocol to be used by peers without application awareness? Our
> application does nothing explicit to  negotiate the Heartbeat
> Extension; we do nothing to prevent it.

There is nothing you can do to prevent in 1.0.1 -- 1.0.1f, other
than recompile with hearbeat support disabled.  Even if hearbeats
are not used by legitimate clients, they are available to malicious
clients.

> 3.       Question: Heartbeat use: once negotiated, is there
> anything automatic in the protocol that causes one side to request
> a heartbeat from the peer?   Our peers communicate at the application
> level in a strict synchronous request - response method; a client
> thread sends a request and waits for a response; no secondary
> threads are involved.

This is irrelevant, but heartbeats are not automatic, and legitimate
hearbeats are not the risk you need to mitigate.  Malformed hearbeat
requests from malicious clients are what you need to defend against.


> Since we enclose the application client and server applications
> and we do no heartbeat work ourselves, what is the risk?

You're just as vulnerable as other applications.

> We
> recognize that reverse engineering our protocol is possible, but
> we believe that the difficulty of the exploit in the context of
> our server application is very high.  We also recognize that we
> could be surprised by very clever attackers, so we want to do the
> right thing.

The same attack as for other protocols encapsulated in SSL works
equally well with your protocol, no need for any ingenuity.  For
example the same attack works equally for HTTP, SMTP and XMPP
servers.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Looking more at the Heatbleed

ag@gmail
In reply to this post by mclellan, dave
1. OpenSSL allows heartbeats during handshake.
2. Handshake request can come from any peer and is responded to (client or server is immaterial). You don't prevent it, so a peer can send heartbeat request and your openssl endpoint shall respond.

From what you describe, your application is vulnerable.

-Amarendra

--
sent via 100% recycled electrons from my mobile command center.

On Apr 10, 2014, at 2:02 PM, "mclellan, dave" <[hidden email]> wrote:

We are looking more deeply into Heartbleed to determine the risk to our proprietary, non-open application.

1.       Background summary: Our proprietary client/server protocol is protected by TLS with OpenSSL 1.0.1c and 1.0.1e.   We do not respond to http or any other standard protocols.  The session initiation and RPC-like communication between client and server is encapsulated inside an API library which an application can’t influence directly.  Neither the physical socket nor the SSL object that represents the channel is directly accessible to the caller of the API library.

2.       Question: Heartbeat negotiation: Is there anything automatic in TLS session negotiation that causes the heartbeat protocol to be used by peers without application awareness? Our application does nothing explicit to  negotiate the Heartbeat Extension; we do nothing to prevent it.   

3.       Question: Heartbeat use: once negotiated, is there anything automatic in the protocol that causes one side to request a heartbeat from the peer?   Our peers communicate at the application level in a strict synchronous request – response method; a client thread sends a request and waits for a response; no secondary threads are involved.

 

Since we enclose the application client and server applications and we do no heartbeat work ourselves, what is the risk?  We recognize that reverse engineering our protocol is possible, but we believe that the difficulty of the exploit in the context of our server application is very high.  We also recognize that we could be surprised by very clever attackers, so we want to do the right thing.

 

+-+-+-+-+-+-+-+-+-

Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St.

Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749

Office:    508-249-1257, Mobile:   978-500-2546, [hidden email]

+-+-+-+-+-+-+-+-+-

 

Reply | Threaded
Open this post in threaded view
|

Re: Looking more at the Heatbleed

Wim Lewis-3
In reply to this post by mclellan, dave

On 10 Apr 2014, at 2:02 PM, mclellan, dave wrote:
> We are looking more deeply into Heartbleed to determine the risk to our proprietary, non-open application.
> 1.       Background summary: Our proprietary client/server protocol is protected by TLS with OpenSSL 1.0.1c and 1.0.1e.   We do not respond to http or any other standard protocols.  The session initiation and RPC-like communication between client and server is encapsulated inside an API library which an application can’t influence directly.  Neither the physical socket nor the SSL object that represents the channel is directly accessible to the caller of the API library.

If a malicious client can connect and go through the TLS handshake, even if they never speak the "inner" protocol, then they are able to issue heartbeat requests and extract memory contents. (Or if your client can be made to connect to a malicious server: the server can issue heartbeat requests to the client.)

If it's impossible to make any TCP connections except through your API, then you're safer, because (a) no heartbeats will be sent, because nobody uses this feature with non-datagram TLS and (b) even if they were, a non-malformed heartbeat does not leak info.

But if you're using TLS at all, then presumably this is because the TCPIP network over which TLS is running is potentially insecure in some way (e.g., it's the open internet); an attacker with the ability to send packets on that layer could start making TLS connections and extracting data even with no knowledge of your proprietary protocol. If you are in a situation where you are only concerned about purely passive eavesdroppers on that connection, though, then I believe you are safe.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Looking more at the Heatbleed

Viktor Dukhovni
On Thu, Apr 10, 2014 at 06:16:33PM -0700, Wim Lewis wrote:

> But if you're using TLS at all, then presumably this is because
> the TCPIP network over which TLS is running is potentially insecure
> in some way (e.g., it's the open internet); an attacker with the
> ability to send packets on that layer could start making TLS
> connections and extracting data even with no knowledge of your
> proprietary protocol. If you are in a situation where you are only
> concerned about purely passive eavesdroppers on that connection,
> though, then I believe you are safe.

Lack of concern for MiTM attacks is quite different from lack of
concern about possible connections to the server from malicious
clients that are not in the middle of protected connections.

Even using SSL only against passive attacks on legitimate connections,
one has to take care of security issues that can be exploited by
hostile clients.  It is very unlikely that the OP can this one out.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Looking more at the Heatbleed

Roberto Spadim
hi guys, what about openssh, does it have some problem with this vulnerability?


2014-04-10 22:35 GMT-03:00 Viktor Dukhovni <[hidden email]>:
On Thu, Apr 10, 2014 at 06:16:33PM -0700, Wim Lewis wrote:

> But if you're using TLS at all, then presumably this is because
> the TCPIP network over which TLS is running is potentially insecure
> in some way (e.g., it's the open internet); an attacker with the
> ability to send packets on that layer could start making TLS
> connections and extracting data even with no knowledge of your
> proprietary protocol. If you are in a situation where you are only
> concerned about purely passive eavesdroppers on that connection,
> though, then I believe you are safe.

Lack of concern for MiTM attacks is quite different from lack of
concern about possible connections to the server from malicious
clients that are not in the middle of protected connections.

Even using SSL only against passive attacks on legitimate connections,
one has to take care of security issues that can be exploited by
hostile clients.  It is very unlikely that the OP can this one out.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]



--
Roberto Spadim
SPAEmpresarial
Eng. Automação e Controle
Reply | Threaded
Open this post in threaded view
|

Re: Looking more at the Heatbleed

ag@gmail
No. OpenSSH is not affected. See http://undeadly.org/cgi?action=article&sid=20140408063423

-ag

--
sent via 100% recycled electrons from my mobile command center.

On Apr 10, 2014, at 6:39 PM, Roberto Spadim <[hidden email]> wrote:

hi guys, what about openssh, does it have some problem with this vulnerability?


2014-04-10 22:35 GMT-03:00 Viktor Dukhovni <[hidden email]>:
On Thu, Apr 10, 2014 at 06:16:33PM -0700, Wim Lewis wrote:

> But if you're using TLS at all, then presumably this is because
> the TCPIP network over which TLS is running is potentially insecure
> in some way (e.g., it's the open internet); an attacker with the
> ability to send packets on that layer could start making TLS
> connections and extracting data even with no knowledge of your
> proprietary protocol. If you are in a situation where you are only
> concerned about purely passive eavesdroppers on that connection,
> though, then I believe you are safe.

Lack of concern for MiTM attacks is quite different from lack of
concern about possible connections to the server from malicious
clients that are not in the middle of protected connections.

Even using SSL only against passive attacks on legitimate connections,
one has to take care of security issues that can be exploited by
hostile clients.  It is very unlikely that the OP can this one out.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]



--
Roberto Spadim
SPAEmpresarial
Eng. Automação e Controle