Discuss the nature of the OpenSSL "Heartbleed" vulnerability, and the issues it relates to in terms of product design, development, inspection, testing, privacy and security, plus any concerns relating to organizational reliance on open source software products.

Interesting link (thanks Marius!) Coverity (sw testing company) finds open source code higher quality than proprietary code

SAMPLE SOLUTION The heartbleed vulnerability stems from one of the secure communication protocols implemented by OpenSSL. Specifically, the "heartbeat" extension to the transport layer protocol. This extension allows a client to keep a server connection open by periodically exchanging a heartbeat communication with the server. The client sends a message to the server, the server sends back a copy, and both sides know the other is still there and functioning. The vulnerability comes about in part because the client sends the message size along with the message. This size isn't used by the server when it stores the message (it stores just the message actually sent). However, when sending the reply, the server copies from its own memory the amount of memory specified in the size field sent by the client - without validating that the size requested matches the size sent and without validating whether the client should have access to the memory space in question. A malicious client can ask for more memory back than it actually sent, in which case the server sends back the 'extra' from whatever happened to lie in its own memory immediately after the client message. In this way the malicious client can obtain illicit snapshots of the (supposedly secure) server memory - though these snapshots are limited to 64kytes due to limitations on the message size field. Some thoughts on issues related to design, development, inspection, testing, privacy, security, and open source products: - Companies must be careful and selective in the use of any third party product (open source included): how much can you trust that they are safe, secure, and reliable? The fact that "everyone is using them" does not guarantee any of the above. - Both the design and testing of products (in this case the heartbeat extension) must try to account for malicious clients, but especially so when the product is something specifically targetted at private/secure information. Code reviews and inspections may have caught the vulnerability prior to its introduction. - The longer something has been in use, the more we tend to trust it as 'safe', thinking that if no risks have been found so far then probably none exist. Clearly that isn't an entirely reliable philosophy.