Hi. On Mon, Apr 14, 2014 at 04:31:18AM -0400, shawn wilson wrote: > It might be possible for an openvpn server to initiate a heartbeat sequence > with a client. And therefore for a rogue server to exploit this. I don't > believe > this to be the case however and I can't think of any other way of exploiting > this. > > If you can get openvpn to use named sockets, you should be able to easily > test this with existing scripts.
Those guys did so called 'Reverse Heartbleed attack', i.e. an attack targeting clients, not the servers: http://blog.meldium.com/home/2014/4/10/testing-for-reverse-heartbleed In particular, this part is very interesting: Is this harder to exploit than Heartbleed? At a high-level, the exploit code is very similar to the client-initiated attack, but there are a couple of factors that make "reverse Heartbleed" a little harder to pull off: If a client is using certificate pinning, then the window for exploitation is much smaller, because as soon as the client realizes the server certificate doesn't match, they'll cut off the TLS connection. Some clients that support TLS heartbeats will not advertise that support when negotiating a handshake. In our exploit code, we removed the OpenSSL checks that determined whether or not heartbeat requests were allowed based on the negotiated and just sent them anyway. Server-initiated heartbeat requests can only be sent once the TLS connection has been established, so they need to be properly encrypted and MACed. We ended up building our exploit on top of a modified version of OpenSSL instead of writing one from scratch to keep the code simpler. Most clients are trying to complete an HTTP request and then close the channel, so our server uses a few tricks to keep the connection open as long as possible and maximize the number of heartbeat requests we can make. We slowly bleed out the HTTP response headers, we stream the HTTP response body, and we send malformed heartbeat requests interleved throughout. We've found that vulnerable clients can actually be made to send hundreds of 16kb chunks of memory back, making it much easier to explore the client's memory space. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140414113542.GA7681@x101h
