Re: [libgadu-devel] How to Report a Security Bug in libgadu

2013-09-27 Thread Radhesh Krishnan K
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

2013-09-26 Thread Wojtek Kaniewski
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

2013-09-19 Thread Radhesh Krishnan K
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

2013-06-16 Thread Wojtek Kaniewski
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

2013-06-15 Thread Wojtek Kaniewski
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-06-15 Thread Bartosz Brachaczek
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

2013-06-13 Thread Radhesh Krishnan K
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-06-13 Thread Wojtek Kaniewski
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-06-13 Thread Bartosz Brachaczek
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

2013-06-12 Thread Wojtek Kaniewski
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-06-12 Thread Bartosz Brachaczek
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

2013-06-07 Thread Radhesh Krishnan K
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

2013-06-06 Thread Bartosz Brachaczek
(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

2013-06-04 Thread Radhesh Krishnan K
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

2013-06-04 Thread Bartosz Brachaczek
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

2013-06-04 Thread Radhesh Krishnan K
Hi Bartosz,

First of all, thank you for volunteering to check this out.

If client trusts a CA which is not universally trusted, is it possible to
find that CA information within the client ? If yes we can use the same CA
to check the certificates, right ?


On Tue, Jun 4, 2013 at 5:07 PM, Bartosz Brachaczek
b.brachac...@gmail.comwrote:

 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




-- 




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-06-03 Thread Wojtek Kaniewski
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

2013-06-02 Thread Radhesh Krishnan K
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