Re: [tor-talk] [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On Wed, Apr 9, 2014 at 2:29 PM, Christopher J. Walters <cwal989@comcast.net> >
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
That would be 2+ years of amazing win on NSA part [1]. Any unlikely impropriety would come out soon. More likely reality... opensource people are busy and good humans and coding mistakes happen. Hopefully the general buzz around NSA/security/crypto/decentral will result dedicating more permanent resource to things like protocol devel and replacements, and auditing of key underlying software code. You really need to be asking if and how the giant for-profit corps that use opensource for free are giving back. $50k a year donated to fund an independant developer pool from the OSS community to sit on the teams of your favorite code projects of choice as auditors is nothing to a companies like that, a dream gig for the dev, a win for project, and good company PR. How often do you see @ge.com @chase.com @ibm.com, etc on developer/donation lists... you need to ask those type of @'s if, how, and why not. [1] And pretty dumb of any attacker to not simply quietly watch, analyse and exploit the committed output of any critical project... no insertion, cost, or risk necessary to do that.
More likely reality... opensource people are busy and good humans and coding mistakes happen.
Given that other likely backdoors were also concealed as "mistakes" in normal commits, I wouldn't write it off. But the real villain here is coding security-critical applications in C, when there are memory-safe, more modern alternatives. The Heartbleed bug-door was a failed memory-bounds check, but that's something more modern alternatives just do automatically as a matter of course. If I recall correctly, Rust was designed explicitly to be memory safe. D is likewise memory safe, and is syntactically close enough to C that an OpenSSL rewrite isn't out of the question. On 10/04/14 08:46, grarpamp wrote:
On Wed, Apr 9, 2014 at 2:29 PM, Christopher J. Walters <cwal989@comcast.net> >
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
That would be 2+ years of amazing win on NSA part [1]. Any unlikely impropriety would come out soon. More likely reality... opensource people are busy and good humans and coding mistakes happen. Hopefully the general buzz around NSA/security/crypto/decentral will result dedicating more permanent resource to things like protocol devel and replacements, and auditing of key underlying software code. You really need to be asking if and how the giant for-profit corps that use opensource for free are giving back. $50k a year donated to fund an independant developer pool from the OSS community to sit on the teams of your favorite code projects of choice as auditors is nothing to a companies like that, a dream gig for the dev, a win for project, and good company PR.
How often do you see @ge.com @chase.com @ibm.com, etc on developer/donation lists... you need to ask those type of @'s if, how, and why not.
[1] And pretty dumb of any attacker to not simply quietly watch, analyse and exploit the committed output of any critical project... no insertion, cost, or risk necessary to do that.
-- T: @onetruecathal, @IndieBBDNA P: +353876363185 W: http://indiebiotech.com
--On Thursday, April 10, 2014 3:46 AM -0400 grarpamp <grarpamp@gmail.com> wrote:
On Wed, Apr 9, 2014 at 2:29 PM, Christopher J. Walters <cwal989@comcast.net> >
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
That would be 2+ years of amazing win on NSA part [1]. Any unlikely impropriety would come out soon. More likely reality... opensource people are busy and good humans and coding mistakes happen.
Oh. And what about the constant babbling stating that open source is oh-so-great security-wise because lots of people can look at the code bla bla bla bla bla. Bla!
Hopefully the general buzz around NSA/security/crypto/decentral will result dedicating more permanent resource to things like protocol devel and replacements, and auditing of key underlying software code. You really need to be asking if and how the giant for-profit corps that use opensource for free are giving back. $50k a year donated to fund an independant developer pool from the OSS community to sit on the teams of your favorite code projects of choice as auditors is nothing to a companies like that, a dream gig for the dev, a win for project, and good company PR.
How often do you see @ge.com @chase.com @ibm.com, etc on developer/donation lists... you need to ask those type of @'s if, how, and why not.
[1] And pretty dumb of any attacker to not simply quietly watch, analyse and exploit the committed output of any critical project... no insertion, cost, or risk necessary to do that.
Dnia czwartek, 10 kwietnia 2014 16:26:46 Juan Garofalo pisze:
--On Thursday, April 10, 2014 3:46 AM -0400 grarpamp <grarpamp@gmail.com>
wrote:
On Wed, Apr 9, 2014 at 2:29 PM, Christopher J. Walters <cwal989@comcast.net> >
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
That would be 2+ years of amazing win on NSA part [1]. Any unlikely impropriety would come out soon. More likely reality... opensource people are busy and good humans and coding mistakes happen.
Oh. And what about the constant babbling stating that open source is oh-so-great security-wise because lots of people can look at the code bla bla bla bla bla. Bla!
Well, they can. Doesn't mean they do. Time to get the message out there: "start bloody looking at the code". -- Pozdr rysiek
Message du 10/04/14 22:42 De : "rysiek" A : cypherpunks@cpunks.org Copie à : Objet : Re: [tor-talk] [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
Dnia czwartek, 10 kwietnia 2014 16:26:46 Juan Garofalo pisze:
--On Thursday, April 10, 2014 3:46 AM -0400 grarpamp
wrote:
On Wed, Apr 9, 2014 at 2:29 PM, Christopher J. Walters
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
That would be 2+ years of amazing win on NSA part [1]. Any unlikely impropriety would come out soon. More likely reality... opensource people are busy and good humans and coding mistakes happen.
Oh. And what about the constant babbling stating that open source is oh-so-great security-wise because lots of people can look at the code bla bla bla bla bla. Bla!
Well, they can. Doesn't mean they do. Time to get the message out there: "start bloody looking at the code".
-- Pozdr rysiek> [ signature.asc (0.3 Ko) ]
There is one reason why this bug came to light, we can see the source code. Otherwise it could be exploited for decades instead of two years and nobody would ever notice it.
rysiek wrote, On 04/10/2014 04:08 PM:
Dnia czwartek, 10 kwietnia 2014 16:26:46 Juan Garofalo pisze:
--On Thursday, April 10, 2014 3:46 AM -0400 grarpamp <grarpamp@gmail.com>
Oh. And what about the constant babbling stating that open source is oh-so-great security-wise because lots of people can look at the code bla bla bla bla bla. Bla!
Well, they can. Doesn't mean they do. Time to get the message out there: "start bloody looking at the code".
And time to start building from source, examining source diffs, and devising one's own stress tests. -- Patrick
Dnia czwartek, 10 kwietnia 2014 17:59:49 Patrick Chkoreff pisze:
rysiek wrote, On 04/10/2014 04:08 PM:
Dnia czwartek, 10 kwietnia 2014 16:26:46 Juan Garofalo pisze:
--On Thursday, April 10, 2014 3:46 AM -0400 grarpamp <grarpamp@gmail.com>
Oh. And what about the constant babbling stating that open source is oh-so-great security-wise because lots of people can look at the code bla bla bla bla bla. Bla!
Well, they can. Doesn't mean they do. Time to get the message out there: "start bloody looking at the code".
And time to start building from source, examining source diffs, and devising one's own stress tests.
Also, this: http://www.youtube.com/watch?v=fwcl17Q0bpk -- Pozdr rysiek
--On Friday, April 11, 2014 1:10 AM +0200 rysiek <rysiek@hackerspace.pl> wrote:
Dnia czwartek, 10 kwietnia 2014 17:59:49 Patrick Chkoreff pisze:
rysiek wrote, On 04/10/2014 04:08 PM:
Dnia czwartek, 10 kwietnia 2014 16:26:46 Juan Garofalo pisze:
--On Thursday, April 10, 2014 3:46 AM -0400 grarpamp <grarpamp@gmail.com>
Oh. And what about the constant babbling stating that open source is oh-so-great security-wise because lots of people can look at the code bla bla bla bla bla. Bla!
Well, they can. Doesn't mean they do. Time to get the message out there: "start bloody looking at the code".
And time to start building from source, examining source diffs, and devising one's own stress tests.
Also, this: http://www.youtube.com/watch?v=fwcl17Q0bpk
Ha! Very good =)
-- Pozdr rysiek
| | And time to start building from source, examining source diffs, and | devising one's own stress tests. | http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1565233 Countering trusting trust through diverse double-compiling An air force evaluation of Multics, and Ken Thompson's famous Turing award lecture "reflections on trusting trust, " showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this attack goes undetected, even complete analysis of a system's source code can not find the malicious code that is running, and methods for detecting this particular attack are not widely known. This paper describes a practical technique, termed diverse double-compiling (DDC), that detects this attack and some compiler defects as well. Simply recompile the source code twice: once with a second (trusted) compiler, and again using the result of the first compilation. If the result is bit-for-bit identical with the untrusted binary, then the source code accurately represents the binary. This technique has been mentioned informally, but its issues and ramifications have not been identified or discussed in a peer-reviewed work, nor has a public demonstration been made. This paper describes the technique, justifies it, describes how to overcome practical challenges, and demonstrates it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/10/2014 09:06 PM, dan@geer.org wrote:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1565233 Countering trusting trust through diverse double-compiling
Yep, that's it. His proof-of-concept implementation is well worth examining. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ It's easier to get forgiveness for being wrong than forgiveness for being right. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREKAAYFAlNIH5MACgkQO9j/K4B7F8HtLACg1ZIlOcCeW9Kl2fV+kDxQxNT0 SxwAnjFKiOaU995Jr4vtgoC9js+2WNhw =NinQ -----END PGP SIGNATURE-----
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
If they did it, someone got a promotion. If they are as surprised as you are, someone got fired. In the meantime, tell me that gcc is so compact and well vetted that there is no room in it for insertions... --dan, channeling for Ken Thompson
Message du 11/04/14 05:44 De : dan@geer.org
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
If they did it, someone got a promotion. If they are as surprised as you are, someone got fired.
In the meantime, tell me that gcc is so compact and well vetted that there is no room in it for insertions...
This article makes an interesting point, we got to dig a bit more from our pockets: http://www.wired.com/2014/04/heartbleedslesson/ The second point I wish to make is the surprise by which the original developer took the issue. Maybe, just maybe, he did not create that flaw at all. It could have been inserted into the OpenSSL repository through a backdoor ... or why would the spies by so interested in hacking professors that deal with crypto and whose word is trusted by the masses? Like they did to a Belgian cryptographer? Was that fellow nerd a turrist of sorts? It may be possible that Segelmann did his job correctly, that the reviewer did his job correctly, but someone unknown may have changed it just a little bit before delivery. Besides funding projects like OpenSSL better, we should start considering the security of the repositories themselves. What ya fellow coders think?
On Fri, Apr 11, 2014 at 03:07:09PM +0200, tpb-crypto@laposte.net wrote:
Message du 11/04/14 05:44 De : dan@geer.org
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
If they did it, someone got a promotion. If they are as surprised as you are, someone got fired.
In the meantime, tell me that gcc is so compact and well vetted that there is no room in it for insertions...
This article makes an interesting point, we got to dig a bit more from our pockets:
http://www.wired.com/2014/04/heartbleedslesson/
The second point I wish to make is the surprise by which the original developer took the issue. Maybe, just maybe, he did not create that flaw at all.
It could have been inserted into the OpenSSL repository through a backdoor ... or why would the spies by so interested in hacking professors that deal with crypto and whose word is trusted by the masses? Like they did to a Belgian cryptographer? Was that fellow nerd a turrist of sorts?
It may be possible that Segelmann did his job correctly, that the reviewer did his job correctly, but someone unknown may have changed it just a little bit before delivery.
Besides funding projects like OpenSSL better, we should start considering the security of the repositories themselves.
What ya fellow coders think?
I certainly don't trust repositories ;) btw, I think this heartbleed story is exaggerated. If it were code execution it would have been much worse. browser vendors fix _a lot_ of "unspecified memory hazards" every few months. IMO getting owned by a browser bug is much more likely than by heartbleed. Is there a significant rise of revoked certs caused by HB paranoia?
Dnia piątek, 11 kwietnia 2014 16:32:44 Georgi Guninski pisze:
On Fri, Apr 11, 2014 at 03:07:09PM +0200, tpb-crypto@laposte.net wrote:
Message du 11/04/14 05:44 De : dan@geer.org
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
If they did it, someone got a promotion. If they are as surprised as you are, someone got fired.
In the meantime, tell me that gcc is so compact and well vetted that there is no room in it for insertions...
This article makes an interesting point, we got to dig a bit more from our pockets:
http://www.wired.com/2014/04/heartbleedslesson/
The second point I wish to make is the surprise by which the original developer took the issue. Maybe, just maybe, he did not create that flaw at all.
It could have been inserted into the OpenSSL repository through a backdoor ... or why would the spies by so interested in hacking professors that deal with crypto and whose word is trusted by the masses? Like they did to a Belgian cryptographer? Was that fellow nerd a turrist of sorts?
It may be possible that Segelmann did his job correctly, that the reviewer did his job correctly, but someone unknown may have changed it just a little bit before delivery.
Besides funding projects like OpenSSL better, we should start considering the security of the repositories themselves.
What ya fellow coders think?
I certainly don't trust repositories ;)
btw, I think this heartbleed story is exaggerated. If it were code execution it would have been much worse.
browser vendors fix _a lot_ of "unspecified memory hazards" every few months.
IMO getting owned by a browser bug is much more likely than by heartbleed.
How do you get owned by a browser bug on a server? I mean, HB is huge, because: - it affects servers; - potentially allows access to private keys and passwords; - this, in case of forward-secrecy-less setups allows the bad guys to decrypt all saved traffic. It's as bad as any root-level remote exploit on a server. And because, you know, "everybody uses OpenSSL", and because it was unknown but in the code for 2+ years, the attack surface was (and is) huge.
Is there a significant rise of revoked certs caused by HB paranoia?
No idea, but we're considering revoking ours. -- Pozdr rysiek
On Fri, Apr 11, 2014 at 04:43:03PM +0200, rysiek wrote:
How do you get owned by a browser bug on a server? I mean, HB is huge, because:
Own the admin or something like this (probably doesn't work for all admins, check the ACLU snowden docs for how NSA targets admins via browser bugs).
- it affects servers; - potentially allows access to private keys and passwords; - this, in case of forward-secrecy-less setups allows the bad guys to decrypt all saved traffic.
It's as bad as any root-level remote exploit on a server. And because, you
Disagree. AFAICT it doesn't affect openssh, only TLS. remote preauth openssh would be fun, though ;)
know, "everybody uses OpenSSL", and because it was unknown but in the code for 2+ years, the attack surface was (and is) huge.
Continue to believe that much more info is stolen via client bugs U buggy CMS/cgi + privilege escalation (see kernel changelogs).
Is there a significant rise of revoked certs caused by HB paranoia?
No idea, but we're considering revoking ours.
This is sound, suspect you are minority. Most people don't reinstall even after full ownage. -- cheers
On Fri, Apr 11, 2014 at 10:43 AM, rysiek <rysiek@hackerspace.pl> wrote:
Dnia piątek, 11 kwietnia 2014 16:32:44 Georgi Guninski pisze:
Is there a significant rise of revoked certs caused by HB paranoia?
No idea, but we're considering revoking ours.
As to ocsp/crl revocation, haven't looked (depending on application, getting the cert swapped out is more important anyway). But those of us who pin down certs instead of trusting CA's have been doing quite a bit of reconfiguring this week due to upstream certs being swapped out.
On Fri, Apr 11, 2014 at 07:02:53PM -0400, grarpamp wrote:
On Fri, Apr 11, 2014 at 10:43 AM, rysiek <rysiek@hackerspace.pl> wrote:
Dnia piątek, 11 kwietnia 2014 16:32:44 Georgi Guninski pisze:
Is there a significant rise of revoked certs caused by HB paranoia?
No idea, but we're considering revoking ours.
As to ocsp/crl revocation, haven't looked (depending on application, getting the cert swapped out is more important anyway). But those of us who pin down certs instead of trusting CA's have been doing quite a bit of reconfiguring this week due to upstream certs being swapped out.
Well, g00gle have strange cert policy: Issuer: C=US, O=Google Inc, CN=Google Internet Authority G2 Validity Not Before: Apr 2 16:00:48 2014 GMT Not After : Jul 1 00:00:00 2014 GMT The visible ASCII structure in the big cert almost sure comes from the ALT names :(
It'd be hard to hide an insertion if the devs all dig into the hashes of commits of their own local repos and compare, right? Even a broken hash would require changing input, so they could go an extra step and verify each commit using another hash algo, if they were feeling super-paranoid. I'm still on the fence: this is the kind of error C is infamous for after all. On 11 April 2014 14:07:09 GMT+01:00, tpb-crypto@laposte.net wrote:
Message du 11/04/14 05:44 De : dan@geer.org
It makes me wonder if the NSA was involved in inserting this bug into OpenSSL clients and servers.
If they did it, someone got a promotion. If they are as surprised as you are, someone got fired.
In the meantime, tell me that gcc is so compact and well vetted that there is no room in it for insertions...
This article makes an interesting point, we got to dig a bit more from our pockets:
http://www.wired.com/2014/04/heartbleedslesson/
The second point I wish to make is the surprise by which the original developer took the issue. Maybe, just maybe, he did not create that flaw at all.
It could have been inserted into the OpenSSL repository through a backdoor ... or why would the spies by so interested in hacking professors that deal with crypto and whose word is trusted by the masses? Like they did to a Belgian cryptographer? Was that fellow nerd a turrist of sorts?
It may be possible that Segelmann did his job correctly, that the reviewer did his job correctly, but someone unknown may have changed it just a little bit before delivery.
Besides funding projects like OpenSSL better, we should start considering the security of the repositories themselves.
What ya fellow coders think?
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Message du 11/04/14 15:38 De : "Cathal Garvey (Phone)"
It'd be hard to hide an insertion if the devs all dig into the hashes of commits of their own local repos and compare, right? Even a broken hash would require changing input, so they could go an extra step and verify each commit using another hash algo, if they were feeling super-paranoid.
I'm still on the fence: this is the kind of error C is infamous for after all.
Right, it is highly unlikely but not impossible, maybe the devs have copies and are digging through it. Which also won't exclude that Segelmann's PC itself was hacked in and the code modified after he e-mailed someone about having his job concluded and was delivering the goods. Considering that the tinfoilers were right all along during an entire decade, I'm also on the fence with this.
On Fri, Apr 11, 2014 at 9:37 AM, Cathal Garvey (Phone) <cathalgarvey@cathalgarvey.me> wrote:
It'd be hard to hide an insertion if the devs all dig into the hashes of commits of their own local repos and compare, right? Even a broken hash would require changing input, so they could go an extra step and verify each commit using another hash algo, if they were feeling super-paranoid.
The detection would often occur with a scrub type of routine maintenance check or automatically depending on the system. And unfortunately there are many critical repos that essentially refuse to move to a revcontrol system that employs signable hashes/merkle such that a cracked repo or even bitrot could be detected. Often out of such non claims [1] as workflow and effort to switch. FreeBSD is an example of such a key repo. http://www.git-scm.com/ http://www.git-scm.com/about/distributed [1] Considering potential the core-outwards architectural integrity benefits, among others.
This article makes an interesting point, we got to dig a bit more from our pockets:
http://www.wired.com/2014/04/heartbleedslesson/
The second point I wish to make is the surprise by which the original developer took the issue. Maybe, just maybe, he did not create that flaw at all.
It could have been inserted into the OpenSSL repository through a backdoor ... or why would the spies by so interested in hacking professors that deal with crypto and whose word is trusted by the masses? Like they did to a Belgian cryptographer? Was that fellow nerd a turrist of sorts?
It may be possible that Segelmann did his job correctly, that the reviewer did his job correctly, but someone unknown may have changed it just a little bit before delivery.
Besides funding projects like OpenSSL better, we should start considering the security of the repositories themselves.
What ya fellow coders think?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/11/2014 06:07 AM, tpb-crypto@laposte.net wrote:
It could have been inserted into the OpenSSL repository through a backdoor... or why would the spies by so interested in hacking professors that deal with crypto and whose word is trusted by the masses? Like they did to a Belgian
It may be possible that Segelmann did his job correctly, that the reviewer did his job correctly, but someone unknown may have changed it just a
For just that reason, perhaps? Because they're experts, the work and word of whom are trusted? That would be the first place I'd expect most people to look last. little bit
before delivery. What ya fellow coders think?
The timing of the commit in question is most interesting, indeed: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c508216... ...the date and time of the year when people are least likely to be sitting at their computers watching for and reviewing commits. Only better time would probably have been at 2359 hours UTC. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ WWPMD? (What Would Paul Muad'dib Do?) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREKAAYFAlNIIKYACgkQO9j/K4B7F8F3jwCgke6jqiBTm7DQrQrq7OyeEnD2 zEgAn155/V3TLOKjhlSI8X/gg65+gP84 =mCzP -----END PGP SIGNATURE-----
Dnia piątek, 11 kwietnia 2014 10:04:38 The Doctor pisze:
The timing of the commit in question is most interesting, indeed:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c508216 1b02a22116ad75f822b1
...the date and time of the year when people are least likely to be sitting at their computers watching for and reviewing commits. Only better time would probably have been at 2359 hours UTC.
Now I love my conspiracy theories just like the next guy and I definitely do not take sides (I am myself quite inclined to think this is not entirely an honest mistake), but... ...the kind of argument you make rings a bell: http://en.wikipedia.org/wiki/Anthropic_bias I agree that this was the very best time for a commit so that nobody sees it/reviews it. Maybe this is why nobody has seen it nor reviewed it? As in, the very fact it is so does not prove that it was done at this time on purpose. -- Pozdr rysiek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/11/2014 12:54 PM, rysiek wrote:
Dnia piątek, 11 kwietnia 2014 10:04:38 The Doctor pisze:
The timing of the commit in question is most interesting, indeed:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c508216
1b02a22116ad75f822b1
...the date and time of the year when people are least likely to be sitting at their computers watching for and reviewing commits. Only better time would probably have been at 2359 hours UTC.
Now I love my conspiracy theories just like the next guy and I definitely do not take sides (I am myself quite inclined to think this is not entirely an honest mistake), but...
...the kind of argument you make rings a bell: http://en.wikipedia.org/wiki/Anthropic_bias
I agree that this was the very best time for a commit so that nobody sees it/reviews it. Maybe this is why nobody has seen it nor reviewed it? As in, the very fact it is so does not prove that it was done at this time on purpose.
I agree that there is no proof that this bug was introduced on purpose and it might be a simple oversight (no matter what it looks like or could be). We have to keep in mind that one of the things spies do is sow suspicion and doubt - it's a powerful weapon! All these vulnerabilities we're finding in critical software /might just be/ mistakes and oversights. Or they might be deliberate attacks by the NSA/GCHQ. Part of the power these agencies wield is that /we'll likely never know/ and so we suspect...everyone. Everything. Cypher - -- Want to communicate with me privately? Find my PGP public key here: http://pgp.mit.edu/pks/lookup?op=get&search=0x5BAEB5B2FA26826B Fingerprint: 6728 40CE 35EE 0BF3 2E15 C7CC 5BAE B5B2 FA26 826B -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTSC4qAAoJEFuutbL6JoJrbIYQAJCMlCI7rpWZq/yUuVFZOmpW dO1QxMF1Gz0KA+MFBc5eiKzWsYbggY6jGfufiaWPDgV7fpmdirkz2enbEro6VFqN kOQded5v72g+cHDJjb4xcsK3J/k+RKeOxQxrNd8XeiqxGAqLlScDos+LGeOOee1f Dgefk/uQ1g/8O3sYz+uQhTyRWy+oEfSr1WUCvPYO1MiQcGt2BSC3S5RxMNKyj1XG so+pIKtrMJq842Rxl8OBJEAHpK7o4AnN9ealHpa6o+4nUR8C4WrN+T+rwnvpuZOI ujfWO6bEMfmGtNxOiZY3FfiJTLILrD4Ebiy28sJp6FkT53Kvvh7Bk4jdB5HJFSBh T4RzsOE5dEcGKIUrkA1W0Ct+SxZY167rFpKKzG4D95onN4EDHkZANm+bq24NxMf7 oB2rm6F1WCb5T2IRFzUiMln0brNGmp1jM9Y4jHRvc7Nsk+X9Xrq0lGoMKiWXqa2j XWQvgdQe3xPods/HRrEThHOJf9zg3YoxdeLmCJvUm459nHjiswOFSEobuYhbroFz Gx9fNyQxy2V2rCY8Yl7vE8qXp6L0S8pylZdeveyXrcKUc4jL3FOKYkEm5Exm9Rmg teI+NvbmUsO8AdEV3v70gvT6pjZr62gxWOjkbRX4LIHIq3eTZJ9+XyrVRGiLx+YU RNu3H/lUDe49yCmtd6O1 =8cIX -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/11/2014 11:02 AM, Cypher wrote:
I agree that there is no proof that this bug was introduced on purpose and it might be a simple oversight (no matter what it looks like or could be). We have to keep in mind that one of the things spies do is
I think it's safe to say that all of us have made mistakes that later came back to bite us. Not all of them were as critical as Heartbleed, but neither are any of us perfect. Additionally, a few folks are calling it the Tequila Hypothesis. Looking at it that way, the heartbeat feature really might have seemed like a good idea at the time (regardless of whether or not alcohol was actually involved).
NSA/GCHQ. Part of the power these agencies wield is that /we'll likely never know/ and so we suspect...everyone. Everything.
They do. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Look up! Look down! Now look at Mr. Frying Pan!" --George Newman, _UHF_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREKAAYFAlNIR1oACgkQO9j/K4B7F8FppwCgokjuzqzUOvp0JVkjn6z8qTUF REAAoKT8Q5uglU9nV9g9NyKaW031HIYv =t3qU -----END PGP SIGNATURE-----
Message du 11/04/14 20:33 De : "Cypher"
I agree that there is no proof that this bug was introduced on purpose and it might be a simple oversight (no matter what it looks like or could be). We have to keep in mind that one of the things spies do is sow suspicion and doubt - it's a powerful weapon! All these vulnerabilities we're finding in critical software /might just be/ mistakes and oversights. Or they might be deliberate attacks by the NSA/GCHQ. Part of the power these agencies wield is that /we'll likely never know/ and so we suspect...everyone. Everything.
Too many bugs, in too many convenient places. One or two may be a coincidence, several of them like it appears to be the case, is not. We know who did it and now even if it is a coincidence, the culprit will be pointed at the NSA. The timing the code was included in the tree cannot be a coincidence. There's one more thing we have to look at. When nobody is paying attention, someone is trying to sneak bad code. The NSA mandate was to protect the people, not to make them vulnerable. Disbanding such a rogue organization would be the right thing to do.
I don't buy into conspiracy theories often but I really can't see how you can fail to follow your own RFC. If he had a check in there to make sure the payload_length wasn't too large I would say "hey, he forgot to make sure it wasn't too small and he never even mentioned checking if it was too small that in the RFC"... but he actually never checked for anything.. so maybe it is just a mistake. He definitely failed to follow his own RFC which never mentioned making sure the length was correct, just that it wasn't too big, and that's something he never did. I don't get how the reviewer can miss it too, like it's code for an RFC the reviewer is COMPLETELY new to... so at first the code looks a bit mad until you read the RFC, then you realize right away that he's missing shit. Seems silly, i don't think the reviewer ever read the RFC. On Sat, 2014-04-12 at 02:48 +0200, tpb-crypto@laposte.net wrote:
Message du 11/04/14 20:33 De : "Cypher"
I agree that there is no proof that this bug was introduced on purpose and it might be a simple oversight (no matter what it looks like or could be). We have to keep in mind that one of the things spies do is sow suspicion and doubt - it's a powerful weapon! All these vulnerabilities we're finding in critical software /might just be/ mistakes and oversights. Or they might be deliberate attacks by the NSA/GCHQ. Part of the power these agencies wield is that /we'll likely never know/ and so we suspect...everyone. Everything.
Too many bugs, in too many convenient places. One or two may be a coincidence, several of them like it appears to be the case, is not. We know who did it and now even if it is a coincidence, the culprit will be pointed at the NSA.
The timing the code was included in the tree cannot be a coincidence. There's one more thing we have to look at. When nobody is paying attention, someone is trying to sneak bad code.
The NSA mandate was to protect the people, not to make them vulnerable. Disbanding such a rogue organization would be the right thing to do.
Message du 12/04/14 04:57 De : "Peter Malone"
A : tpb-crypto@laposte.net Copie à : "Cypher" , cypherpunks@cpunks.org Objet : Re: [tor-talk] [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
I don't buy into conspiracy theories often but I really can't see how you can fail to follow your own RFC. If he had a check in there to make sure the payload_length wasn't too large I would say "hey, he forgot to make sure it wasn't too small and he never even mentioned checking if it was too small that in the RFC"... but he actually never checked for anything.. so maybe it is just a mistake. He definitely failed to follow his own RFC which never mentioned making sure the length was correct, just that it wasn't too big, and that's something he never did.
I don't get how the reviewer can miss it too, like it's code for an RFC the reviewer is COMPLETELY new to... so at first the code looks a bit mad until you read the RFC, then you realize right away that he's missing shit. Seems silly, i don't think the reviewer ever read the RFC.
Look at the date and time the commit was done by the reviewer, make your own conclusions: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c508216...
Dnia sobota, 12 kwietnia 2014 06:06:36 tpb-crypto@laposte.net pisze:
Look at the date and time the commit was done by the reviewer, make your own conclusions:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c508216 1b02a22116ad75f822b1
If anybody is to be suspected of anything unsavoury here, it's the reviewer, I guess. -- Pozdr rysiek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/12/2014 01:47 AM, rysiek wrote:
If anybody is to be suspected of anything unsavoury here, it's the reviewer, I guess.
If there was a reviewer looking at it, that is. That'd be the right time of year for teams to accept commits without looking at them. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "All talk, no shock!" --Soundwave, _Transformers: the Movie_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREKAAYFAlNJbbQACgkQO9j/K4B7F8EjngCfSht7C8hKClYUwSY3QUeRfOs2 Xx0AniU6BrjuiHQaCfYW2kyjqE5lVwfj =xNyG -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/10/2014 08:15 PM, dan@geer.org wrote:
In the meantime, tell me that gcc is so compact and well vetted that there is no room in it for insertions...
Some interesting research has been done recently on this very topic that might be of interest to this particular mailing list. Oh, and cheers! - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ It's easier to get forgiveness for being wrong than forgiveness for being right. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREKAAYFAlNIHsYACgkQO9j/K4B7F8G0fACggcCn+ngLNoKWl4oOTYcAz46v VSYAni0ULpv7m2GBVwjbjGQl86x42YQP =gOJ/ -----END PGP SIGNATURE-----
participants (12)
-
Cathal Garvey -
Cathal Garvey (Phone)
-
Cypher -
dan＠geer.org -
Georgi Guninski -
grarpamp -
Juan Garofalo -
Patrick Chkoreff -
Peter Malone -
rysiek -
The Doctor -
tpb-crypto＠laposte.net