Re: [libgadu-devel] How to Report a Security Bug in libgadu
Hi Wojtek, Thank you for your response. Could you request a CVE for this ? On Fri, Sep 27, 2013 at 2:21 AM, Wojtek Kaniewski wojte...@toxygen.netwrote: Dnia 2013-09-19, czw o godzinie 19:40 +0530, Radhesh Krishnan K pisze: I couldn't follow up with this for long time. Is this bug fixed ? libgadu now rejects connection when certificate verification fails and gg_login_params.tls is set to GG_SSL_REQUIRED. When .tls is set to GG_SSL_ENABLED it just issues a warning, since then it allows even plain-text connections. CRL is supported only when the library handles it automatically (GnuTLS = 3.0), which is documented in README. New release is a matter of days. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel -- Regards, Radhesh Krishnan K. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-09-19, czw o godzinie 19:40 +0530, Radhesh Krishnan K pisze: I couldn't follow up with this for long time. Is this bug fixed ? libgadu now rejects connection when certificate verification fails and gg_login_params.tls is set to GG_SSL_REQUIRED. When .tls is set to GG_SSL_ENABLED it just issues a warning, since then it allows even plain-text connections. CRL is supported only when the library handles it automatically (GnuTLS = 3.0), which is documented in README. New release is a matter of days. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Hi, I couldn't follow up with this for long time. Is this bug fixed ? On Sun, Jun 16, 2013 at 10:52 PM, Wojtek Kaniewski wojte...@toxygen.netwrote: Dnia 2013-06-15, sob o godzinie 23:20 +0200, Bartosz Brachaczek pisze: Does this function also verify the host name? It seems that it doesn't but I'd like to be sure before I start looking into it. Yeah, you're right. It doesn't. So I did implement commonName verification with rudimentary support for wildcard domains. I did not dive into the subjectAltName verification though. Should we care? And BTW, do you know if OpenSSL and GnuTLS handle CRL automatically or should we provide and/or load some CRL file manually? Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel -- Regards, Radhesh Krishnan K. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-06-15, sob o godzinie 23:20 +0200, Bartosz Brachaczek pisze: Does this function also verify the host name? It seems that it doesn't but I'd like to be sure before I start looking into it. Yeah, you're right. It doesn't. So I did implement commonName verification with rudimentary support for wildcard domains. I did not dive into the subjectAltName verification though. Should we care? And BTW, do you know if OpenSSL and GnuTLS handle CRL automatically or should we provide and/or load some CRL file manually? Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-06-07, pią o godzinie 01:55 +0200, Bartosz Brachaczek pisze: So the functions of interest are: a) for OpenSSL: -- SSL_CTX_set_default_verify_paths() to use CA cert store configured during OpenSSL's build Does this function also verify the host name? It seems that it doesn't but I'd like to be sure before I start looking into it. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
2013/6/15 Wojtek Kaniewski wojte...@toxygen.net: Dnia 2013-06-07, pią o godzinie 01:55 +0200, Bartosz Brachaczek pisze: So the functions of interest are: a) for OpenSSL: -- SSL_CTX_set_default_verify_paths() to use CA cert store configured during OpenSSL's build Does this function also verify the host name? It seems that it doesn't but I'd like to be sure before I start looking into it. Yeah, you're right. It doesn't. --Bartosz ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
I think first option is better than the second one as it covers both possibilities. It gives the user an option to specify a CA trust store file to use and if not mentioned we can use the default. On Thu, Jun 13, 2013 at 4:08 AM, Bartosz Brachaczek b.brachac...@gmail.comwrote: 2013/6/12 Wojtek Kaniewski wojte...@toxygen.net: As Bartosz wrote the code for GnuTLS will be more complicated, so it may take some time. Do you have any plan for it? I have performed some research and the options seem to be to: 1) Have a build-time option to explicitly specify a CA trust store file to use, and if not specified, default to the first existing of: /etc/ssl/certs/ca-certificates.crt (Debian, Gentoo, Arch), /etc/pki/tls/cert.pem (Fedora), /etc/ssl/ca-bundle.pem (OpenSUSE), /usr/local/share/certs/ca-root-nss.crt (FreeBSD), /etc/ssl/cert.pem (OpenBSD) If specified, we could use the configured file and ignore system default altogether for both OpenSSL and GnuTLS. But if it was guessed, probably we should rather use OpenSSL's and GnuTLS's (in case of GnuTLS 3.0 or newer) default. 2) Another option would be to simply hard-code all these paths for GnuTLS older than 3.0 and not provide any build-time option at all. And as I'm thinking about that, it actually seems to be the best option to me. 3) For the sake of completeness: We could also require GnuTLS v3, but it's really a no-go because we should fix this issue in the 1.11 line and raising library requirements to something that even Debian 7.0 doesn't have is a very bad idea. What do you think? --Bartosz ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel -- Regards, Radhesh Krishnan K. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
2013/6/13 Bartosz Brachaczek b.brachac...@gmail.com 2013/6/12 Wojtek Kaniewski wojte...@toxygen.net: As Bartosz wrote the code for GnuTLS will be more complicated, so it may take some time. Do you have any plan for it? (...) I plan to copy and paste a part of GnuTLS' configure.ac. Take a look at https://gitorious.org/gnutls/gnutls/blobs/c59329a089a9ed108692066de95f533f482b5422/configure.acline 377. And if we detect GnuTLS 3.x we'll use appropriate function. Are you okay with such solution? Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
2013/6/13 Wojtek Kaniewski wojte...@toxygen.net: I plan to copy and paste a part of GnuTLS' configure.ac. Take a look at https://gitorious.org/gnutls/gnutls/blobs/c59329a089a9ed108692066de95f533f482b5422/configure.ac line 377. And if we detect GnuTLS 3.x we'll use appropriate function. Are you okay with such solution? I'm fine with it. --Bartosz ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-06-12, śro o godzinie 12:42 +0530, Radhesh Krishnan K pisze: I was wondering if there is any update on this ? I commited the verification code for OpenSSL version. As Bartosz wrote the code for GnuTLS will be more complicated, so it may take some time. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
2013/6/12 Wojtek Kaniewski wojte...@toxygen.net: As Bartosz wrote the code for GnuTLS will be more complicated, so it may take some time. Do you have any plan for it? I have performed some research and the options seem to be to: 1) Have a build-time option to explicitly specify a CA trust store file to use, and if not specified, default to the first existing of: /etc/ssl/certs/ca-certificates.crt (Debian, Gentoo, Arch), /etc/pki/tls/cert.pem (Fedora), /etc/ssl/ca-bundle.pem (OpenSUSE), /usr/local/share/certs/ca-root-nss.crt (FreeBSD), /etc/ssl/cert.pem (OpenBSD) If specified, we could use the configured file and ignore system default altogether for both OpenSSL and GnuTLS. But if it was guessed, probably we should rather use OpenSSL's and GnuTLS's (in case of GnuTLS 3.0 or newer) default. 2) Another option would be to simply hard-code all these paths for GnuTLS older than 3.0 and not provide any build-time option at all. And as I'm thinking about that, it actually seems to be the best option to me. 3) For the sake of completeness: We could also require GnuTLS v3, but it's really a no-go because we should fix this issue in the 1.11 line and raising library requirements to something that even Debian 7.0 doesn't have is a very bad idea. What do you think? --Bartosz ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Hi Bartosz, Adding Equifax Secure CA one to the list of trusted CA's sounds like a good idea to me. On Fri, Jun 7, 2013 at 5:25 AM, Bartosz Brachaczek b.brachac...@gmail.comwrote: (Reposting my conversation with Wojtek to the mailing list. I have just noticed we switched away from it). 2013/6/7 Bartosz Brachaczek b.brachac...@gmail.com: 2013/6/6 Wojtek Kaniewski wojte...@toxygen.net: Dnia 2013-06-04, wto o godzinie 13:37 +0200, Bartosz Brachaczek pisze: But checking which certificates are accepted by the proprietary client should be straightforward, as the current version of it is written in XUL and uses xulrunner's/gecko's methods of verifying certificates. I can volunteer to check this. If it turns out that the proprietary client trusts a CA that is not universally trusted, we might want to trust the same one when connecting to the Gadu-Gadu network in libgadu. Right now they use RapidSSL certificate issued by Equifax Secure Certificate Authority. I can see their certificate in my Ubuntu, so I guess it would be a matter of setting some flag to verify against preinstalled certificates, adding them to a list of trusted CA's or something similar. That's right, I have incorrectly assumed OpenSSL is using system CA cert store by default, and it's not the case. So the functions of interest are: a) for OpenSSL: -- SSL_CTX_set_default_verify_paths() to use CA cert store configured during OpenSSL's build -- SSL_get_verify_result() to retrieve certificate verification result b) for GnuTLS: -- gnutls_certificate_set_x509_system_trust() to use default system CA cert store, requires GnuTLS = 3.0 so it can be problematic (alternatively gnutls_certificate_set_x509_trust_file() can be used to point to specific files; in OpenSSL that would of course be possible, too) -- gnutls_certificate_verify_peers2() and gnutls_x509_crt_check_hostname() to verify the certificate validity As for rejecting invalid certificates, what do you think about leaving behaviour for GG_SSL_ENABLED as is, but adding a obligatory check in case of GG_SSL_REQUIRED? This way users would be still able to use SSL (on their own risk) if the CA changed to something obscure. I think it makes sense. Regards, Wojtek -- Regards, Radhesh Krishnan K. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
(Reposting my conversation with Wojtek to the mailing list. I have just noticed we switched away from it). 2013/6/7 Bartosz Brachaczek b.brachac...@gmail.com: 2013/6/6 Wojtek Kaniewski wojte...@toxygen.net: Dnia 2013-06-04, wto o godzinie 13:37 +0200, Bartosz Brachaczek pisze: But checking which certificates are accepted by the proprietary client should be straightforward, as the current version of it is written in XUL and uses xulrunner's/gecko's methods of verifying certificates. I can volunteer to check this. If it turns out that the proprietary client trusts a CA that is not universally trusted, we might want to trust the same one when connecting to the Gadu-Gadu network in libgadu. Right now they use RapidSSL certificate issued by Equifax Secure Certificate Authority. I can see their certificate in my Ubuntu, so I guess it would be a matter of setting some flag to verify against preinstalled certificates, adding them to a list of trusted CA's or something similar. That's right, I have incorrectly assumed OpenSSL is using system CA cert store by default, and it's not the case. So the functions of interest are: a) for OpenSSL: -- SSL_CTX_set_default_verify_paths() to use CA cert store configured during OpenSSL's build -- SSL_get_verify_result() to retrieve certificate verification result b) for GnuTLS: -- gnutls_certificate_set_x509_system_trust() to use default system CA cert store, requires GnuTLS = 3.0 so it can be problematic (alternatively gnutls_certificate_set_x509_trust_file() can be used to point to specific files; in OpenSSL that would of course be possible, too) -- gnutls_certificate_verify_peers2() and gnutls_x509_crt_check_hostname() to verify the certificate validity As for rejecting invalid certificates, what do you think about leaving behaviour for GG_SSL_ENABLED as is, but adding a obligatory check in case of GG_SSL_REQUIRED? This way users would be still able to use SSL (on their own risk) if the CA changed to something obscure. I think it makes sense. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Hi Wojtek, Sorry, I have a doubt. I would like to know how certificate validation is performed in the proprietary protocol and why something similar cannot be performed in this case? On Tue, Jun 4, 2013 at 4:41 AM, Wojtek Kaniewski wojte...@toxygen.netwrote: Dnia 2013-06-02, nie o godzinie 19:02 +0530, Radhesh Krishnan K pisze: I would like to report a security bug in libgadu. libgadu is using openSSL library for creating secure connections. (...) So the product using libgadu will be vulnerable to man-in-the-middle attack. It was rather a conscious decision. Since libgadu is a reverse-engineered implementation of a proprietary protocol, we have no control over the certificates used for SSL connections. We don't know which certificates will be accepted or rejected by the original client, so there is no reliable way to verify their validity in libgadu. But since you mentioned it, I guess we should at least add a note to the documentation. Regards, Wojtek -- Regards, Radhesh Krishnan K. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Hi, Simply using SSL_get_verify_result() is not a solution here, as it returns X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY when connecting to the proprietary servers on my system (I assume I am not being attacked, you might want to confirm it yourself). But checking which certificates are accepted by the proprietary client should be straightforward, as the current version of it is written in XUL and uses xulrunner's/gecko's methods of verifying certificates. I can volunteer to check this. If it turns out that the proprietary client trusts a CA that is not universally trusted, we might want to trust the same one when connecting to the Gadu-Gadu network in libgadu. Bartosz PS. I'm attaching a patch so you can easily check what does SSL_get_verify_result() return on your system. diff --git a/src/events.c b/src/events.c index 3f401e9..2cb104c 100644 --- a/src/events.c +++ b/src/events.c @@ -1145,6 +1145,10 @@ static gg_action_t gg_handle_tls_negotiation(struct gg_session *sess, struct gg_ X509_NAME_oneline(X509_get_issuer_name(peer), buf, sizeof(buf)); gg_debug_session(sess, GG_DEBUG_MISC, // cert issuer: %s\n, buf); + +long res = SSL_get_verify_result(GG_SESSION_OPENSSL(sess)); +if (res != X509_V_OK) +gg_debug_session(sess, GG_DEBUG_MISC, // WARNING! unable to verify peer certificate! res=%ld\n, res); } sess-state = next_state; 2013/6/4 Radhesh Krishnan K radheshkrishn...@gmail.com: Hi Wojtek, Sorry, I have a doubt. I would like to know how certificate validation is performed in the proprietary protocol and why something similar cannot be performed in this case? On Tue, Jun 4, 2013 at 4:41 AM, Wojtek Kaniewski wojte...@toxygen.net wrote: Dnia 2013-06-02, nie o godzinie 19:02 +0530, Radhesh Krishnan K pisze: I would like to report a security bug in libgadu. libgadu is using openSSL library for creating secure connections. (...) So the product using libgadu will be vulnerable to man-in-the-middle attack. It was rather a conscious decision. Since libgadu is a reverse-engineered implementation of a proprietary protocol, we have no control over the certificates used for SSL connections. We don't know which certificates will be accepted or rejected by the original client, so there is no reliable way to verify their validity in libgadu. But since you mentioned it, I guess we should at least add a note to the documentation. Regards, Wojtek -- Regards, Radhesh Krishnan K. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-06-02, nie o godzinie 19:02 +0530, Radhesh Krishnan K pisze: I would like to report a security bug in libgadu. libgadu is using openSSL library for creating secure connections. (...) So the product using libgadu will be vulnerable to man-in-the-middle attack. It was rather a conscious decision. Since libgadu is a reverse-engineered implementation of a proprietary protocol, we have no control over the certificates used for SSL connections. We don't know which certificates will be accepted or rejected by the original client, so there is no reliable way to verify their validity in libgadu. But since you mentioned it, I guess we should at least add a note to the documentation. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Hi, I would like to report a security bug in libgadu. libgadu is using openSSL library for creating secure connections. A program using openSSL can perform SSL handshake by invoking the SSL_connect function. Some cetrificate validation errors are signaled through , the return values of the SSL_connect, while for the others errors SSL_connect returns OK but sets internal verify result flags. Application must call ssl_get_verify_result function to check if any such errors occurred. This check is missing in libgadu. And thus a man-in-the-middle attack is possible failing all the SSL protection. (Please refer :- https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf) Another way to verify SSL certificate is using the api SSL_CTX_set_verify.The SSL_CTX_set_verify() API allows you to set the verification flags in the SSL_CTX structure and a callback function for customized verification as its third argument. (Setting NULL to the callback function means the built-in default verification function is used.) In the second argument of SSL_CTX_set_verify(), you can set the following macro (Please refer:- http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html) 1. SSL_VERIFY_NONE Server mode: the server will not send a client certificate request to the client, so the client will not send a certificate. Client mode: if not using an anonymous cipher (by default disabled), the server will send a certificate which will be checked. The result of the certificate verification process can be checked after the TLS/SSL handshake using the SSL_get_verify_result function. The handshake will be continued regardless of the verification result. 2. SSL_VERIFY_PEER 3. SSL_VERIFY_FAIL_IF_NO_PEER_CERT 4. SSL_VERIFY_CLIENT_ONCE However, In libgadu SSL_CTX_set_verify() API is used but the second parameter is SSL_VERIFY_NONE and third parameter is NULL, Which means we should use SSL_get_verify_result API to verify the peer certificate. But SSL_get_verify_result API is not used anywhere in libgadu code base which make the product vulnerable to man-in-the-middle attack. So the product using libgadu will be vulnerable to man-in-the-middle attack. On Sun, Jun 2, 2013 at 2:54 AM, Rafał Malinowski rafal.przemyslaw.malinow...@gmail.com wrote: Hello. Please use this mailing list to report bugs. Regards, Rafał Malinowski ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel -- Regards, Radhesh Krishnan K. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
