Re: CVE-2009-3555 not addressed in OpenSSL
On Thursday 11 November 2010, Kurt Roeckx wrote: So I've prepared a package based on the ubuntu patch. I also went over every commit between the 0.9.8l and 0.9.8m release and am reasonly confident this patch should work properly. The current package is available at: http://people.debian.org/~kroeckx/openssl/rfc5746/ I would welcome people testing it. Note that it might still change based on feedback from people. It seems at least tor needs some patching to work with the updated openssl. [1] Peter, can you test that and prepare/test an updated package for Lenny if necessary, please? Thanks in advance. [1] http://archives.seul.org/or/cvs/Apr-2010/msg00214.html -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201011152226.27571...@sfritsch.de
Re: CVE-2009-3555 not addressed in OpenSSL
Hi Kurt, On Thursday 11 November 2010 19:43:33 Kurt Roeckx wrote: So I've prepared a package based on the ubuntu patch. I also went over every commit between the 0.9.8l and 0.9.8m release and am reasonly confident this patch should work properly. The current package is available at: http://people.debian.org/~kroeckx/openssl/rfc5746/ I would welcome people testing it. Note that it might still change based on feedback from people. I have tested it in some different environments with different types of configurations and the packages work very fine for me. In case someone else also wants to test them in an i386 context, the builds I used are here: http://people.debian.org/~thijs/openssl/ I hope we can see this update in the next point release. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: CVE-2009-3555 not addressed in OpenSSL
On Sat, 2010-11-13 at 18:14 +0100, Thijs Kinkhorst wrote: I have tested it in some different environments with different types of configurations and the packages work very fine for me. Just one question, did you test the patch or did you test the build? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289668905.4372.29.ca...@envygeeks.dev
Re: CVE-2009-3555 not addressed in OpenSSL
On Saturday 13 November 2010 18:21:45 Jordon Bedwell wrote: On Sat, 2010-11-13 at 18:14 +0100, Thijs Kinkhorst wrote: I have tested it in some different environments with different types of configurations and the packages work very fine for me. Just one question, did you test the patch or did you test the build? I'm not sure what the context of your question is, but I tested the amd64- built packages that Kurt provided and I have built i386 packages from Kurt's dsc that I also tested. Testing was both for some renegotiation-specific scenarios as well as some regular openssl usage. Hope this answers your question. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: CVE-2009-3555 not addressed in OpenSSL
On Fri, Oct 01, 2010 at 12:26:31AM +0200, Kurt Roeckx wrote: On Wed, Sep 29, 2010 at 02:13:37PM -0700, Kyle Bader wrote: Debian, being a volunteer organization, has it's upsides and downsides. The downside here being without an active volunteer interested in this problem, nothing has happened. What is needed here is someone to step up to the plate: file some bugs; try to find the patches; backport and test them; etc. Bottom line, a little work and communication with maintainers of the affected packages would go a long way toward resolving this. That was my initial goal in initiating this conversation. I provided a link to the patches already: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/jaunty/openssl/jaunty-proposed/revision/34 I seem to have missed that part in your original mail, and was not aware of anybody that tried to backport the changes. So I've prepared a package based on the ubuntu patch. I also went over every commit between the 0.9.8l and 0.9.8m release and am reasonly confident this patch should work properly. The current package is available at: http://people.debian.org/~kroeckx/openssl/rfc5746/ I would welcome people testing it. Note that it might still change based on feedback from people. Kurt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010184333.ga31...@roeckx.be
Re: CVE-2009-3555 not addressed in OpenSSL
* Simon Josefsson: FWIW, the latest stable GnuTLS version with RFC 5746 support is not even in testing, so it won't be part of even the next stable. What would be required to get a backport of RFC 5746 support into the current stable (considering that we do not want to incorporate too many unrelated changes)? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp6odnwf@mid.deneb.enyo.de
Re: CVE-2009-3555 not addressed in OpenSSL
Florian Weimer f...@deneb.enyo.de writes: * Simon Josefsson: FWIW, the latest stable GnuTLS version with RFC 5746 support is not even in testing, so it won't be part of even the next stable. What would be required to get a backport of RFC 5746 support into the current stable (considering that we do not want to incorporate too many unrelated changes)? Someone to move the changes from the 2.10.x branch back on to 2.8.x, and to make sure it is working properly. There are self tests to check that a backport is working: http://git.savannah.gnu.org/cgit/gnutls.git/tree/tests/safe-renegotiation The new API to query whether the extension is negotiated or not is also needed, but that shouldn't cause any problems as far as I can see. A binary using the new API wouldn't work with the original gnutls in stable, though, but I think that is an acceptable price? /Simon -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqv3g4e4@mocca.josefsson.org
Re: CVE-2009-3555 not addressed in OpenSSL
Marsh Ray ma...@extendedsubset.com writes: On 10/21/2010 06:40 AM, Simon Josefsson wrote: The new API to query whether the extension is negotiated or not is also needed, but that shouldn't cause any problems as far as I can see. A binary using the new API wouldn't work with the original gnutls in stable, though, but I think that is an acceptable price? Even if you didn't add the new API, the protocol-level functionality would be improved. So even if the decision to introduce a new API on an old interface represents a trade-off of risk vs functionality, it is not an argument against adding protocol support for RFC 5746 (which does not suggest the new API is needed for its implementation). Sure, agreed. I guess the API is mostly useful when testing that the backport is working properly, and once that has been confirmed, the API is no longer necessary. Perhaps the API is not strictly necessary in a backport since it is probably possible to extract from the debug log whether the extension was negotiated or not, if some application really wanted to know and be completely backwards compatible. OTOH, it is still not clear to me that backporting SRN would really solve any identifiable vulnerability since GnuTLS renegotiation works differently than OpenSSL/NSS. So it might be something for a point update rather than a security update, but I suppose that is up to the security team to decide. /Simon -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjzz3vkr@mocca.josefsson.org
Re: CVE-2009-3555 not addressed in OpenSSL
On Wed, Sep 29, 2010 at 02:13:37PM -0700, Kyle Bader wrote: Debian, being a volunteer organization, has it's upsides and downsides. The downside here being without an active volunteer interested in this problem, nothing has happened. What is needed here is someone to step up to the plate: file some bugs; try to find the patches; backport and test them; etc. Bottom line, a little work and communication with maintainers of the affected packages would go a long way toward resolving this. That was my initial goal in initiating this conversation. I provided a link to the patches already: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/jaunty/openssl/jaunty-proposed/revision/34 I seem to have missed that part in your original mail, and was not aware of anybody that tried to backport the changes. I installed the jaunty package on my lenny machines and the ff error console warning is gone: https://debian-lenny.badercom.net/ It appears to work but whenever a package as critical as openssl is modified it's important to have upstream take a look to make sure everything looks good. Ubuntu may or may not have done this, I haven't done the leg work to figure that out but it looks like that could be the next step. If I/we/whoever can verify this or gain the blessing of upstream would you consider updating the package Kurt if I also coordinate this with the Debian apache and nginx packagers? I think there are also other packages affected by this. This probably includes atleast tor. As I understand it they already have some complex code to deal with various versions, you probably want to have input from the maintainer if you want to fix this in stable. I will not have any time to look at this during the next month. If someone wants to put some time in this and upload this to proposed-updates and talk to the other maintainers so that this can all be prepared for a next stable update, I would be happy. Kurt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100930222631.ga3...@roeckx.be
Re: CVE-2009-3555 not addressed in OpenSSL
On mar., 2010-09-28 at 17:58 -0500, Jordon Bedwell wrote: On 09/28/2010 03:04 PM, Marsh Ray wrote: On 09/24/2010 02:45 AM, Simon Josefsson wrote: But that's a choice made by Debian. Call it release policy, procedure, or whatever, Debian cannot use the existence of its own bureaucracy as a justification for wrong action (or inaction). Microsoft has implemented the correct fix for this security bug, Debian has not implemented the correct fix for this security bug. It intrigues me to know that even with a new stable coming soon we still won't see a proper fix. With patches being available to vendors for so long I'm starting to wonder why it wasn't on the to-do list from the start as a /possible/ rerun and *must* fix on Squeeze. Well, who uses gnuTLS as the server anyway? Afaik the secure renegotiation was especially a problem in https case, and mod_gnutls isn't really widely used. The vast majority of people out there would use mod_ssl, and openssl support for rfc 5746 has been added in 0.9.8m (http://packages.debian.org/changelogs/pool/main/o/openssl/current/changelog) which is indeed in testing and will be part of squeeze. I'm not too sure the patch for renegotiation is straightforward to backport and include in a stable release. So yes, the situation could be better, but it doesn't look as bad as this thread seems to imply. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: CVE-2009-3555 not addressed in OpenSSL
Yves-Alexis Perez cor...@debian.org writes: On mar., 2010-09-28 at 17:58 -0500, Jordon Bedwell wrote: On 09/28/2010 03:04 PM, Marsh Ray wrote: On 09/24/2010 02:45 AM, Simon Josefsson wrote: But that's a choice made by Debian. Call it release policy, procedure, or whatever, Debian cannot use the existence of its own bureaucracy as a justification for wrong action (or inaction). Microsoft has implemented the correct fix for this security bug, Debian has not implemented the correct fix for this security bug. It intrigues me to know that even with a new stable coming soon we still won't see a proper fix. With patches being available to vendors for so long I'm starting to wonder why it wasn't on the to-do list from the start as a /possible/ rerun and *must* fix on Squeeze. Well, who uses gnuTLS as the server anyway? Exim uses GnuTLS, and at least in lenny it was the default MTA. However I looked at how Exim uses GnuTLS a long time ago, and it is not directly vulnerable. Almost all servers that were using GnuTLS was not vulnerable, because of how GnuTLS handles renegotiation. However by not supporting the new TLS extension, clients have no way of knowing whether the server is insecure or not. That is a problem, but it is borderline between a security problem and an interoperability problem. /Simon -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6akgvc3@mocca.josefsson.org
Re: CVE-2009-3555 not addressed in OpenSSL
Simon Josefsson si...@josefsson.org writes: Yves-Alexis Perez cor...@debian.org writes: Well, who uses gnuTLS as the server anyway? Exim uses GnuTLS, and at least in lenny it was the default MTA. However I looked at how Exim uses GnuTLS a long time ago, and it is not directly vulnerable. Almost all servers that were using GnuTLS was not vulnerable, because of how GnuTLS handles renegotiation. However by not supporting the new TLS extension, clients have no way of knowing whether the server is insecure or not. That is a problem, but it is borderline between a security problem and an interoperability problem. OpenLDAP in Debian also uses GnuTLS, but if I recall correctly, the OpenLDAP developers looked at this problem when it was first announced and concluded that LDAP as a protocol is not particularly vulnerable to the problem due to significant difficulties in encoding the required attack into what the LDAP protocol expects, and OpenLDAP in specific is not vulnerable for other reasons. See: http://www.openldap.org/lists/openldap-devel/200911/msg5.html -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v8cxp2a@windlord.stanford.edu
Re: CVE-2009-3555 not addressed in OpenSSL
On Tue, 28 Sep 2010 15:04:04 -0500, Marsh Ray wrote: On 09/24/2010 02:45 AM, Simon Josefsson wrote: Marsh Rayma...@extendedsubset.com writes: As a long-term Debian user myself, I appeal to Debian's sense of enlightened self-interest and urge that RFC 5746 support be backported to stable. FWIW, the latest stable GnuTLS version with RFC 5746 support is not even in testing, so it won't be part of even the next stable. It may be too late for that in the release cycle though... But that's a choice made by Debian. Call it release policy, procedure, or whatever, Debian cannot use the existence of its own bureaucracy as a justification for wrong action (or inaction). As you certainly know Simon, great effort has been expended by many people over the course of the last year to develop and deploy industry-wide a backwards-compatible protocol fix in record time. To this end, minor version updates and source patches to all major open-source implementations were provided to library users and distros. Under these circumstances, I contend that it is wrong for Debian to withhold these security fixes from its installed base. Web browsers are now warning users about unpatched servers. Server admins who run Debian are left without a packaged solution. Consequently, their users are unable to configure their client applications to strict (more secure) mode and client applications must ship with the less secure default settings. These facts remain: Opera has implemented the correct fix for this security bug, Microsoft has implemented the correct fix for this security bug, Mozilla has implemented the correct fix for this security bug, OpenSSL has implemented the correct fix for this security bug, IBM Java has implemented the correct fix for this security bug, GNUTLS has implemented the correct fix for this security bug, Google has implemented the correct fix for this security bug, RedHat has implemented the correct fix for this security bug, Ubuntu has implemented the correct fix for this security bug, ...yet... Debian has not implemented the correct fix for this security bug. Debian, being a volunteer organization, has it's upsides and downsides. The downside here being without an active volunteer interested in this problem, nothing has happened. What is needed here is someone to step up to the plate: file some bugs; try to find the patches; backport and test them; etc. Bottom line, a little work and communication with maintainers of the affected packages would go a long way toward resolving this. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100929165222.34d3e611.michael.s.gilb...@gmail.com
Re: CVE-2009-3555 not addressed in OpenSSL
On 09/29/2010 03:52 PM, Michael Gilbert wrote: On Tue, 28 Sep 2010 15:04:04 -0500, Marsh Ray wrote: On 09/24/2010 02:45 AM, Simon Josefsson wrote: Marsh Rayma...@extendedsubset.com writes: As a long-term Debian user myself, I appeal to Debian's sense of enlightened self-interest and urge that RFC 5746 support be backported to stable. FWIW, the latest stable GnuTLS version with RFC 5746 support is not even in testing, so it won't be part of even the next stable. It may be too late for that in the release cycle though... But that's a choice made by Debian. Call it release policy, procedure, or whatever, Debian cannot use the existence of its own bureaucracy as a justification for wrong action (or inaction). As you certainly know Simon, great effort has been expended by many people over the course of the last year to develop and deploy industry-wide a backwards-compatible protocol fix in record time. To this end, minor version updates and source patches to all major open-source implementations were provided to library users and distros. Under these circumstances, I contend that it is wrong for Debian to withhold these security fixes from its installed base. Web browsers are now warning users about unpatched servers. Server admins who run Debian are left without a packaged solution. Consequently, their users are unable to configure their client applications to strict (more secure) mode and client applications must ship with the less secure default settings. These facts remain: Opera has implemented the correct fix for this security bug, Microsoft has implemented the correct fix for this security bug, Mozilla has implemented the correct fix for this security bug, OpenSSL has implemented the correct fix for this security bug, IBM Java has implemented the correct fix for this security bug, GNUTLS has implemented the correct fix for this security bug, Google has implemented the correct fix for this security bug, RedHat has implemented the correct fix for this security bug, Ubuntu has implemented the correct fix for this security bug, ...yet... Debian has not implemented the correct fix for this security bug. Debian, being a volunteer organization, has it's upsides and downsides. The downside here being without an active volunteer interested in this problem, nothing has happened. What is needed here is someone to step up to the plate: file some bugs; try to find the patches; backport and test them; etc. Bottom line, a little work and communication with maintainers of the affected packages would go a long way toward resolving this. Best wishes, Mike There is a bug against openssl and mod_ssl for apache already they simply just block renegotiation (unless they did a better patch later that I don't recall seeing) and one was challenged (if I remember right openssl) because it was missing something. Personally I had assumed Debian of all people would be on the ball with this so I never double backed to check and see if they patched it properly but I remember everything just being block block block and not fix fix fix for real. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca3a852.8010...@envygeeks.com
Re: CVE-2009-3555 not addressed in OpenSSL
Debian, being a volunteer organization, has it's upsides and downsides. The downside here being without an active volunteer interested in this problem, nothing has happened. What is needed here is someone to step up to the plate: file some bugs; try to find the patches; backport and test them; etc. Bottom line, a little work and communication with maintainers of the affected packages would go a long way toward resolving this. That was my initial goal in initiating this conversation. I provided a link to the patches already: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/jaunty/openssl/jaunty-proposed/revision/34 I installed the jaunty package on my lenny machines and the ff error console warning is gone: https://debian-lenny.badercom.net/ It appears to work but whenever a package as critical as openssl is modified it's important to have upstream take a look to make sure everything looks good. Ubuntu may or may not have done this, I haven't done the leg work to figure that out but it looks like that could be the next step. If I/we/whoever can verify this or gain the blessing of upstream would you consider updating the package Kurt if I also coordinate this with the Debian apache and nginx packagers? -- Kyle -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikisdrz91bovr2_eebmhonyk+15prafbeun1...@mail.gmail.com
Re: CVE-2009-3555 not addressed in OpenSSL
On Wed, 29 Sep 2010 14:13:37 -0700, Kyle Bader wrote: Debian, being a volunteer organization, has it's upsides and downsides. The downside here being without an active volunteer interested in this problem, nothing has happened. What is needed here is someone to step up to the plate: file some bugs; try to find the patches; backport and test them; etc. Bottom line, a little work and communication with maintainers of the affected packages would go a long way toward resolving this. That was my initial goal in initiating this conversation. I provided a link to the patches already: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/jaunty/openssl/jaunty-proposed/revision/34 I installed the jaunty package on my lenny machines and the ff error console warning is gone: https://debian-lenny.badercom.net/ It appears to work but whenever a package as critical as openssl is modified it's important to have upstream take a look to make sure everything looks good. Ubuntu may or may not have done this, I haven't done the leg work to figure that out but it looks like that could be the next step. If I/we/whoever can verify this or gain the blessing of upstream would you consider updating the package Kurt if I also coordinate this with the Debian apache and nginx packagers? I could have sworn that renegotion in lenny's openssl was disabled. But according to the changelog, that looks to not be the case [0]. Based on that, I agree that a DSA should be issued. Mike [0] http://packages.debian.org/changelogs/pool/main/o/openssl/openssl_0.9.8g-15+lenny8/changelog -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100929172338.fe2db2e5.michael.s.gilb...@gmail.com
Re: CVE-2009-3555 not addressed in OpenSSL
On 09/29/2010 05:51 PM, Jordon Bedwell wrote: On 09/29/2010 04:23 PM, Michael Gilbert wrote: I could have sworn that renegotion in lenny's openssl was disabled. But according to the changelog, that looks to not be the case [0]. Based on that, I agree that a DSA should be issued. Even if renegotiation was disabled (which I briefly mentioned there was an issue with somebody challenging it in the original ticket) you can't seriously call that a fix more than a temporary damage control mechanism until a permanent fix comes. Part of what's so maddening about this bug is not that its so incredibly hard to patch, or that there are millions of sites using renegotiation, but that so often solutions which seem like a good idea at first turn out to be borderline and crummy in the broader picture. And it always takes a lot of discussion to work it out. For example, Apple quickly disabled renegotiation, they didn't know anybody was using it. Turns out it broke Tor, which needed it, but didn't happen to be insecure in they way they were using it. I think of it like this: SSL/TLS is a client-server protocol. Both endpoints have to work together to make the channel secure. It also has to be correctly interfaced to the application layer protocols running on top of it. We often have the picture in mind of the user shopping online and not wanting to have his credit card number intercepted in transit. This model has driven several design decisions of SSL/TLS and not always for the better. But really, from the protocol perspective, we have to expect that the client and server both have a critical interest in the security of their mutual connection. We can't assume that the client-side user is the only endpoint with secrets to protect. The server side shouldn't leaving it up to the client side to prevent a MitM (but PKI is a whole nother topic). We usually swift patch things out when we plan to work on a permanent fix, not disable a feature and call it a fixed when there is already a solution... Debian is usually really great. We knew that folks would disable renegotiation and we might have trouble getting it fix it correctly after that, since so few used it. If Debian's users don't need renegotiation, that's fine! It doesn't need to be turned back on! Most developers didn't know about this hidden feature anyway. That's not really the issue. All that we really need to move forward right now is: When a client sends a Client Hello containing an empty Renegotiation Info (RI) extension, the server replies with an empty RI extension of his own. It's just five fixed-value bytes that the server appends to his own Server Hello to acknowledge the client's request. This happens on the initial handshake and all in the SSL library itself. * It doesn't require that renegotiation be re-enabled. * Neither should it require changes to the application code (except conceivably to back out temporary patch or two). These five bytes will mean the world to some server admin somewhere, who's boss is questioning his judgment for installing Debian everywhere and now users are starting to report strange warnings in their browsers. - Marsh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca3e8a5.8000...@extendedsubset.com
Re: CVE-2009-3555 not addressed in OpenSSL
On Wed, 29 Sep 2010, Marsh Ray wrote: These five bytes will mean the world to some server admin somewhere, who's boss is questioning his judgment for installing Debian everywhere and now users are starting to report strange warnings in their browsers. Very well. Do we have something from OpenSSL upstream, stating that the patch is safe to apply to the OpenSSL version in Debian stable? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100930025527.ga23...@khazad-dum.debian.net
Re: CVE-2009-3555 not addressed in OpenSSL
Simon Josefsson si...@josefsson.org writes: Yves-Alexis Perez cor...@debian.org writes: Well, who uses gnuTLS as the server anyway? Exim uses GnuTLS, and at least in lenny it was the default MTA. However I looked at how Exim uses GnuTLS a long time ago, and it is not directly vulnerable. Almost all servers that were using GnuTLS was not vulnerable, because of how GnuTLS handles renegotiation. However by not supporting the new TLS extension, clients have no way of knowing whether the server is insecure or not. That is a problem, but it is borderline between a security problem and an interoperability problem. OpenLDAP in Debian also uses GnuTLS, but if I recall correctly, the OpenLDAP developers looked at this problem when it was first announced and concluded that LDAP as a protocol is not particularly vulnerable to the problem due to significant difficulties in encoding the required attack into what the LDAP protocol expects, and OpenLDAP in specific is not vulnerable for other reasons. See: http://www.openldap.org/lists/openldap-devel/200911/msg5.html -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v8cxp2a@windlord.stanford.edu -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/.4ca43...@fliegl.com
Re: CVE-2009-3555 not addressed in OpenSSL
Debian, being a volunteer organization, has it's upsides and downsides. The downside here being without an active volunteer interested in this problem, nothing has happened. What is needed here is someone to step up to the plate: file some bugs; try to find the patches; backport and test them; etc. Bottom line, a little work and communication with maintainers of the affected packages would go a long way toward resolving this. That was my initial goal in initiating this conversation. I provided a link to the patches already: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/jaunty/openssl/jaunty-proposed/revision/34 I installed the jaunty package on my lenny machines and the ff error console warning is gone: https://debian-lenny.badercom.net/ It appears to work but whenever a package as critical as openssl is modified it's important to have upstream take a look to make sure everything looks good. Ubuntu may or may not have done this, I haven't done the leg work to figure that out but it looks like that could be the next step. If I/we/whoever can verify this or gain the blessing of upstream would you consider updating the package Kurt if I also coordinate this with the Debian apache and nginx packagers? -- Kyle -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikisdrz91bovr2_eebmhonyk+15prafbeun1...@mail.gmail.com
Re: CVE-2009-3555 not addressed in OpenSSL
On Tue, 28 Sep 2010 15:04:04 -0500, Marsh Ray wrote: On 09/24/2010 02:45 AM, Simon Josefsson wrote: Marsh Rayma...@extendedsubset.com writes: As a long-term Debian user myself, I appeal to Debian's sense of enlightened self-interest and urge that RFC 5746 support be backported to stable. FWIW, the latest stable GnuTLS version with RFC 5746 support is not even in testing, so it won't be part of even the next stable. It may be too late for that in the release cycle though... But that's a choice made by Debian. Call it release policy, procedure, or whatever, Debian cannot use the existence of its own bureaucracy as a justification for wrong action (or inaction). As you certainly know Simon, great effort has been expended by many people over the course of the last year to develop and deploy industry-wide a backwards-compatible protocol fix in record time. To this end, minor version updates and source patches to all major open-source implementations were provided to library users and distros. Under these circumstances, I contend that it is wrong for Debian to withhold these security fixes from its installed base. Web browsers are now warning users about unpatched servers. Server admins who run Debian are left without a packaged solution. Consequently, their users are unable to configure their client applications to strict (more secure) mode and client applications must ship with the less secure default settings. These facts remain: Opera has implemented the correct fix for this security bug, Microsoft has implemented the correct fix for this security bug, Mozilla has implemented the correct fix for this security bug, OpenSSL has implemented the correct fix for this security bug, IBM Java has implemented the correct fix for this security bug, GNUTLS has implemented the correct fix for this security bug, Google has implemented the correct fix for this security bug, RedHat has implemented the correct fix for this security bug, Ubuntu has implemented the correct fix for this security bug, ...yet... Debian has not implemented the correct fix for this security bug. Debian, being a volunteer organization, has it's upsides and downsides. The downside here being without an active volunteer interested in this problem, nothing has happened. What is needed here is someone to step up to the plate: file some bugs; try to find the patches; backport and test them; etc. Bottom line, a little work and communication with maintainers of the affected packages would go a long way toward resolving this. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100929165222.34d3e611.michael.s.gilb...@gmail.com -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/.4ca43...@fliegl.com
Re: CVE-2009-3555 not addressed in OpenSSL
On 09/24/2010 02:45 AM, Simon Josefsson wrote: Marsh Rayma...@extendedsubset.com writes: As a long-term Debian user myself, I appeal to Debian's sense of enlightened self-interest and urge that RFC 5746 support be backported to stable. FWIW, the latest stable GnuTLS version with RFC 5746 support is not even in testing, so it won't be part of even the next stable. It may be too late for that in the release cycle though... But that's a choice made by Debian. Call it release policy, procedure, or whatever, Debian cannot use the existence of its own bureaucracy as a justification for wrong action (or inaction). As you certainly know Simon, great effort has been expended by many people over the course of the last year to develop and deploy industry-wide a backwards-compatible protocol fix in record time. To this end, minor version updates and source patches to all major open-source implementations were provided to library users and distros. Under these circumstances, I contend that it is wrong for Debian to withhold these security fixes from its installed base. Web browsers are now warning users about unpatched servers. Server admins who run Debian are left without a packaged solution. Consequently, their users are unable to configure their client applications to strict (more secure) mode and client applications must ship with the less secure default settings. These facts remain: Opera has implemented the correct fix for this security bug, Microsoft has implemented the correct fix for this security bug, Mozilla has implemented the correct fix for this security bug, OpenSSL has implemented the correct fix for this security bug, IBM Java has implemented the correct fix for this security bug, GNUTLS has implemented the correct fix for this security bug, Google has implemented the correct fix for this security bug, RedHat has implemented the correct fix for this security bug, Ubuntu has implemented the correct fix for this security bug, ...yet... Debian has not implemented the correct fix for this security bug. - Marsh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca24a34.5000...@extendedsubset.com
Re: CVE-2009-3555 not addressed in OpenSSL
On 09/28/2010 03:04 PM, Marsh Ray wrote: On 09/24/2010 02:45 AM, Simon Josefsson wrote: But that's a choice made by Debian. Call it release policy, procedure, or whatever, Debian cannot use the existence of its own bureaucracy as a justification for wrong action (or inaction). Microsoft has implemented the correct fix for this security bug, Debian has not implemented the correct fix for this security bug. It intrigues me to know that even with a new stable coming soon we still won't see a proper fix. With patches being available to vendors for so long I'm starting to wonder why it wasn't on the to-do list from the start as a /possible/ rerun and *must* fix on Squeeze. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca272fa.2060...@envygeeks.com
Re: CVE-2009-3555 not addressed in OpenSSL
Marsh Ray ma...@extendedsubset.com writes: As a long-term Debian user myself, I appeal to Debian's sense of enlightened self-interest and urge that RFC 5746 support be backported to stable. FWIW, the latest stable GnuTLS version with RFC 5746 support is not even in testing, so it won't be part of even the next stable. It may be too late for that in the release cycle though... /Simon -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk0z37qt@mocca.josefsson.org
Re: Re: CVE-2009-3555 not addressed in OpenSSL
Anyway, the proper fix would be to backport the RFC5746 changes. Yes. Now, what's the argument for not doing it properly? :-) But the other end will also require that support for it to work. Not long ago, this was a chicken-and-egg problem with the clients and servers. But at this point most other vendors have patched to add RFC 5746 support: https://bugzilla.redhat.com/show_bug.cgi?id=588181#c3 http://www.opera.com/docs/changelogs/windows/1050/ https://developer.mozilla.org/NSS_3.12.6_release_notes https://bugzilla.mozilla.org/show_bug.cgi?id=545755 http://code.google.com/p/chromium/issues/detail?id=38082#c9 http://www.microsoft.com/technet/security/bulletin/ms10-049.mspx http://support.microsoft.com/kb/980436 https://lists.ubuntu.com/archives/ubuntu-security-announce/2010-September/001164.html and so on... Debian is unfortunately lagging conspicuously here. Yes, behind MS. You're probably better off avoiding renegotiation. There are a couple of subtle limitations of this logic: * Some people need renegotiation. They aren't particularly many, and they aren't particularly vocal, but if you need it, you really need it. * There is absolutely no way for the client to tell if the server is performing an unsafe renegotiation at the time the client is expected to hand over his session cookie (and/or sign with his client cert). Unless, of course, he has successfully negotiated the use of RFC 5746 then can be confident that continuing the connection is safe. Eventually client apps will refuse to talk to servers that don't support RFC 5746 just as today they refuse to talk SSLv2. Browsers are starting to warn about it today: https://support.mozilla.com/en-US/questions/746438 By not supporting RFC 5746 on the server side, even if the server knows that it will never renegotiate, it prolongs for everyone the delay until clients can stop making potentially insecure connections. In this sense, it is a shared ecosystem problem. As a long-term Debian user myself, I appeal to Debian's sense of enlightened self-interest and urge that RFC 5746 support be backported to stable. Regards, - Marsh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9b95a7.9080...@extendedsubset.com
Re: Re: CVE-2009-3555 not addressed in OpenSSL
I saw the security tag on bug #555829, I meant that the package page should reflect the current security situation: http://packages.debian.org/lenny/openssl Shouldn't it show a [security] tag similar to: http://packages.debian.org/lenny/couchdb -- Kyle Bader -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100909103658.66781...@cerebrum
Re: Re: CVE-2009-3555 not addressed in OpenSSL
On Thu, Sep 09, 2010 at 10:36:58AM -0700, Kyle Bader wrote: I saw the security tag on bug #555829, I meant that the package page should reflect the current security situation: http://packages.debian.org/lenny/openssl Shouldn't it show a [security] tag similar to: http://packages.debian.org/lenny/couchdb As far as I can tell, that means that the version it's telling you about is part of the security archive and not yet part of a stable release. Kurt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100909175719.ga20...@roeckx.be
Re: Re: Re: CVE-2009-3555 not addressed in OpenSSL
I saw the security tag on bug #555829, I meant that the package page should reflect the current security situation: http://packages.debian.org/lenny/openssl Shouldn't it show a [security] tag similar to: http://packages.debian.org/lenny/couchdb As far as I can tell, that means that the version it's telling you about is part of the security archive and not yet part of a stable release. Yes, that does seem to be the case. I was wrongfully under the impression that there was an easy way to see the security status of a package from that page. -- Kyle Bader -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100909112659.42303...@cerebrum
CVE-2009-3555 not addressed in OpenSSL
Hello Deb-sec! I'd like to bring to the attention of the developers and the Debian community that CVE-2009-3555 has not been completely addressed in Debian/stable as we are meant to believe here: http://security-tracker.debian.org/tracker/CVE-2009-3555 The apache nginx fixes paper over the issue without addressing the underlying problem, a protocol vulnerability in the openssl library. In my opinion the openssl package should be marked with a security tag, as it is for Ubuntu and Debian bug #555829 should be re-opened. Debian package: http://packages.debian.org/lenny/openssl Ubuntu package: http://packages.ubuntu.com/jaunty/openssl Debian Bug Report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555829 After verification from upstream this patch series looks like the proper way to address the protocol vulnerability: Ubuntu proposed fix: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/jaunty/openssl/jaunty-proposed/revision/34 To demonstrate this issue you can goto my example site, Debian/stable (lenny), openssl (0.9.8g-15+lenny8) custom apache (2.2.16): https://debian-lenny.badercom.net With a recent Firefox build you will notice this in the error console: debian-lenny.badercom.net : server does not support RFC 5746, see CVE-2009-3555 Example site where protocol vulnerability is addressed, Debian/testing (squeeze), openssl (0.9.8o-2) custom apache (2.2.16): https://debian-squeeze.badercom.net Thanks, -- Kyle Bader -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinpvwvmhtx2v0coj0tbfvngxxtp7aarygaqj...@mail.gmail.com
Re: CVE-2009-3555 not addressed in OpenSSL
On Wed, Sep 08, 2010 at 10:20:11AM -0700, Kyle Bader wrote: Hello Deb-sec! I'd like to bring to the attention of the developers and the Debian community that CVE-2009-3555 has not been completely addressed in Debian/stable as we are meant to believe here: http://security-tracker.debian.org/tracker/CVE-2009-3555 The apache nginx fixes paper over the issue without addressing the underlying problem, a protocol vulnerability in the openssl library. In my opinion the openssl package should be marked with a security tag, as it is for Ubuntu and Debian bug #555829 should be re-opened. Bug #555829 is still listed as affecting stable and has a security tag. I've now also marked it properly with version numbers, but it really doesn't change anything other than saying that testing/unstable was also affected at some point in the past. Anyway, the proper fix would be to backport the RFC5746 changes. But the other end will also require that support for it to work. You're probably better off avoiding renegotiation. Kurt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908214111.ga13...@roeckx.be
