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

2013-06-01 Thread Radhesh Krishnan K
Hi all,

I would like to know how to report a security bug in libgadu. I don't see
any option to report a  bug here http://toxygen.net/libgadu/.
http://toxygen.net/libgadu/


--.

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


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