| [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]
