4 ms·

Sorry if this is a silly question, but is this simply the Heartbleed bug? Or is this a different memory leak bug?

saranagati 13y ago
appears to be a different bug. nothing as big as heartbleed though from what I can tell.
yarbelk 13y ago
Not a silly question. Not all of us know which bug report is which sensationalised bug name. I know I don't. Admittedly, some bugs deserve to be sensationalised.
- Dylan16807 13y ago
  You didn't look at the fifteen second description of what Heartbleed is?
  - IgorPartola 13y ago
    To be fair the linked patch is very sparse and even so not everyone reads C, or knows what the Heartbleed code looked like. I can guess at what this is because some kind people provided a few good links about how bad memory management in OpenSSL is handled.
    - yohanatan 13y ago
      The patch also comes with an explanation of the bug which obviously does not align at all with either the short- or the long-winded explanations of Heartbleed.
    - yaur 13y ago
      backstory here http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse http://www.tedunangst.com/flak/post/analysis-of-openssl-free...
IgorPartola 13y ago
This is not the Heartbleed bug. I am not certain this is actually an immediately exploitable vulnerability (aka a sexy bug). What this looks like is an instance where the code calls free() on a buffer, then assumes the buffer is still available (uses it in some way). The patch seems to make it only free the buffer after it is empty, preventing this behavior. I think this is related to OpenSSL's issue with malloc and the way it handles memory allocation.
- Danieru 13y ago
  You're right about the custom malloc in so far as but bug would have been caught earlier without it.
- yaur 13y ago
  No this was written about a couple days ago. It frees the memory and because Open uses a LIFO memory allocater it can "safely" assume that whatever was still in there is still in there. I belive that in order to exploit this you would need to exhaust its internal allocator (so that it requests more from the OS) and your payoff would be... having your connection dropped. This was discovered in the course of someone's attempt to figure out why OpenSSL randomly drops connections when its using a sane/OS supplied allocator.
Dylan16807 13y ago
It's a bug that got in the way of memory hardening that could have stopped heartbleed, but it's not actually related. Heartbleed is reading too far, this is not that.
rtpg 13y ago
I think this is more of a bug that could enable something like Heartbleed. So squashing this might make other bugs less interesting to exploit.

appears to be a different bug. nothing as big as heartbleed though from what I can tell.

Not a silly question. Not all of us know which bug report is which sensationalised bug name. I know I don't. Admittedly, some bugs deserve to be sensationalised.

Dylan16807 13y ago
You didn't look at the fifteen second description of what Heartbleed is?
- IgorPartola 13y ago
  To be fair the linked patch is very sparse and even so not everyone reads C, or knows what the Heartbleed code looked like. I can guess at what this is because some kind people provided a few good links about how bad memory management in OpenSSL is handled.
  - yohanatan 13y ago
    The patch also comes with an explanation of the bug which obviously does not align at all with either the short- or the long-winded explanations of Heartbleed.
  - yaur 13y ago
    backstory here http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse http://www.tedunangst.com/flak/post/analysis-of-openssl-free...

IgorPartola 13y ago

This is not the Heartbleed bug. I am not certain this is actually an immediately exploitable vulnerability (aka a sexy bug). What this looks like is an instance where the code calls free() on a buffer, then assumes the buffer is still available (uses it in some way). The patch seems to make it only free the buffer after it is empty, preventing this behavior. I think this is related to OpenSSL's issue with malloc and the way it handles memory allocation.

Danieru 13y ago
You're right about the custom malloc in so far as but bug would have been caught earlier without it.
yaur 13y ago
No this was written about a couple days ago. It frees the memory and because Open uses a LIFO memory allocater it can "safely" assume that whatever was still in there is still in there. I belive that in order to exploit this you would need to exhaust its internal allocator (so that it requests more from the OS) and your payoff would be... having your connection dropped. This was discovered in the course of someone's attempt to figure out why OpenSSL randomly drops connections when its using a sane/OS supplied allocator.

Dylan16807 13y ago

It's a bug that got in the way of memory hardening that could have stopped heartbleed, but it's not actually related. Heartbleed is reading too far, this is not that.

rtpg 13y ago

I think this is more of a bug that could enable something like Heartbleed. So squashing this might make other bugs less interesting to exploit.