-1

Wrt to recent OpenSSL bug, is it possible for a user-space app to read other's process memory via mmap? This is in reference to the bug description found at http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

I guess, the concern in the above article to read memory via memcpy (as its copying memory based on what used supplied in the packet length) is valid, because if you happen to have a credit card information in that location, it can be sent back to the user who generated the packet.

jww
  • 97,681
  • 90
  • 411
  • 885
Jimm
  • 8,165
  • 16
  • 69
  • 118
  • This is very unlikely. The ->payload field in the ssl code is allocated dynamically, and will have been obtained by linux by an anom mmap of /dev/zereo. (in chunks of a few MB, IIRC) the chance that a different mapping is in the same 64 K window is very very small. Besides, the memory map will be arranged in such a way that the "heap" can be expanded linearly, so file mappings will be placed in a different area. – wildplasser Apr 09 '14 at 20:43

1 Answers1

1

It depends on exactly what you mean, but the short answer is "yes".

A trivial example would be two applications that both have the same shared library loaded. The shared code would be visible to read from both processes.

You can also opt to map memory with mmap in such a way that they can be shared amongst processes, by using the MAP_SHARED flag. This is one method of inter process communication.

As for being able to read memory that isn't mapped with the shared flag that shouldn't be possible for a user space application.

In light of the bug however you could have a go and open an https connection to localhost. Who knows what you might find.

Will
  • 4,585
  • 1
  • 26
  • 48
  • I believe the attacker would need to control a pointer for the read, and I don't think that has happened [yet] (correct me here). Plus, the memory for the heap and the memory for shared memory usually differ drastically. So its not enough to read off the end of the heap (which would likely result in a `SIGSEG`). Perhaps the POCs need to try a small SSL record combined with a large Heartbeat message in an effort to overwrite to a location. – jww Apr 09 '14 at 22:29
  • Overwrite will result in segmentation fault, not sure if reading random memory via mmap, that does not belong to process would cause seg fault also? – Jimm Apr 09 '14 at 23:16
  • To my knowledge, shared libraries only share the code space, but any memory allocation by shared libraries is done within an application's heap or stack. – Jimm Apr 09 '14 at 23:21
  • Nothing is written. The request is just allowed to address memory that is beyond what is intended to be read, upto 64K size. And that memory *could* happen to contain the (private) key data. – wildplasser Apr 09 '14 at 23:34