Slashdot Mirror
OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks
Bismillah (993337) writes "A potentially very serious bug in OpenSSL 1.0.1 and 1.0.2 beta has been discovered that can leak just about any information, from keys to content. Better yet, it appears to have been introduced in 2011, and known since March 2012."
Quoting the security advisory: "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server." The attack may be repeated and it appears trivial to acquire the host's private key. If you were running a vulnerable release, it is even suggested that you go as far as revoking all of your keys. Distributions using OpenSSL 0.9.8 are not vulnerable (Debian Squeeze vintage). Debian Wheezy, Ubuntu 12.04.4, Centos 6.5, Fedora 18, SuSE 12.2, OpenBSD 5.4, FreeBSD 8.4, and NetBSD 5.0.2 and all following releases are vulnerable. OpenSSL released 1.0.1g today addressing the vulnerability. Debian's fix is in incoming and should hit mirrors soon, Fedora is having some trouble applying their patches, but a workaround patch to the package .spec (disabling heartbeats) is available for immediate application.
"We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."
Yikes. And it's been known for 2 years. That's some shit!
Who knows who knew what and when, but the 2012 statement is a misinterpretation of TFA where they seem to be saying it essentially started "hitting the shelves" in distros about then, whereas before then it was mostly only distributed in beta builds and head code.
Someone had to do it.
Now how are we supposed to collect people's private information without their knowledge? Think of the children and all of the terrorists captured with this exploit in the wild!
sincerely,
NSA
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Never trusted openssl - only use GnuTLS.
http://www.theregister.co.uk/2...
Irony rears it's head on the day that patches for a Linux vulnerability are announced at the same time Microsoft ends its patching and update service for Windows XP.
How is a vulnerability in OpenSSL, which is a library that can be compiled for multiple platforms, a "Linux vulnerability"?
As I can't imagine the servers I connect to being interested in snooping on my client data, I presume this bug is only a real concern for systems running services, not acting as clients.
I do not fail; I succeed at finding out what does not work.
Basically it means if you know any UNIX sysadmins, they'll be pretty cranky for the next week or so as they've been busy trying to put the poop back in the baby.
Oh yeah, and lots of your gadgets and favorite cloud services may be vulnerable, so anything stored on them may be in the hands of others.
Someone had to do it.
sudo apt-get update && sudo apt-get upgrade.
Generate and distribute new keys.
Problem soved.
"On the Internet, nobody can hear you being subtle." -Linus Torvalds
Could someone please give Theo a heap of grief over this from me? He's always so quick to bag out GnuTLS and others when they have an issue. Only fair he gets a share of what he dishes out. Besides, this seems to be even worse than a "goto fail"...
Nobody tell the NSA about this, okay?
Have you tried turning it off and on again?
can someone link to the git blame of the bug please?
Is there anyone on the planet using TLS heartbeats via TCP for anything except exploiting this bug? What is even the point of heartbeats without DTLS?
Bugs are bugs yet decision to enable a mostly useless feature for non-DTLS by default in my view is not so easily excusable.
Well, it's not good that almost every major audit-able crypto library has been found to have trivial exploits (still waiting on issues in the Chrome and Mozilla SSL libraries).
It's good that eyes are looking, and people are finding these things. I imagine that without Snowden's revelations, nobody would have bothered to check. And these bugs would have been found much later or not at all, allowing espionage organizations to compromise many more private communications in the interim.
While the idea that the NSA or some other agency had a hand in these bugs is largely a conspiracy theory, the answer to whether they knew about these flaws and exploited them should be pretty obvious. After all, the NSA has probably done the very same code audits for the purpose of finding holes they can exploit.
And before somebody says a closed-source implementation wouldn't suffer these problems, quite frankly, if all of these libraries were closed-source, we wouldn't know if there was a vulnurability at all, or for that matter if any found would be fixed. There needs to be more eyes auditing the security code, not fewer.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Because nobody even attempts to run secure applications on any other platform...
That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.
Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.
NSA, I am sure, know plenty of holes — if not custom-made by the authors doors — into proprietary software too.
I am disappointed at the quality of open source software — especially pieces as famous and fundamental as OpenSSL, and I agree, that open source's claimed advantage of there being "thousands of eyeballs" verifying its correctness is overblown.
But to declare it to be "losing" is a silly jump just as far in the direction opposite to the enthusiastic proclamations of the above mentioned ideology-driven advocates.
In Soviet Washington the swamp drains you.
Linux Mint, and I'd assume Ubuntu too, has already pushed the updates out. Happy happy. Joy joy.
How the fuck did this get modded up? Idiot mods (and "DarwinSurvivor", apparently) can't read a link, I guess...
The only way this could have been stupider is if it was actually the same link, instead of merely being a link that I could tell, just from the URL, was about exactly the same issue.
Morons.
There's no place I could be, since I've found Serenity...
Any data kept in RAM on an open-ssl box has probably been compromised. It sounds like that includes private keys, root certs, passwords, etc.
This is why passwords etc should be encrypted in RAM. It's funny, there's a Security Technical Implementation Guides (STIG) on that very item. It always sounded sort of ridiculous, but now I know why it was there.
Chrome just uses the operating system for a lot of the certificate validation of HTTPS, so it can be vulnerable to security holes that apply to the operating system. Chrome wasn't vulnerable to "goto fail", but presumably it has been vulnerable to others in Windows and Mac OS.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Shill much?
Two anonymous cowards with IDs less than 1000 digits apart write anti-open source posts at the same time?
But the actual announcement is not among them.
https://www.openssl.org/news/secadv_20140407.txt
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.
It's not the fix of the code that's messy. It's the fix of the trusts using that code to function. They are all broken. After the upgrade keys need to be replaced, certificates re-issued, endpoints and clients reconfigured to trust new keys, and in some cases customers and end-users may need to be involved. For anything of CDE level security or higher, it's as big a cleanup job than the one that gave us openssl-blacklist, but the blacklist for this would be neither complete nor easy to assemble.
I predict a lot more interest in turning on CRL pathways in the future.
Someone had to do it.
Good thing I use WIndows, so I'm safe.
Does this effect SSH at all? It seems more likely this would effect TSL servers such as Apache and stunnel.
Yet again, C's non-existent bounds checking and completely unprotected memory access lets an attacker compromise the system with data.
But hey, it's faster.
Despite car companies complaining loudly that if people just drove better there would be no accidents, laws were eventually changed to require seatbelts and airbags because humans are humans and accidents are inevitable.
Because C makes it trivially easy to stomp all over memory we are guaranteed that even the best programmers using the best practices and tools will still churn out the occasional buffer overflow, information disclosure, stack smash, or etc.
Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory. Singularity proved that was perfectly workable. I don't care if the language is C#, Rust, or whatever else. How many more times do we have to get burned before we make the move?
As long as all our personal information relies on really smart people who never make mistakes, we're doomed.
Natural != (nontoxic || beneficial)
Keeping the passwords encrypted in RAM doesn't help all that much if you also have the decryption key in RAM. Which you do, because you need to use the password. Right?
Having said that; a server should (ideally) never have a plain-text password anyway.
*air-punch*
I knew procrastinating Debian upgrades for most of a decade would pay off! I am VINDICATED!
Shill much?
Two anonymous cowards with IDs less than 1000 digits apart write anti-open source posts at the same time?
LOL!
That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.
...
systemd devs seem bound and determined to prove you wrong there...
Yeah, sometimes I say things so stupid, it amazes me, too
My understanding is that Chrome and Mozilla both use NSS. It's a bit outdated, so I could be wrong (given that Google forked webkit, I can imagine them forking NSS too).
Actually, with a quick Google search, it seems that Chrome on Android uses (used?) OpenSSL for certain functions. I'm curious to know if secure communication via Android devices can be compromised via those functions. At first glance, I'd say no, but I don't have enough domain knowledge to make this assertion.
NSS is thus far secure, but I really, really would like to see the results of multiple full and independent audits. If there's a problem in NSS, that would be about as big as it can get.
Like I said, it's a bit frightening that there are such large and somewhat obvious holes in these major crypto libraries found within three months of each other, but it's good to know that they're being found and fixed.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
On a side note, regarding advantage of there being "thousands of eyeballs" verifying its correctness" -
ESR's famous quote is "with enough eyeballs, all bugs are shallow - the fix will be obvious to someone."
The quote doesn't say anything about correctness. It says that when strange behavior is noticed, someone will see a clear fix. A shallow bug is one that's right there on the surface, where you can see the source of the problem. That's in contrast to one where you have to spend hours searching for what's causing the problem. It makes no claim of how quickly or easily a bug will be discovered - just how it can be fixed once it's discovered.
There are security vulnerabilities seemingly EVERYWHERE. Do programmers not test their code anymore? Is there no testing protocol for security issues? Is no one embarrased to have released a piece of software that's so porous? I'm retired, and I can tell you that if I had written code with the security holes that modern programs and apps seem to have, I would have been unceremoniously fired very quickly by any and all of the several employers for whom I worked in my career. But that doesn't seem to happen today, unfortunately.
But, regardless of the root cause (intentional malice or just sloppiness) I'm glad eyes have been checking these code bases with more diligence over the past several months. In the end it means more security for us users, regardless of our platform of choice.
Thank you again, Edward Snowden, for the collective wake up call!
Now if we could just get our governing officials to fix some of these egregious laws...
#DeleteChrome
Heh, I also suffer from foot-in-mouth disease from time to time. And look - you got modded up! : )
Re " both models have advantages and disadvantages depending on what the product is, the size of its market, the type of market, etc. and sometimes those advantages can't even be realised" ... just like you did the first few times...
The problem with a closed source effort is what we saw with Prism http://www.theguardian.com/wor...
The legal system and dev staff stay with the closed source product.
With open source code - when an issue is found days, months, years later it can be corrected, fully understood and fed back into further world wide crypto education.
The other option is to trust known weakened corporate encryption over many new versions and have faith in their legal teams
The other emerging aspect is that of US National Security Letters (NSL) for ongoing bulk collection 'efforts' vs a more global open source code.
After Snowden many more people will be looking at crypto, with open source code someone might be able to offer reviewed, tested fixes to junk standards.
Domestic spying is now "Benign Information Gathering"
Figures - I write a dozen thoughtful posts that get no love, but when I take a brain shart on a post, that gets the mod points.
Any word on who was responsible for this bug?
With address space layout randomization, I can't imagine how you could probe memory for sensitive information without causing the process to randomly crash. Given how polished the website publicizing the vulnerability is, I think they're more interested in creating hype.
I once had a signature.
RHEL updates are available:
https://rhn.redhat.com/errata/RHSA-2014-0376.html
CentOS updates are available:
http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html
Fedora updates are available, hitting the mirrors, but you can get it earlier, instructions here:
https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html
https://lists.fedoraproject.org/pipermail/announce/2014-April/003206.html
Basically, an attacker can connect to many secure Internet services - could be a banking website, or your email server, or a server hosting software updates, or possibly your corporate VPN - and learn everything that the server knows. This includes the private key (sort of like a super-complex and super-secret password) that is used to *make* the service secure. The attacker can then get all the data that the server sees, ranging from normal user passwords to all your emails and banking info.
This vulnerability is many, many kinds of bad. I'm simplifying a lot here. Basically, an awful lot of data is at risk right now, because of this bug.
This site has a pretty great explanation that most people likely to be found on /. will be able to follow, even if not normally security types: http://heartbleed.com/
There's no place I could be, since I've found Serenity...
Fuzzing isn't the only way of finding vulnerabilities in closed source software, not even close. And are you saying that source is required for exploit development? That's simply not the case.
Got any actual evidence, or are you simply going to try to deflect blame away from this glaring black eye?
You're probably thinking of OpenSSH. OpenSSL is independent as far as I know.
All non-trivial code bases are stuffed with exploits, flaws, and vulnerabilities. Source: Just ask any competent programmer.
I read TFA and all I got was this lousy cookie
Silly, all "Open*" projects are owned by OpenBSD. Like OpenGL. And OpenOffice. :p
I read TFA and all I got was this lousy cookie
Hint: closed source code probably contains hundreds or thousands of these holes and they hang around unfixed for decades.
I could as well say that open source contains hundreds or thousands of these holes and more will be discovered as time passes on. And that seems to actually be the case.
See the original title of this thread: "Things are starting to turn around". How often these days do we hear about dangerous vulnerabilities in Microsoft software? Every day less and less. How often do we see fatal errors in open source software? More and more. Just from the recent months, there has been an X11 server vulnerability (lurking there for a cool 23 years), the GnuTLS bug and now this OpenSSL issue. All in very important system components.
The SSL core team all appear to be professionals.
I have not checked, but most of the contributors probably are too.
The same is true of most big open source projects (like the Linux Kernel).
The differences are:
1) There is better disclosure of bugs in open source
2) some bugs can be discovered by third party audit (as the GNUTLS bug was)
Competent programmer here. Exploits are programs developed to take advantage of flaws and vulnerabilities, so most software is not "stuffed" with them. Anyway, the post I was responding to seemed to be insinuating that bugs like this go unfixed in proprietary software simply because it is proprietary. I can tell you that is not that case. There are researchers out there combing through everything, open or closed.
To get your version, run:
openssl version
Yes, I looked it up... in hindsight, I guess it was kind of obvious and I should have been able to figure it out. Anyway, it's done. Hope it saves someone a few seconds....
Exploits are programs developed to take advantage of flaws and vulnerabilities, so most software is not "stuffed" with them.
Non sequitur. Just because an exploit has not yet been developed for a given vulnerability does not mean that the vulnerability does not exist.
Il n'y a pas de Planet B.
What are you blathering about? I was correcting his misuse of the term "exploit". Vulnerability and exploit are often used as synonyms, but they're not.
I don't understand why this is controversial. People consider it a bad idea to roll your own encryption code. Why isn't it a bad idea to roll your own bounds checking? Because it's easy and you won't screw it up? I'm sure people writing their own hash functions feel the same way.
Do people seriously prioritize speed over security? Of all of the things my computer might squander its gigahertz on, squandering them by checking bounds on things that will never actually be out of bounds isn't something I can disagree with if it makes the software running on my computer more secure. It's kind of like how, when doing math problems on a test, you check your work to make sure you get the right answer. Technically it's a waste of time if you know what you're doing, but if you're concerned about your grade, you do it anyway just in case.
Besides, if you want to whine about unnecessary wasting of CPU cycles, just look at an assembly dump of floating-point equations being solved in C as compiled by GCC. Anyone who actually knows how to do floating point in assembly language will want to cry. The round() function is a good example, as the documentation declares a specific way of rounding half-way cases which isn't what the FPU does and which anyone who knows how to use floating point math correctly will realize is a complete fucking waste of time since what the FPU does do is 100% adequate.
I read that as "potential exploits", but by all means take the point for this one--I stand corrected.
Il n'y a pas de Planet B.
It did affect your laptop, but it is patched if you have kept up with installing security updates. Ubuntu backports important fixes like this one but the version number will still be reported as the base version Ubuntu uses.
And what would be an appropriate language for writing security-critical software?
Once you have upgraded your copy openssl you can determine which processes need to be restarted by running the following command (only tested on Linux):
sudo lsof +c0 |grep DEL |grep libssl |awk '{ print $1 }' |sort |uniq
Note that just because a process is listed here doesn't mean it is vulnerable to the leak, it just means that it is linked to the vulnerable version of libssl.
And I must say it is far simpler and clear to use.
Two cents complete.
I am very small, utmostly microscopic.
Distributions using OpenSSL 0.9.8 are not vulnerable
This is why I haven't upgraded my Linux servers in 23 years.
I call BS. We are talking FOSS here so there can be absolutely no security issue because it was produced by a large community of do-gooders who vetted all commits for us and this means that every bug gets caught within seconds of being committed.
It is a fact (not theory or guess) that only commercial, closed software has security flaws.
Well, it is a security flaw/hole until it's been plugged.
Android disables heartbeats (DOPENSSL_NO_HEARTBEATS):
https://android.googlesource.com/platform/external/openssl/+/master/build-config-64.mk
Chrome uses NSS, not OpenSSL, so it's a different SSL stack.
http://golang.org/
Fascism should more properly be called corporatism because it is the merger of state and corporate power. -- Mussolini
Running 12.04 LTS and updated openssl to 1.0.1-4ubuntu5.12
Which contains the patch.
http://changelogs.ubuntu.com/c...
System is still vulnerable. Seeing this reported on askubuntu as well. filippo checker confirms site is still vulnerable after upgrade
Make sure you restart the service. Any processes launched before installing the patch may still include the old version of the shared library.
Filippo Valsorda's online tool for checking web servers for the Heartbleed vulnerability is quite an eye opener. As well as telling you whether the server is vulnerable, it displays a small snippet of the memory it retrieved (there are scripts on Github that will show you the whole 64KB I believe).
In the quick tests I did on login.yahoo.com (used for Yahoo's email and probably all other Yahoo services), I saw three different user's passwords and at least part of their usernames. And you can just sit there refreshing the page to see more! Madness!
Android 2.x is still out there for about one year. Judging by how the marketshare is dropping.
And IE on XP is now finally dying out. I hope. Although if you draw a line to 0. It's still 3.75 years before it gets there.
So I predict SNI is 3 years off ?
New things are always on the horizon
Splendid, a programming language from a dead website.
Nice threads, though.
Watch this Heartland Institute video
Conversely, just because no vulnerabilities have been found is not necessarily a good reason to assume a given piece of software is full of them.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Here is how you can test your servers to see if they are vulnerable.
Download this Python SSL Heartbleed test script.
Download it, rename it to ssltest.py, then run it as:
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
dpkg -l 'libssl*'
Watch this Heartland Institute video
Amusing fact: the primary author of systemd is the same guy that brought us pulseaudio. Why do we do this to ourselves?
Perhaps because more and more systems are being run on open source. And because it is open source, and people can read the code.
In other news, we can check everything quickly by not checking everything!
His comment is more interesting than your reply makes it out to be.
I've looked at a few disassemblies of compiled C code. GCC is already pretty good at understanding how variables interact within for() loops. If you make two nested loops, one for each index of a two dimensional array, it'll output code which simply uses a pointer that's incremented in a loop to access the array and check the pointer against a limit to determine when the loop is complete, such that the pair of for loops you wrote don't actually exist in the final code. It'll even switch the order of your nested loops if necessary to make this possible. If you perform a calculation inside of both loops that can be moved outside of one of them, it'll spot that and move the calculation outside of the inner loop. Write an equation in an unnecessarily verbose way that makes use of multiple unnecessary temporary variables? It'll notice and your temporary variables won't exist in the final code. Use the same sub-expression in multiple equations? It'll notice and calculate that sub-expression once and store it to a temporary variable. The compiler optimization isn't smart enough to turn your O(n^2) algorithm into an O(n*log(n)) algorithm, and indeed, what it does do is kind of basic, but it's still able to figure out quite a few of the more obvious optimizations, and in doing so it frees the programmer from having to worry about these more trivial things, which allows the programmer to focus their attention on things that computers aren't smart enough to do for us.
Thus, when it comes to code like this:
int a[100][100];
for (int y = 0; y < 256; y++) {
for (int x = 0; x < 256; x++) {
a[x][y] = x * y;
};
};
GCC wouldn't even think about outputting code to check the array bounds. It would check them as it compiles and decide whether to output the code without bounds checking, or, as in the case above, report that this code will always exceed the array bounds.
GCC already looks at code in enough detail that, if you call a small function that exists in the same source file, it'll notice its small size and inline it. I once had a pair of functions that each called the other recursively and saw that it chose to inline one of them within the other. So it would likely notice that the array bounds will be just fine even if you put your loop in one function and access the array in another as long as both functions exist within the same source file so that it is able to examine both functions at the same time. So, for the most part, it would only generate bounds checking where it is actually necessary: In code where the array index comes from outside the program, or in code where the index comes from within the program but through a complex enough path that even a human couldn't safely assume that they're 100% certain the index will always be within bounds.
So, most of the time, the compiler would correctly determine whether or not bounds checking is even necessary. Sure, sometimes it might be wrong, but humans get this wrong as well. The difference is that when the compiler gets it wrong, it'll err on the side of performing the check even when it's unnecessary, whereas humans tend to often get it wrong by leaving out the check even when it is necessary, or by attempting to perform the check but writing the code incorrectly so that the check fails.
As long as our software is doomed be screwed up in some manner, I'd prefer it be screwed up by being a bit slower than necessary, rather than having it expose data on my computer to any web site I visit.
Does anyone else see anything odd about the search results for this story?
I Googled "heartbleed" around 15 minutes ago and looked through 13 pages of results. I was looking for some info a little on the hardcore side, and the Google results were kind of surprising. There were tons of big well-known sites at the very top of the list - Fox, CNN, BBC News, Reuters and Forbes, etc; then a whole lot of mainstream "tech news" sites (PC World, ZDNet and so on) and blogs (HuffPo for example), then finally some more tech oriented or actual tech ones (YCombinator, Netcraft, StackOverflow) with a tiny sprinkling of blogs and relevant support forums (Cisco). US-CERT's listing was down on page 3 or so and honestly there just were not that many "hardcore" sites to be seen.
Running the search again after clearing cookies, the layout has changed a lot. The big news sites hits have slid way down (Fox News is on p. 3 now, for instance) with tech news and blogs moving up. All in all, the harder tech sites are floating upward and the less so are moving down. It's like the lava lamp version of a security scare.
Wondered what other Slashdotters think, it just seems a bit... strange, somehow. Don't these things usually bubble around in the tech community for a bit before surfacing in the mainstream world? It's like every big news site on the planet picked it up simultaneously, followed by the mainstream tech news site, and finally it began to filter down into the tech world. Could just be an artifact of Google's update cycle, but it definitely piqued my curiosity.
And what would be an appropriate language for writing security-critical software?
How about this one? It is a little memory-hungry though - 128K of RAM isn't within everyone's budget.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
I cant decide - am I looking at an intentional misrepresentation, or a facepalm-worthy senior moment? Linus' Law had nothing to do with verifying code. From Wikipedia,
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
Mac OS (10.9 at least) uses openssl version:
OpenSSL 0.9.8y 5 Feb 2013
so it shouldn't have the vulnerability.
People should not fear their government. Governments should fear their people.
That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.
Especially since a Dr Stephen Henson and the IETF member and security professional Robin Seggelmann submitted the bug, their CV:s are as professional as it gets. So please get real...
you need to assume that your private keys and other SSL artifacts have been compromise. have fun regenerating your certs and getting them re-signed.
Re-signed by a compromised private certificate?
"known for 2 years"
No, no, this has been the code part of the stable release of OpenSSL for 2 years. The bug has only been known by non-blackhats for up to a few weeks.
Yes, the heartbeat exploit popped up just recently. ...
But the bug which forces users to keep data in freed buffers has been known for at least 4 years. Tedunangst calls it "exploit mitigation countermeasures"