• Post Reply Bookmark Topic Watch Topic
  • New Topic

Heart Bleed Bug in openSSL

 
Rajesh Martin
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

How to rectify the heart bleed bug in the openSSL
 
Jaikiran Pai
Sheriff
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rajesh, welcome to CodeRanch!

There's already a discussion going on about it here http://www.coderanch.com/t/631935/Security/Heartbleed-Bug-vulnerability-popular-OpenSSL. Apparently, you have to upgrade the library version to fix it.
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Upgrading the library is the first step. For a public web server, changing the private keys and SSL certificates would be next, but not necessarily last. Other software that incorporates OpenSSL (SSH clients, VPN clients etc.) may also need updating.
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I thought I understood the bug, but the I realized I still had a question about it. So the client sends a length for the heartbeat, then sends data. The bug is what happens when the data is shorter than the length. But why doesn't the server wait until the full length worth of bytes comes through? Why does it echo the heartbeat when, from its point of view, it doesn't have the full heartbeat yet?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65524
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Today's xkcd explains it well:


 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's a good basic explanation, but it doesn't answer my question.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65524
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's not a matter of the server waiting for anything, but of sending as much data as is asked for regardless of whether it should or not, thus sending the data that it has in memory.

In the last panel, the server should be saying "500! Are you insane? No way!"
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But how does the server know that the client has finished sending the data? If it has been sent a length of 500, why isn't it waiting until 500 bytes come in?

Is the length sent by the client redundantly? If so, it sounds like the real bug is in the TLS spec.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65524
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The 500 bytes aren't going in, but going out.
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The bytes going out are supposed to be a copy of the bytes going in. That obviously means that the server must receive the bytes before it can send them back.

In the XKCD example, how does the server decide to send something back after it has received the 3 bytes of "HAT"? Why did it wait until it received 3 bytes - why didn't it stop at 2, or 1, and allocate and send back the buffer starting with just "H" or "HA"? The server must know somehow that the actual data length is only 3, as opposed to 500, to know to reply after 3 bytes, even if it mistakenly uses the 500 for the amount of memory to put in the reply.

But hey, I decided to look it up myself in RFC 6520. It turns out that the client does provide the length redundantly, just as I suspected. There is a length defined for the overall message, and then within the message, there is a length defined for the payload of the message, with the remainder presumed to be padding. It's this defining of two dependent lengths that allows the client to send inconsistent lengths to cause the bug.

RFC 6520 even explicitly warns against this bug:

"If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently."

 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65524
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good research!

Have a cow.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!