1

I asked a question on stackoverflow, but guess this site is better suited for it.

Idea is to prevent problems when the next buffer overflow bug comes out.

In my understanding the problem with Heartbleed was the access to memory of previous requests? Isn't it possible to wipe the memory after using it? To use different memory spaces for each request, that are not accessible by the next one? If the web server (e.g. apache or nginx) is started with multiple processes, are they still sharing memory containing user information?

My question in short: Is it possible to configure Apache/Nginx/Linux/others to use a more secure model of memory access?

Performance reduction wouldn't matter since Heartbleed 2.0 will eventually come and then you just have a quick laugh instead of lots of work.

5

(Much of this is based on my answer here)

There are techniques, such as memory guard pages and wiping of deallocated memory, that should have stopped Heartbleed or a similar attack in the future. OpenBSD, for example, uses them by default. Heartbleed was made worse because it uses its own memory allocator that actively works to defeat memory protection.

There's a limit to how much protection an operating system can provide against incompetent programming. Heartbleed exceeded that limit.

  • interesting, so more or less you're saying it's not possible because of openssl itself? and if the openssl library (or any other) was loaded fresh for every request? speed wouldn't really matter if it means not reseting thousands of passwords and informing the users. – Ikarus May 3 '14 at 22:29
  • Even if you reloaded the OpenSSL library with every request, it would still leak data from that request -- such as the SSL private key. – Mark May 3 '14 at 22:56
  • wow, didn't think about that part. thank you for all the explanations! – Ikarus May 3 '14 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.