source : http://www.theregister.co.uk/2014/04/09/heartbleed_explained/
About a year ago, it was discovered the bug Heartbleed, vulnerabilities affecting OpenSSL library.
But informing me on the Web I found some documents that explain technically what is this bug.
Many people have explained the flaw so much superficial then I will try to analyse the whole issue Heartbleed from a technical point of view.
OpenSSL library that is used to encrypt communications over the internet, is the heart of encrypted protocols such as SSL/TLS (for HTTPS), ssh, sftp, which ensure the security of communication and privacy on the Internet for web applications, email, instant messaging (IM) and some virtual private networks (VPNs).
The flaw (CVE-2014-0160) has existed since December 2011, and was fixed with OpenSSL 1.0.1 version g. Vulnerable versions of OpenSSL 1.0.1 from 1.0.1 to f, while not affected OpenSSL versions prior to and subsequent to the 1.0.0 1.0.1 g.
The vulnerability was introduced following the implementation of the Heartbeat extension for some protocols used by OpenSSL. Heartbeat avoids having to renegotiate every time the secure connection between client and server, keeping alive the links with requests made at regular intervals; in particular, the client sends a string to the server and the latter the forwards as a response to the client.
The bug allows an attacker to read up to 64 KB of memory from your system vulnerable, with the possibility of compromising the secret keys that are used to identify service providers and to encrypt the traffic, the names and passwords of users. This allows attackers to spy on communications, to impersonate or steal data directly from users and services.
An attack that exploits this flaw leaves no trace and can be accomplished without the use of credentials or special privileges.
But how could this happen? Read the code and let's find out:
The core of vulnerability in ssl/d1_both. c: http://git.openssl.org/gitweb/?p=op...db9023b881d7cd9f379b0c154650d6c108e9a3#patch2
First you get a pointer to the data in a record SSLv3 assigned to p.
Returning to dtls1_process_heartbeat, acquired the structure of the record assigned to p, by type, length and data memory address.
The first byte of the record SSLv3 is the Heartbeat.
The n2s reads two bytes to p, writes in the payload, and increments the pointer p, basically stores the length. Note that the actual size in SSLv3 record is not checked.
Finally the pointer pl contains the memory address where the Heartbeat data are provided by the applicant.
In this step, you allocate the amount of memory required by the function up to 65535 OPENSSL_malloc +1 +2 +16 bytes, to be precise.
Bp is variable the pointer used to access this memory.
The macro works in reverse order of s2n n2s, copy the two byte payload content buffering bp.
Finally on the buffer is copied to a data volume, present at memory address pl, equal to the length required by the payload.
Then the function will send the buffer to the user and to "liberate" the memory, concluding the heartbeat.
So where is the bug?
Inside the function parsed does not a congruence on control data that is requested by the user. The client when it sends a string to the server to complete a heartbeat, can declare a higher length, in this way the server responds with the data in memory that should not normally be accessible to users.
An example is worth a thousand words, so suppose the user request to the server the string "Hello", stating that this is 4 letters long. the server writes within the payload variable the value 4, pl will point to the first letter of the word "Hello" and bp response buffer will copy only 4 letters from that bet by pl, and say "Hi". Now suppose the user request to the server the string "hack" and declaring that it is 20 long letters; the server will store inside the payload variable the value 20, believing mistakenly that the word that must send as answer 20 characters long. Bp will then be written "hacks" followed by 16 characters that exist in memory.
This happens because the reading from the law all the memcpy contiguous memory to SSLv3 record within the same process.
I'd like to now reflect a moment on this vulnerability, not so much from a technical point of view but from a practical point of view.
It is necessary that giants such as Google, Facebook, etc, which use these critical infrastructure, invest in safety controls to prevent problems in the future as a Heartbeat.
Enjoy with malware analysis
Last edited by a moderator:
