Re: OT: Re: FYA: http://heartbleed.com/
On Thu, 10 Apr 2014 03:44:26 +, Ralph W Siegler wrote: Stuart Henderson stu at spacehopper.org writes: On 2014-04-09, sven falempin sven.falempin at gmail.com wrote: i which this : https://polarssl.org was open and inside the base You can wish, but that is commercial+GPL code so OpenBSD can't use it in base. What I would wish for is the OpenSSH project to expand to become the OpenSSH/SSL project. I'll take a 'correct and slow' transport layer security over 'fast and bypassing my OS's memory protection features' transport layer security any day. Such a scope would seem to be within the purview of securing communications. Dang, I got my wish with the LibreSSL project! Another donation coming up!
Re: FYA: http://heartbleed.com/
patrick keshishian pkesh...@gmail.com wrote: [...] | ... the NSA has more than 1,000 experts | devoted to ferreting out such flaws using | sophisticated analysis techniques, many of them | classified. The agency found Heartbleed shortly | after its introduction, according to one of the | people familiar with the matter, and it became a | basic part of the agency's toolkit for stealing | account passwords and other common tasks. found! OK. so it wasn't implanted in there... what a relief! [...] source: http://www.businessweek.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers I just want to put your quotation in its context. Just before it: | While many Internet companies rely on the free code, its integrity depends | on a small number of underfunded researchers who devote their energies to | the projects. | | In contrast, ... [your quotation] For businessweek it is just a matter of money. :) Rodrigo.
Re: FYA: http://heartbleed.com/
John Moser john.r.mo...@gmail.com wrote: On Thu, Apr 10, 2014 at 4:18 PM, John Moser john.r.mo...@gmail.com wrote: Also why has nobody corrected me on this yet? I've read El Reg's analysis, and they missed a critical detail that I didn't see until I read the code in context: IT ALLOCATES TOO SMALL OF A WRITE BUFFER, TOO. Okay, it would send out the payload on exploit. It would also kill a heap canary that glibc should catch on free(). Christ maybe you're right. I'm looking at this again and I'm wrong: it DOES allocate big enough of a payload. Obviously I am not a programmer. There actually is no memory allocator bug in this code; it uses the allocator entirely correctly. I have never seen before such technical news in a normal newspaper: http://www.faz.net/aktuell/feuilleton/openssl-sicherheitsluecke-jetzt-muss-jeder-jedes-passwort-aendern-12889676.html Rodrigo.
Re: FYA: http://heartbleed.com/
On 08/04/14 21:40, Theo de Raadt wrote: On Tue, Apr 08, 2014 at 15:09, Mike Small wrote: nobody openbsd.as.a.desk...@gmail.com writes: read overrun, so ASLR won't save you What if malloc's G option were turned on? You know, assuming the subset of the worlds' programs you use is good enough to run with that. No. OpenSSL has exploit mitigation countermeasures to make sure it's exploitable. What Ted is saying may sound like a joke... So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever. Some other debugging toolkits get them too. To a large extent these come with almost no performance cost. But around that time OpenSSL adds a wrapper around malloc free so that the library will cache memory on it's own, and not free it to the protective malloc. You can find the comment in their sources ... #ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just OH, because SOME platforms have slow performance, it means even if you build protective technology into malloc() and free(), it will be ineffective. On ALL PLATFORMS, because that option is the default, and Ted's tests show you can't turn it off because they haven't tested without it in ages. So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys. OpenSSL is not developed by a responsible team. Just for completion on this interesting debate about this malloc wrapper issue that has been raised here, I have forwarded it to the OpenSSL developers: http://thread.gmane.org/gmane.comp.encryption.openssl.devel/24208 I guessed that you might be interested in knowing that. Regards! [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: FYA: http://heartbleed.com/
| [NSA] knew for at least two years about ... the | Heartbleed bug, and regularly used it to gather | critical intelligence, two people familiar with | the matter said. I was waiting for someone to say this. | ... the NSA has more than 1,000 experts | devoted to ferreting out such flaws using | sophisticated analysis techniques, many of them | classified. The agency found Heartbleed shortly | after its introduction, according to one of the | people familiar with the matter, and it became a | basic part of the agency's toolkit for stealing | account passwords and other common tasks. found! OK. so it wasn't implanted in there... what a relief! | Currently, the NSA has a trove of thousands of | such vulnerabilities that can be used to breach | some of the world's most sensitive computers, | according to a person briefed on the matter. | Intelligence chiefs have said the country's | ability to spot terrorist threats and understand | the intent of hostile leaders would be vastly | diminished if their use were prohibited. source: http://www.businessweek.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers See? This was all for the good of freedom loving people after all! I wonder when they'll leak the backdoor implan...I mean they found in OpenBSD. --patrick On 4/10/14, Carlos Alberto Lopez Perez clo...@igalia.com wrote: On 08/04/14 21:40, Theo de Raadt wrote: On Tue, Apr 08, 2014 at 15:09, Mike Small wrote: nobody openbsd.as.a.desk...@gmail.com writes: read overrun, so ASLR won't save you What if malloc's G option were turned on? You know, assuming the subset of the worlds' programs you use is good enough to run with that. No. OpenSSL has exploit mitigation countermeasures to make sure it's exploitable. What Ted is saying may sound like a joke... So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever. Some other debugging toolkits get them too. To a large extent these come with almost no performance cost. But around that time OpenSSL adds a wrapper around malloc free so that the library will cache memory on it's own, and not free it to the protective malloc. You can find the comment in their sources ... #ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just OH, because SOME platforms have slow performance, it means even if you build protective technology into malloc() and free(), it will be ineffective. On ALL PLATFORMS, because that option is the default, and Ted's tests show you can't turn it off because they haven't tested without it in ages. So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys. OpenSSL is not developed by a responsible team. Just for completion on this interesting debate about this malloc wrapper issue that has been raised here, I have forwarded it to the OpenSSL developers: http://thread.gmane.org/gmane.comp.encryption.openssl.devel/24208 I guessed that you might be interested in knowing that. Regards! [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: FYA: http://heartbleed.com/
Theo de Raadt deraadt at cvs.openbsd.org writes: So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys. So maybe you're right. Maybe we should all have these protections. I know glibc has some, but I don't think it just crashes out if you malloc(16) and read 65000 bytes. It will if you're at top of heap (should I say top of brk() to sound like I know what I'm talking about?) and hit an unmapped page; but the heap is one continuous mapped region, and you'll wind up all over it. So most of OpenSSL isn't run on OpenBSD. We have appliances that are vulnerable--FortiNet stuff, SonicWall stuff. Lots of RedHat, Fedora, CentOS, SuSE, Ubuntu, Debian, whatever machines. Basically everyone's vulnerable. This vulnerability would have been found if, before release of 1.0.1, someone would have taken a packet analyzer to OpenSSL and tried this. Regardless of your OpenBSD special memory allocation leak condom, a bunch of data coming back when you should see 4 bytes says something is very wrong here. So we assume it wouldn't have been found. If we did anything to trigger the bug, it would crash on OpenBSD, in Theo's ideal world; as apparently nobody triggered the bug, it still would have not crashed on OpenBSD, in Theo's ideal world. (We'll pretend Theo's ideal world is limited to coding concerns in OpenSSL, and doesn't involve everyone running OpenBSD or an OpenBSD-like malloc() implementation.) The moment this went out, some blackhat may have secretly analyzed the diff between 1.0 and 1.0.1 and gone, Oh lol! Or maybe saw the new support for TLS Heartbeat and gone, Hey man, a new feature. I bet I can break it! Security researchers took until 1.0.1f to do this. Even ignoring the full disclosure, a responsible disclosure would have shifted distribution packages around immediately when the new code went up. Every distribution has a network of friends in every other distribution who are all hooking up with upstream developers so that they all know about security vulnerabilities before they're out. Every distribution packages a patched binary before upstream drops code. Every distribution is ready to throw that thing right up on the mirrors immediately, one second after the code release hits the upstream repositories. And several hours later, sysadmins start noticing there's a security update. Some of us patch immediately, in production. Some of us have to run through evaluation, risk analysis (this takes me, personally, between ten seconds and ten minutes), testing, then final roll-out. Some of us need an hour; some of us need weeks. We're already hours behind. Between blackhats maybe finding the bug and not saying anything, blackhats analyzing the bug between announcement and the sysadmin noticing, and blackhats analyzing the bug between sysadmins noticing and patching, you have this big window of maybe we were hacked, and we have no real way to tell. Congratulations: your Chief Information Security Engineer is Schrödinger's Cat. Your keys may have been stolen. Or not. You can patch quickly, but then you assume nobody has stolen your keys in the first hour or twelve that the exploit became known. So, no. Even if OpenSSL were developed responsibly by the standards of Theo, 99.999% of everything would still be vulnerable. Hell, even with Responsible Disclosure, our only reasonable response to this bug is to revoke and reissue 99.999% of all SSL certificates ever issued. And that's even considering just how much of a huge advantage responsible disclosure would have given us in terms of response time, as I've illustrated. This is not a situation where the programmers would have saved us all the headache by not tweaking away an OpenBSD protection. That was never a thing. Good PR for that protection--and maybe we should look at implementing it everywhere; I don't know, I don't understand it and thus can't analyze the risks or costs--but it's not something that, as a protection only available currently on OpenBSD, would have actually changed the situation. GMANE captcha: profiled
Re: FYA: http://heartbleed.com/
The moment this went out, some blackhat may have secretly analyzed the diff between 1.0 and 1.0.1 and gone, Oh lol! Or maybe saw the new support for TLS Heartbeat and gone, Hey man, a new feature. I bet I can break it! Security researchers took until 1.0.1f to do this. Even before heartbeat arrived, it would have crashed with the stupid openssl allocator turned off. Try it. Compile libssl with -DDOPENSSL_NO_BUF_FREELIST Start nginx, put it under some heavy service. Look at the logs. See how bad things start to happen? Had the non-freelist code path been tested in OpenBSD OR ANYWHERE ELSE, it would have alerted the entire world that there are use-after-free's in other code paths. And the use-after-free's would have been fixed. They would not be able to hide. OpenSSL would have had a robust internal memory allocator. In the context of security software, robust means fail-hard, fail-closed, when any unexpected condition is triggered. That bad feature was added in 2006 and fully entrenched by 2008. More recently, the heartbeat feature was added, and if a hard system allocator was available, the initial testing would probably have exposed the problem right during the development cycle. Then it would have been fixed before deployment. But I think it is clear you aren't a programmer, and this is over your head. Or you are simply making excuses for others. Did they pay you to write all that text?
Re: FYA: http://heartbleed.com/
Compile libssl with -DDOPENSSL_NO_BUF_FREELIST Yes but that's because OpenSSL is broken. If OpenSSL had not been broken in this respect, Segglemann's bug would not have survived any sort of testing or peer review. So no, fixing OpenSSL to work without its freelist would not necessarily have exposed heartbleed. John, there is bullshit coming out of your mouth.
Re: FYA: http://heartbleed.com/
Em 10-04-2014 15:22, Theo de Raadt escreveu: Compile libssl with -DDOPENSSL_NO_BUF_FREELIST Yes but that's because OpenSSL is broken. If OpenSSL had not been broken in this respect, Segglemann's bug would not have survived any sort of testing or peer review. So no, fixing OpenSSL to work without its freelist would not necessarily have exposed heartbleed. John, there is bullshit coming out of your mouth. Oh my. Let us do a ssl library. Oh, it would be nice if we managed our own memory, you know, cause every library should manage their own memory. Why trust the operating system? After all it is not like it has being doing this forever. If more people use OpenBSD to develop and test things, I assure you that the world would be safer. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: FYA: http://heartbleed.com/
Maybe in your imaginary world where your malloc() library is a static code correctness analysis tool instead of a behavioral anomaly detection tool. The fact remains that this was a boundary error triggered by incorrect user input validation--that it would not crash under any circumstances where 100% of all OpenSSL code besides this very small block of code was 100% correct unless it was actively exploited. Normal heartbeats stay within correct bounds and function correctly: 100 bytes are allocated, the payload says it's 100 bytes, 100 bytes are read, no boundaries are exceeded. Apparently nobody did any testing or peer review that involved saying, Oh, shit. You actually send the length of a piece of user-supplied data WITH user-supplied data? I hope you're checking for any kind of stupid shit the user may do, like ask you to copy 5000 bytes of data into a 50 byte buffer and inject code, or something. If they did, they would have seen that they sent a 4 byte long heartbeat with a payload length of 10, and got back 10 bytes, and wondered where the hell 10 bytes came from. The range checking is happening inside dynamically allocated memory. I suspect Mr. Segglemann did run a simple test with all the sizes, but the daemon did not crash on him because the allocation scheme disables an increasingly common safetybelt for dynamically allocated memory. If he didn't do such a test, you would be the one calling him incompetent. This OpenBSD malloc safety belt is also included in many programming test tools. Surely someone ran those in the last two years. Unfortunately, the OpenSSL freelist foils them all, because inside the program full scope the objects remain live. You seem to understand bugs from the top down. But you don't understand that we can resist them from the bottom up, essentially free. Unless people overly complicate their own software to make security assessment impossible.
Re: FYA: http://heartbleed.com/
On Thu, Apr 10, 2014 at 4:18 PM, John Moser john.r.mo...@gmail.com wrote: Also why has nobody corrected me on this yet? I've read El Reg's analysis, and they missed a critical detail that I didn't see until I read the code in context: IT ALLOCATES TOO SMALL OF A WRITE BUFFER, TOO. Okay, it would send out the payload on exploit. It would also kill a heap canary that glibc should catch on free(). Christ maybe you're right. I'm looking at this again and I'm wrong: it DOES allocate big enough of a payload. Obviously I am not a programmer. There actually is no memory allocator bug in this code; it uses the allocator entirely correctly.
Re: FYA: http://heartbleed.com/
On Tue, Apr 8, 2014 at 9:40 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: OpenSSL is not developed by a responsible team. And on twitter and google+ I've seen a lot of people who believe that OpenSSL is an OpenBSD project :(
Re: FYA: http://heartbleed.com/
Perfect Forward Secrecy by default? Is it on in OpenBSD? On Wed, Apr 9, 2014 at 9:07 AM, David Coppa dco...@gmail.com wrote: On Tue, Apr 8, 2014 at 9:40 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: OpenSSL is not developed by a responsible team. And on twitter and google+ I've seen a lot of people who believe that OpenSSL is an OpenBSD project :(
Re: OT: Re: FYA: http://heartbleed.com/
On 2014-04-09, sven falempin sven.falem...@gmail.com wrote: i which this : https://polarssl.org was open and inside the base You can wish, but that is commercial+GPL code so OpenBSD can't use it in base. https://en.wikipedia.org/wiki/Secure_Transport#Overview Though I wonder how many OpenSSL premium support customers' worth of annual fees it would take to persuade them to relicense.
Re: FYA: http://heartbleed.com/
Em 09-04-2014 05:02, nobody escreveu: Perfect Forward Secrecy by default? Is it on in OpenBSD? I use httpd and with the default configuration it uses PFS by default, if you just enable ssl and setup the cert and key. But it allows any cipher, so an old browser or a client that does not support it, will still be able to connect. You can deny it though. I don't know about the default nginx configuration, but I assume it will be along the same lines. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: FYA: http://heartbleed.com/
Theo de Raadt wrote: Some other debugging toolkits get them too. To a large extent these come with almost no performance cost. Is there any special reason why there is no /etc/malloc.conf by default (linking to, say, 'S') then? Philippe
Re: FYA: http://heartbleed.com/
On Wed, Apr 09, 2014 at 11:49:56AM -0400, Philippe Meunier wrote: Theo de Raadt wrote: Some other debugging toolkits get them too. To a large extent these come with almost no performance cost. Is there any special reason why there is no /etc/malloc.conf by default (linking to, say, 'S') then? Philippe THe almost for free features are enabled by default. The remaining are switched on by S, but are certainly not for free. -Otto
Re: FYA: http://heartbleed.com/
Theo de Raadt wrote: Some other debugging toolkits get them too. To a large extent these come with almost no performance cost. Is there any special reason why there is no /etc/malloc.conf by default (linking to, say, 'S') then? Yes, there's a real good reason -- too much portable software breaks. The right level of mitigations are currently turned on. We are continually cranking the knob just a little bit more to turn on a few more. For example, a mechanims called PIE was just enabled system-wide on powerpc and i386. It was already enabled elsewhere. And we have just switched from the old 8-byte -fstack-protector heuristic to the new -fstack-protector-strong heuristic. It has taken more than 10 years to slowly ramp up the security migitations, generate soft pain, and thus push improvements up into the massive portable software base. Go look for my presentation in Russia.
Re: FYA: http://heartbleed.com/
On 2014-04-09, Theo de Raadt dera...@cvs.openbsd.org wrote: Is there any special reason why there is no /etc/malloc.conf by default (linking to, say, 'S') then? Yes, there's a real good reason -- too much portable software breaks. No, the performance impact of the stricter malloc options means that developers and bulk builders don't want to enable them, so we don't actually know what breakage will result. -- Christian naddy Weisgerber na...@mips.inka.de
Re: OT: Re: FYA: http://heartbleed.com/
Stuart Henderson stu at spacehopper.org writes: On 2014-04-09, sven falempin sven.falempin at gmail.com wrote: i which this : https://polarssl.org was open and inside the base You can wish, but that is commercial+GPL code so OpenBSD can't use it in base. What I would wish for is the OpenSSH project to expand to become the OpenSSH/SSL project. I'll take a 'correct and slow' transport layer security over 'fast and bypassing my OS's memory protection features' transport layer security any day. Such a scope would seem to be within the purview of securing communications.
Re: OT: Re: FYA: http://heartbleed.com/
On Wed, Apr 9, 2014 at 8:44 PM, Ralph W Siegler rsieg...@rsiegler.orgwrote: Stuart Henderson stu at spacehopper.org writes: On 2014-04-09, sven falempin sven.falempin at gmail.com wrote: i which this : https://polarssl.org was open and inside the base You can wish, but that is commercial+GPL code so OpenBSD can't use it in base. What I would wish for is the OpenSSH project to expand to become the OpenSSH/SSL project. I'll take a 'correct and slow' transport layer security over 'fast and bypassing my OS's memory protection features' transport layer security any day. Such a scope would seem to be within the purview of securing communications. So Theo's message in the other thread about openssh and the foundation imho is the right approach. Not that my opinion matters. Point out what secure, fundamentally important software billions of people rely on every second of every day and don't pay a dime for. Step up and donate, I'm sure everybody here agrees. The problem with that as I see it is that people will complain about not being able to donate to a specific subset of the project. As with OpenSSH in the past and probably present. The same way many complained before the foundation existed about paying Theo's power bill and humble salary. I shouldn't say problem, couldn't think of better language, just that there may be an opportunity here. I disagree with that attitude completely but in this case would it be such a bad idea to make an appeal to the broader community and seek funding for just this? I guess my point is, people are worked up about this and everybody knows you guy's are the ones to fix it, even if they whine about their hurt feelings. -noah
Re: OT: Re: FYA: http://heartbleed.com/
The problem with that as I see it is that people will complain about not being able to donate to a specific subset of the project. As with OpenSSH in the past and probably present. The same way many complained before the foundation existed about paying Theo's power bill and humble salary. [...] A correction is due here. My salary is only a sub-set of the CD sales. That is a result of the bi-annual release engineering. In years past, the CD revenue beyond my salary was used to fund hackathons, network, and the electricity. That decreased as time went by. Until there was little left. Then the Foundation came along. So, regarding your paragraph: donations were not for my salary.
Re: OT: Re: FYA: http://heartbleed.com/
On Wed, Apr 9, 2014 at 10:25 PM, Theo de Raadt dera...@cvs.openbsd.orgwrote: The problem with that as I see it is that people will complain about not being able to donate to a specific subset of the project. As with OpenSSH in the past and probably present. The same way many complained before the foundation existed about paying Theo's power bill and humble salary. [...] A correction is due here. My salary is only a sub-set of the CD sales. That is a result of the bi-annual release engineering. In years past, the CD revenue beyond my salary was used to fund hackathons, network, and the electricity. That decreased as time went by. Until there was little left. Then the Foundation came along. So, regarding your paragraph: donations were not for my salary. Sorry if I wasn't clear. I kind of muddled the two together. I do understand that. It's why I stated 'before the foundation existed'. If my memory serves me it was a point of contention that cd sales and whatever meager direct donations went into a big pot, most of which is for what you described, the rest for you and that it wasn't tax deductible. If I can manage to be clear for a change, I always thought it was a bullshit attitude but seems to be a reality. People who donate only because they get tax breaks are pricks. Maybe I'm off base and it's not worth the time to pander to those folks. Ignoring the masses is one of the things that make this project great. I'll stop beating this bike shed colored horse now. Thank you all for your hard work and dedication. I'll be able to make a donation at the end of this month and will. --noah
FYA: http://heartbleed.com/
OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012) how surprising.. but doesn't ASLR suppose to protect from this? http://undeadly.org/cgi?action=articlesid=20140408063423
Re: FYA: http://heartbleed.com/
read overrun, so ASLR won't save you - any pro-active thoughts to prevent this in the future? (I'm not a programmer, so.. pardon if my question is idiotic) Thanks! On Tue, Apr 8, 2014 at 7:34 PM, nobody openbsd.as.a.desk...@gmail.comwrote: OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012) how surprising.. but doesn't ASLR suppose to protect from this? http://undeadly.org/cgi?action=articlesid=20140408063423
Re: FYA: http://heartbleed.com/
nobody openbsd.as.a.desk...@gmail.com writes: read overrun, so ASLR won't save you What if malloc's G option were turned on? You know, assuming the subset of the worlds' programs you use is good enough to run with that.
Re: FYA: http://heartbleed.com/
On Tue, Apr 08, 2014 at 15:09, Mike Small wrote: nobody openbsd.as.a.desk...@gmail.com writes: read overrun, so ASLR won't save you What if malloc's G option were turned on? You know, assuming the subset of the worlds' programs you use is good enough to run with that. No. OpenSSL has exploit mitigation countermeasures to make sure it's exploitable.
Re: FYA: http://heartbleed.com/
On Tue, Apr 08, 2014 at 15:09, Mike Small wrote: nobody openbsd.as.a.desk...@gmail.com writes: read overrun, so ASLR won't save you What if malloc's G option were turned on? You know, assuming the subset of the worlds' programs you use is good enough to run with that. No. OpenSSL has exploit mitigation countermeasures to make sure it's exploitable. What Ted is saying may sound like a joke... So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever. Some other debugging toolkits get them too. To a large extent these come with almost no performance cost. But around that time OpenSSL adds a wrapper around malloc free so that the library will cache memory on it's own, and not free it to the protective malloc. You can find the comment in their sources ... #ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just OH, because SOME platforms have slow performance, it means even if you build protective technology into malloc() and free(), it will be ineffective. On ALL PLATFORMS, because that option is the default, and Ted's tests show you can't turn it off because they haven't tested without it in ages. So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys. OpenSSL is not developed by a responsible team.
OT: Re: FYA: http://heartbleed.com/
On Tue, Apr 8, 2014 at 12:40 PM, Theo de Raadt dera...@cvs.openbsd.orgwrote: On Tue, Apr 08, 2014 at 15:09, Mike Small wrote: nobody openbsd.as.a.desk...@gmail.com writes: read overrun, so ASLR won't save you What if malloc's G option were turned on? You know, assuming the subset of the worlds' programs you use is good enough to run with that. No. OpenSSL has exploit mitigation countermeasures to make sure it's exploitable. What Ted is saying may sound like a joke... So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever. Some other debugging toolkits get them too. To a large extent these come with almost no performance cost. But around that time OpenSSL adds a wrapper around malloc free so that the library will cache memory on it's own, and not free it to the protective malloc. You can find the comment in their sources ... #ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just OH, because SOME platforms have slow performance, it means even if you build protective technology into malloc() and free(), it will be ineffective. On ALL PLATFORMS, because that option is the default, and Ted's tests show you can't turn it off because they haven't tested without it in ages. So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys. OpenSSL is not developed by a responsible team. Perhaps it's a great time to kickstart an OpenOpenSSL replacement, a la bgpd, ospfd, smtpd et al? Now, I don't have the skills or the guts, but I do have $5 on it. Anybody else?
Re: OT: Re: FYA: http://heartbleed.com/
On Tue, Apr 8, 2014 at 9:05 PM, noah pugsley noah.pugs...@gmail.com wrote: On Tue, Apr 8, 2014 at 12:40 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: On Tue, Apr 08, 2014 at 15:09, Mike Small wrote: nobody openbsd.as.a.desk...@gmail.com writes: read overrun, so ASLR won't save you What if malloc's G option were turned on? You know, assuming the subset of the worlds' programs you use is good enough to run with that. No. OpenSSL has exploit mitigation countermeasures to make sure it's exploitable. What Ted is saying may sound like a joke... So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever. Some other debugging toolkits get them too. To a large extent these come with almost no performance cost. But around that time OpenSSL adds a wrapper around malloc free so that the library will cache memory on it's own, and not free it to the protective malloc. You can find the comment in their sources ... #ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just OH, because SOME platforms have slow performance, it means even if you build protective technology into malloc() and free(), it will be ineffective. On ALL PLATFORMS, because that option is the default, and Ted's tests show you can't turn it off because they haven't tested without it in ages. So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys. OpenSSL is not developed by a responsible team. Perhaps it's a great time to kickstart an OpenOpenSSL replacement, a la bgpd, ospfd, smtpd et al? Now, I don't have the skills or the guts, but I do have $5 on it. Anybody else? i which this : https://polarssl.org was open and inside the base -- - () ascii ribbon campaign - against html e-mail /\
