14

OpenBSD provides a list of substantial protections against exploits inherent to the OS. Most of these features are not found in other operating systems, or at least are not turned on by default. The list from the OpenBSD website linked above includes:

  • strlcpy() and strlcat()
  • Memory protection purify
    • W^X
    • .rodata segment
    • Guard pages
    • Randomized malloc()
    • Randomized mmap()
    • atexit() and stdio protection
  • Privilege separation
  • Privilege revocation
  • Chroot jailing
  • New uids
  • ProPolice
  • ... and others

Do any of the security protections in OpenBSD mitigate the data-exposure from the Heartbleed attack?

In other words, would an Apache/nginx https server using OpenSSL have been any less vulnerable to the Heartbleed attack because it was being run on OpenBSD?

Brian M. Hunt
  • 537
  • 1
  • 3
  • 16
  • 7
    thank god. I though the heartbleed questions had stopped. Good to know it's still going strong. – tylerl Apr 29 '14 at 15:50
  • 1
    Sorry for nitpicking, but I can't resist not to comment when people incorrectly capitalize parts of a word, such as *HeartBleed.* Please, it's *Heartbleed!* – nyuszika7h Apr 29 '14 at 19:32

2 Answers2

20

No.

OpenBSD has measures (specifically, malloc() guard pages and wiping of deallocated memory) that should have turned Heartbleed into a crash or a leak of a whole bunch of "0x0d" bytes. However, as noted in a blog post here, OpenSSL uses its own custom memory-management system which acts to defeat those measures.

Mark
  • 34,390
  • 9
  • 85
  • 134
6

There seem to be some misconceptions here about how memory management in OpenSSL works.

OPENSSL_malloc and OPENSSL_free by default just call the system malloc and free (there is some indirection, so an application can redefine these functions if it wants, but OpenSSL doesn't do that itself). However, for some data structures, notably input buffers, it keeps hold of some previously allocated but unused items on a freelist, without actually freeing them. Since it doesn't sanitize the buffer contents after use, if a buffer is taken from the freelist and reused the previous contents may still be present (even if the system free would have erased it).

However, since in most other cases, OpenSSL is in fact just calling the system malloc and free, mitigations like guard pages (which would have made a read past the end of the 16K input buffer crash) and clearing freed memory (which would have stopped some of the bignum data leakage people have seen) would have helped, even with OpenSSL's current memory management. They wouldn't have helped with exposing previous input buffer contents or with private bignum data that was in valid (unfreed) heap locations (unless guard pages were used to prevent the overread happening at all).

Matthew
  • 61
  • 2
  • 2
    I find this answer confusing. At first you appear to be implying that OpenSSL's memory functions aren't all that bad, but then using further technical details you specify how they actually *are* bad. It would be helpful if you specified a clearer 'yes' and 'no' answer. It requires very detailed reading now to see you mean the 'no' answer, although that conclusion is quite simple. – DCKing Apr 30 '14 at 14:16
  • 1
    If guard pages had been enabled, that would have been a partially effective mitigation. If memory blanking on free had been enabled, that would have been a partially effective mitigation. The attack would have been entirely mitigated if input buffers had been blanked when no longer used (either by OpenSSL or by free) and if input buffers were protected by guard pages from an overread as well. Clearer? – Matthew Apr 30 '14 at 20:16