[Bug 1380038] [NEW] SSL problems: doesn't check certificate chain and hostname when ssl connecting
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in pacemaker, the following is details: 1. file : /pacemaker-1.1.6/lib/common/remote.c problem : Certificate chain verification is missing 2. file : /pacemaker-1.1.6/lib/common/remote.c problem : Hostname verification is missing More specifically , we can take hostname check for example, the function verify_certificate() can only guarantee the validity of the certificate but cannot guarantee that the host you are trying to connect is the one you intend to visit, which may lead to man-in-the-middle attack or other security issues. And other APIs have similar problems. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, my email : rainkin1...@gmail.com Thanks. ** Affects: pacemaker (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1380038 Title: SSL problems: doesn't check certificate chain and hostname when ssl connecting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1380038/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1376592] [NEW] X509 certificate verification problem
Public bug reported: Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. We believe that freetds-bin didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate. We found the vulnerability by static analysis, typically, a process of verification involves calling a chain of API, and we can deduce whether the communication process is vulnerable by detecting whether the function call process matches a certain model. For example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate. If the source code does not match this model, then we can deduce this code is vulnerable. What’ more , Gnutls is the same as Openssl. To verify the result: 一.Hostname verification: 1. configure the file freetds.conf : # A typical Microsoft server [sqlserver2000] host = hackbyfun.sqlserver.com port = 1433 tds version = 8.0 encrpytion = require 2.wirte the file /etc/hosts in order to simulate DNS hijack: 10.214.146.123 hackbyfun.sqlserver.com (PS: 10.214.146.123 is a normal sql server ip, its domain name is safe.sqlserver.com ) 3.connect with freetds-bin tsql -S sqlserver2000 -U sa -P your password 4.result：connect succeed!! The fetch succeeded, indicating freetds-bin didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. the same as the above process. Run freetds-bin to connect a normal sql server 3. result :connect succeed!! The fetch succeeded again and no warning was given, indicating freetds- bin didn't check whether the certificate expired or not. (PS: I have saved the wireshark packages, and upload these files) I am running freetds-bin 9.1-5 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. ** Affects: freetds (Ubuntu) Importance: Undecided Status: New ** Tags: ssl ** Attachment added: wireshark ssl conneting packages https://bugs.launchpad.net/bugs/1376592/+attachment/4222110/+files/freetds.zip ** Information type changed from Private Security to Public ** Description changed: Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. We believe that freetds-bin didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate. We found the vulnerability by static analysis, typically, a process of verification involves calling a chain of API, and we can deduce whether the communication process is vulnerable by detecting whether the function call process matches a certain model. For example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate. If the source code does not match this model, then we can deduce this code is vulnerable. What’ more , Gnutls is the same as Openssl. To verify the result: 一.Hostname verification: 1. configure the file freetds.conf : -# A typical Microsoft server + # A typical Microsoft server [sqlserver2000] - host = hackbyfun.sqlserver.com - port = 1433 - tds version = 8.0 - encrpytion = require + host = hackbyfun.sqlserver.com + port = 1433 + tds version = 8.0 + encrpytion = require 2.wirte the file /etc/hosts in order to simulate DNS hijack: - 10.214.146.123 hackbyfun.sqlserver.com - (PS: 10.214.146.123 is a normal sql server ip, its domain name is safe.sqlserver.com ) + 10.214.146.123 hackbyfun.sqlserver.com + (PS: 10.214.146.123 is a normal sql server ip, its domain name is safe.sqlserver.com ) 3.connect with freetds-bin tsql -S sqlserver2000 -U sa -P your password - result：connect succeed!! + 4.result：connect succeed!! + The fetch succeeded, indicating freetds-bin didn't check the hostname + against the signee of the certificate. - The fetch succeeded, indicating freetds-bin didn't check the hostname against the signee of the certificate. - - Also for expired time check, + 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. the same as the above process. Run freetds-bin to connect a normal sql server 3.
[Bug 1376595] [NEW] X509 certificate verification problem
Public bug reported: Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. We believe that scrollz didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate. We found the vulnerability by static analysis, typically, a process of verification involves calling a chain of API, and we can deduce whether the communication process is vulnerable by detecting whether the function call process matches a certain model. For example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate. If the source code does not match this model, then we can deduce this code is vulnerable. What’ more , Gnutls is the same as Openssl. Static analysis result : /scrollz-2.1/source/server.c login_to_server() have problems. We provide this result to help developers to locate the problem faster. To verify the result: 一.Hostname verification 1. write the file /etc/hosts in order to simulate DNS hijack: 64.32.24.176irc.mibbit.net 46.137.23.30chat.freenode.net (PS：exchange the ip between these two irc servers) 2. connecting chat.freenode.net with scrollz /server -ssl irc.mibbit.net:6697 3. result : we connected irc.mibbit.net!! The fetch succeeded, indicating srcollz didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run scrollz to connect a normal irc server, such as irc.mibbit.net(46.137.12.30) 3. result : connect succeed!! The fetch succeeded again and no warning was given, indicating scrollz didn't check whether the certificate expired or not. I am running scrollz 2.1-1.1 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. ** Affects: scrollz (Ubuntu) Importance: Undecided Status: New ** Tags: ssl ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1376595 Title: X509 certificate verification problem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/scrollz/+bug/1376595/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1376601] [NEW] X509 certificate verification problem
Public bug reported: Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. We believe that xfce4-mailwatch-plugin didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate. We found the vulnerability by static analysis, typically, a process of verification involves calling a chain of API, and we can deduce whether the communication process is vulnerable by detecting whether the function call process matches a certain model. For example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate. If the source code does not match this model, then we can deduce this code is vulnerable. What’ more , Gnutls is the same as Openssl. The static analysis result: /xfce4-mailwatch-plugin-1.1.0/libmailwatch-core/mailwatch-net-conn.c xfce_mailwatch_net_conn_make_secure() We provide this result to help developers to locate the problem faster. To verify the result: 一. Hostname verification: 1.configure xface4-mailwatch-plugin: IMAP(SSL) :imap.163.com Username : 598105904 Password : Your password Advanced: Use SSL/TLS on alternate port 2. change /etc/hosts in order to simulate the DNS hijack 113.108.16.116 imap.163.com （113.108.16.116 is QQ’s imap server） 3. run xfce4-mailwatch-plugin to fetch the mail 4. result : succeed!!! The fetch succeeded, indicating xface4-mailwatch-plugin didn't check the hostname against the signee of the certificate. 二．Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run xfce4-mailwatch-plugin to fetch the mail. 3. result:succeed!! The fetch succeeded again and no warning was given, indicating xface4 -mailwatch-plugin didn't check whether the certificate expired or not. I am running xfce4-mailwatch-plugin 1.2.0-1 in ubuntu 14.04 LTS. (PS: I have saved the wireshark ssl connecting packages and upload these files.) for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. ** Affects: xfce4-mailwatch-plugin (Ubuntu) Importance: Undecided Status: New ** Tags: ssl ** Attachment added: wireshark ssl conneting packages https://bugs.launchpad.net/bugs/1376601/+attachment/4222132/+files/xfce4-mailwatch-plugin.zip ** Information type changed from Private Security to Public ** Description changed: Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. We believe that xfce4-mailwatch-plugin didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate. We found the vulnerability by static analysis, typically, a process of verification involves calling a chain of API, and we can deduce whether the communication process is vulnerable by detecting whether the function call process matches a certain model. For example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate. If the source code does not match this model, then we can deduce this code is vulnerable. What’ more , Gnutls is the same as Openssl. The static analysis result: /xfce4-mailwatch-plugin-1.1.0/libmailwatch-core/mailwatch-net-conn.c xfce_mailwatch_net_conn_make_secure() We provide this result to help developers to locate the problem faster. To verify the result: 一. Hostname verification: 1.configure xface4-mailwatch-plugin: IMAP(SSL) :imap.163.com Username : 598105904 Password : Your password Advanced: Use SSL/TLS on alternate port 2. change /etc/hosts in order to simulate the DNS hijack - 113.108.16.116imap.163.com -（113.108.16.116 is QQ’s imap server） + 113.108.16.116imap.163.com + （113.108.16.116 is QQ’s imap server） 3. run xfce4-mailwatch-plugin to fetch the mail 4. result : succeed!!! The fetch succeeded, indicating xface4-mailwatch-plugin didn't check the hostname against the signee of the certificate. 二．Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run xfce4-mailwatch-plugin to fetch the mail. - 3. result:succeed!! The fetch succeeded again and no warning was given, indicating xface4 -mailwatch-plugin didn't check whether the certificate expired or not. I am running
[Bug 1381936] [NEW] SSL connection is not secure in links
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in links: 1. miss hostname check when verify x509 certificate 2. miss expired time check when verify x509 certificate More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. To verify the result we make, we prove the vulnerability manually. Result ：we can browse any website with invalid certificate and we won’t get any warnings. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Affects: links2 (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1381936 Title: SSL connection is not secure in links To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/links2/+bug/1381936/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1381940] [NEW] suck have ssl security problems
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in suck: 1. miss hostname check when verify x509 certificate 2. miss expired time check when verify x509 certificate More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. To verify the result we make, we prove the vulnerability manually. Result ：we can connect to any server with invalid certificate and we won’t get any warnings. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Affects: suck (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1381940 Title: suck have ssl security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/suck/+bug/1381940/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1381936] Re: SSL connection is not secure in links
I am very glad to receive your responce. We test links in Ubuntu 12.04. thanks, rainkin -- 原始邮件 -- 发件人: Axel Beckert;a...@debian.org; 发送时间: 2014年10月18日(星期六) 凌晨2:51 收件人: rainkin598105...@qq.com; 主题: [Bug 1381936] Re: SSL connection is not secure in links Please also state which version of links (or alternatively which version of Ubuntu) you checked. -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/1381936 Title: SSL connection is not secure in links Status in “links2” package in Ubuntu: Incomplete Bug description: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in links: 1. miss hostname check when verify x509 certificate 2. miss expired time check when verify x509 certificate More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. To verify the result we make, we prove the vulnerability manually. Result ：we can browse any website with invalid certificate and we won’t get any warnings. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/links2/+bug/1381936/+subscriptions ** Description changed: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in links: 1. miss hostname check when verify x509 certificate 2. miss expired time check when verify x509 certificate More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. To verify the result we make, we prove the vulnerability manually. - Result ：we can browse any website with invalid certificate and we won’t get any warnings. + Result ：we can browse any website with invalid certificate and we won’t get any warnings. PS: + We test links in Ubunut 12.04. for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1381936 Title: SSL connection is not secure in links To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/links2/+bug/1381936/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380298] Re: some SSL security problems
** Description changed:
- Recently, we are trying to find SSL security problems by static
- analysis. For example, as we all know, Hostname verification is an
- important step when verifying X509 certificates, however, people tend to
- miss the step or to misunderstand the APIs when using SSL/TLS, which
- might cause severe man in the middle attack and break the entire TLS
- mechanism. And static analysis is a way of finding whether the APIs are
- called correctly.
+ Recently, our group is trying to find SSL security problems by static
+ analysis. When using Openssl, people tend to miss the step or to
+ misunderstand the APIs when using SSL/TLS, which might cause severe man
+ in the middle attack and break the entire TLS mechanism. And static
+ analysis is a way of finding whether the APIs are called correctly.
+
+ Now we just check whether a software verify the certitiface chain when
+ using Openssl.
+
+ 一. How we ensure whether a software check the certificate chain or not?
+ We make a matching algorithm. If source code doesn't match this, the software
is not secure.
+
+ Typically, when Openssl clients want to verify a certificate, there are
+ the following choices:
+
+ 1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
+ [Example 1]
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+
+ [Example 2]
+
+ //check the built-in verification result after the SSL handshake
+
+ if( SSL_get_peer_certificate(ssl)!=NULL
+
+ SSL_get_verify_result(ssl)==X509_V_OK)
+ {
+//PASS
+ }
+ else
+ {
+
+//FAIL
+ }
+
+ 2. Using custom verification.
+
+ [Example 3]
+ X509* usrcert = SSL_get_peer_certificate(ssl);
+ rootCertStore = X509_STORE_new();
+ ....
+ ctx = X509_STORE_CTX_new();
+ ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
+ ret = X509_verify_cert(ctx)
+
+ This example read the certificate out using SSL_get_peer_certificate
+ API. Then it use X509 API suite to do certificate verification. X509 API
+ is part of OPENSSL library. Theoretically, a developer can use any API
+ in any libraries to do this verification, but in practice, we only
+ identify the case above: using X509 API suite.
+
+
+ 3. Add restrictions or relaxations to built-in certificate verification
+
+ The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
+ By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
+
+ [Example 4]
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
+ static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
+ {
+
+
+ return preverify_ok;
+ }
+
+
+ 二. The analysis result
Now, we find some SSL problems in crtmpserver, the following is details:
-
file : crtmpserver-apps/crtmpserver-1.0~dfsg/thelib/src/protocols/ssl
/outboundsslprotocol.cpp
-
function : OutboundSSLProtocol::DoHandshake()
-
SSL method : \
-
SSL_CTX_set_verify() argument :SSL_VERIFY_NONE
-
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-
call SSL_get_peer_certificate():NO
-
call SSL_get_verify_result(): NO
-
- According to the above result, we think the SSL connection in
- crtmpserver is not secure.
+ According to the above result, we think crtmpserver doesn't check the
+ certificate chain when using OPENSSL.
- More specifically , we can take function SSL_CTX_set_verify() for
- example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx,
- SSL_VERIFY_NONE, null), we should verify the certificate by calling the
- function SSL_get_peer_certificate() to get the certificate. If the
- source code does not match this model, then we can deduce this code is
- vulnerable. And other APIs have similar problems.
PS: for
[Bug 1380304] Re: perdition have some SSL security problems
** Description changed:
- Recently, we are trying to find SSL security problems by static
- analysis. For example, as we all know, Hostname verification is an
- important step when verifying X509 certificates, however, people tend to
- miss the step or to misunderstand the APIs when using SSL/TLS, which
- might cause severe man in the middle attack and break the entire TLS
- mechanism. And static analysis is a way of finding whether the APIs are
- called correctly.
+ Recently, our group is trying to find SSL security problems by static
+ analysis. When using Openssl, people tend to miss the step or to
+ misunderstand the APIs when using SSL/TLS, which might cause severe man
+ in the middle attack and break the entire TLS mechanism. And static
+ analysis is a way of finding whether the APIs are called correctly.
+
+ Now we just check whether a software verify the certitiface chain when
+ using Openssl.
+
+ 一. How we ensure whether a software check the certificate chain or not?
+ We make a matching algorithm. If source code doesn't match this, the software
is not secure.
+
+ Typically, when Openssl clients want to verify a certificate, there are
+ the following choices:
+
+ 1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
+ [Example 1]
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+
+ [Example 2]
+
+ //check the built-in verification result after the SSL handshake
+
+ if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
+ {
+//PASS
+ }
+ else
+ {
+ //FAIL
+ }
+
+ 2. Using custom verification.
+
+ [Example 3]
+ X509* usrcert = SSL_get_peer_certificate(ssl);
+ rootCertStore = X509_STORE_new();
+ .. ..
+ ctx = X509_STORE_CTX_new();
+ ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
+ ret = X509_verify_cert(ctx)
+
+ This example read the certificate out using SSL_get_peer_certificate
+ API. Then it use X509 API suite to do certificate verification. X509 API
+ is part of OPENSSL library. Theoretically, a developer can use any API
+ in any libraries to do this verification, but in practice, we only
+ identify the case above: using X509 API suite.
+
+ 3. Add restrictions or relaxations to built-in certificate verification
+
+ The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
+ By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
+
+ [Example 4]
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
+ static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
+ {
+
+
+ return preverify_ok;
+ }
+
+ 二. The analysis result
Now, we find some SSL problems in perdition, the following is details:
-
file : perdition/perdition-1.19~rc4/perdition/ssl.c
-
function : __perdition_ssl_connection
-
SSL method : SSLv23
-
SSL_CTX_set_verify() argument : SSL_VERIFY_PEER
-
Have SSL_CTX_set_verify ( SSL_set_verify) callback : YES (but accept
self-signed certificate expired certificate)
-
call SSL_get_peer_certificate(): NO
-
call SSL_get_verify_result(): NO
-
According to the above result, we think the SSL connection in perdition
is not secure .perdition can accept self-signed certificate
certificate, which means MITM attack is possible.
PS: for more information, you can see the paper:
http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your
responce.
Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1380304
Title:
perdition have some SSL security problems
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/perdition/+bug/1380304/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380435] Re: epic5's SSL connection is not secure
** Description changed:
- Recently, we are trying to find SSL security problems by static
- analysis. For example, as we all know, Hostname verification is an
- important step when verifying X509 certificates, however, people tend to
- miss the step or to misunderstand the APIs when using SSL/TLS, which
- might cause severe man in the middle attack and break the entire TLS
- mechanism. And static analysis is a way of finding whether the APIs are
- called correctly.
+ Recently, our group is trying to find SSL security problems by static
+ analysis. When using Openssl, people tend to miss the step or to
+ misunderstand the APIs when using SSL/TLS, which might cause severe man
+ in the middle attack and break the entire TLS mechanism. And static
+ analysis is a way of finding whether the APIs are called correctly.
+
+ Now we just check whether a software verify the certitiface chain when
+ using Openssl.
+
+ 一. How we ensure whether a software check the certificate chain or not?
+ We make a matching algorithm. If source code doesn't match this, the software
is not secure.
+
+ Typically, when Openssl clients want to verify a certificate, there are
+ the following choices:
+
+ 1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
+ [Example 1]
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+
+ [Example 2]
+
+ //check the built-in verification result after the SSL handshake
+
+ if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
+ {
+//PASS
+ }
+ else
+ {
+ //FAIL
+ }
+
+ 2. Using custom verification.
+
+ [Example 3]
+ X509* usrcert = SSL_get_peer_certificate(ssl);
+ rootCertStore = X509_STORE_new();
+ .. ..
+ ctx = X509_STORE_CTX_new();
+ ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
+ ret = X509_verify_cert(ctx)
+
+ This example read the certificate out using SSL_get_peer_certificate
+ API. Then it use X509 API suite to do certificate verification. X509 API
+ is part of OPENSSL library. Theoretically, a developer can use any API
+ in any libraries to do this verification, but in practice, we only
+ identify the case above: using X509 API suite.
+
+ 3. Add restrictions or relaxations to built-in certificate verification
+
+ The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
+ By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
+
+ [Example 4]
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
+ static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
+ {
+
+
+ return preverify_ok;
+ }
+
+ 二. The analysis result
Now, we find some SSL problems in epic5, the following is details:
-
file : epic5/epic5-1.1.2/source/ssl.c
-
function : ssl_connect
-
SSL method : \
-
call SSL_CTX_set_verify() : NOT FOUND
-
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-
call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom
verification)
-
call SSL_get_verify_result(): NO
-
According to the above result, we think the SSL connection in epic5 is
not secure.
- More specifically , we can take function SSL_CTX_set_verify() for
- example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx,
- SSL_VERIFY_NONE, null), we should verify the certificate by calling the
- function SSL_get_peer_certificate() to get the certificate at first.
- Then use X509 APIs or self-define function to verify the certificate we
- get. If the source code does not match this model, then we can deduce
- this code is vulnerable. And other APIs have similar problems.
+ 三. How we prove the result we got.
To verify the result we make, we attack the software manually.
- 一.Hostname verification
- 1. change /etc/hosts in order to simulate the DNS hijack
- 46.137.23.30 attacker.com
-（46.137.23.30 is a normal irc server）
-
- 2. #rainkin@rainkin:~$ epic5 rainkin attacker.com:6697:::OPN:irc-ssl
-
- 3. result
[Bug 1380304] Re: perdition have some SSL security problems
** Description changed:
Recently, our group is trying to find SSL security problems by static
analysis. When using Openssl, people tend to miss the step or to
misunderstand the APIs when using SSL/TLS, which might cause severe man
in the middle attack and break the entire TLS mechanism. And static
analysis is a way of finding whether the APIs are called correctly.
- Now we just check whether a software verify the certitiface chain when
- using Openssl.
+ The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
+ Now we just check whether a software verify the certitiface chain when using
Openssl.
一. How we ensure whether a software check the certificate chain or not?
We make a matching algorithm. If source code doesn't match this, the software
is not secure.
Typically, when Openssl clients want to verify a certificate, there are
the following choices:
1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
[Example 1]
- /**
- * set VERIFY_PEER flag before the establishment of a SSL connection
- * OPENSSL will drop connection during handshake if verification fails
- * No custom callback function used.
- */
- SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
[Example 2]
//check the built-in verification result after the SSL handshake
if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
{
-//PASS
+ //PASS
}
else
{
- //FAIL
+ //FAIL
}
2. Using custom verification.
[Example 3]
X509* usrcert = SSL_get_peer_certificate(ssl);
rootCertStore = X509_STORE_new();
.. ..
ctx = X509_STORE_CTX_new();
ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
ret = X509_verify_cert(ctx)
This example read the certificate out using SSL_get_peer_certificate
API. Then it use X509 API suite to do certificate verification. X509 API
is part of OPENSSL library. Theoretically, a developer can use any API
in any libraries to do this verification, but in practice, we only
identify the case above: using X509 API suite.
3. Add restrictions or relaxations to built-in certificate verification
The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
[Example 4]
SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
{
return preverify_ok;
}
二. The analysis result
Now, we find some SSL problems in perdition, the following is details:
-
file : perdition/perdition-1.19~rc4/perdition/ssl.c
-
function : __perdition_ssl_connection
-
SSL method : SSLv23
-
SSL_CTX_set_verify() argument : SSL_VERIFY_PEER
-
Have SSL_CTX_set_verify ( SSL_set_verify) callback : YES (but accept
self-signed certificate expired certificate)
-
call SSL_get_peer_certificate(): NO
-
call SSL_get_verify_result(): NO
-
According to the above result, we think the SSL connection in perdition
is not secure .perdition can accept self-signed certificate
certificate, which means MITM attack is possible.
PS: for more information, you can see the paper:
http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your
responce.
Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1380304
Title:
perdition have some SSL security problems
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/perdition/+bug/1380304/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380435] Re: epic5's SSL connection is not secure
** Description changed:
Recently, our group is trying to find SSL security problems by static
analysis. When using Openssl, people tend to miss the step or to
misunderstand the APIs when using SSL/TLS, which might cause severe man
in the middle attack and break the entire TLS mechanism. And static
analysis is a way of finding whether the APIs are called correctly.
- Now we just check whether a software verify the certitiface chain when
- using Openssl.
+ The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
+ Now we just check whether a software verify the certitiface chain when using
Openssl.
一. How we ensure whether a software check the certificate chain or not?
We make a matching algorithm. If source code doesn't match this, the software
is not secure.
Typically, when Openssl clients want to verify a certificate, there are
the following choices:
1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
[Example 1]
- /**
- * set VERIFY_PEER flag before the establishment of a SSL connection
- * OPENSSL will drop connection during handshake if verification fails
- * No custom callback function used.
- */
- SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
[Example 2]
//check the built-in verification result after the SSL handshake
if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
{
-//PASS
+ //PASS
}
else
{
- //FAIL
+ //FAIL
}
2. Using custom verification.
[Example 3]
X509* usrcert = SSL_get_peer_certificate(ssl);
rootCertStore = X509_STORE_new();
.. ..
ctx = X509_STORE_CTX_new();
ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
ret = X509_verify_cert(ctx)
This example read the certificate out using SSL_get_peer_certificate
API. Then it use X509 API suite to do certificate verification. X509 API
is part of OPENSSL library. Theoretically, a developer can use any API
in any libraries to do this verification, but in practice, we only
identify the case above: using X509 API suite.
3. Add restrictions or relaxations to built-in certificate verification
The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
[Example 4]
SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
{
return preverify_ok;
}
二. The analysis result
Now, we find some SSL problems in epic5, the following is details:
-
file : epic5/epic5-1.1.2/source/ssl.c
-
function : ssl_connect
-
SSL method : \
-
call SSL_CTX_set_verify() : NOT FOUND
-
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-
call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom
verification)
-
call SSL_get_verify_result(): NO
-
According to the above result, we think the SSL connection in epic5 is
not secure.
-
三. How we prove the result we got.
To verify the result we make, we attack the software manually.
1. change the system time to 2200 to guarantee the certificate to be
expired.
2. run epic5 to connect to a normal irc server.
3. result:succeed!!
The fetch succeeded again and no warning was given, indicating the
software didn't check whether the certificate expired or not.
PS: I have saved the SSL connection Wireshark packages, and upload these
files.
for more information, you can see the paper:
http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your
responce.
Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
[Bug 1380298] Re: some SSL security problems
** Description changed:
Recently, our group is trying to find SSL security problems by static
analysis. When using Openssl, people tend to miss the step or to
misunderstand the APIs when using SSL/TLS, which might cause severe man
in the middle attack and break the entire TLS mechanism. And static
analysis is a way of finding whether the APIs are called correctly.
- Now we just check whether a software verify the certitiface chain when
- using Openssl.
+ The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
+ Now we just check whether a software verify the certitiface chain when using
Openssl.
一. How we ensure whether a software check the certificate chain or not?
We make a matching algorithm. If source code doesn't match this, the software
is not secure.
Typically, when Openssl clients want to verify a certificate, there are
the following choices:
1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
[Example 1]
/**
* set VERIFY_PEER flag before the establishment of a SSL connection
* OPENSSL will drop connection during handshake if verification fails
* No custom callback function used.
*/
SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
[Example 2]
//check the built-in verification result after the SSL handshake
if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
{
//PASS
}
else
{
//FAIL
}
2. Using custom verification.
[Example 3]
X509* usrcert = SSL_get_peer_certificate(ssl);
rootCertStore = X509_STORE_new();
....
ctx = X509_STORE_CTX_new();
ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
ret = X509_verify_cert(ctx)
This example read the certificate out using SSL_get_peer_certificate
API. Then it use X509 API suite to do certificate verification. X509 API
is part of OPENSSL library. Theoretically, a developer can use any API
in any libraries to do this verification, but in practice, we only
identify the case above: using X509 API suite.
3. Add restrictions or relaxations to built-in certificate verification
The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
[Example 4]
SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
{
return preverify_ok;
}
二. The analysis result
Now, we find some SSL problems in crtmpserver, the following is details:
-
file : crtmpserver-apps/crtmpserver-1.0~dfsg/thelib/src/protocols/ssl
/outboundsslprotocol.cpp
-
function : OutboundSSLProtocol::DoHandshake()
-
SSL method : \
-
SSL_CTX_set_verify() argument :SSL_VERIFY_NONE
-
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-
call SSL_get_peer_certificate():NO
-
call SSL_get_verify_result(): NO
-
According to the above result, we think crtmpserver doesn't check the
certificate chain when using OPENSSL.
PS: for more information, you can see the paper:
http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your
responce.
Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1380298
Title:
some SSL security problems
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crtmpserver/+bug/1380298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380458] Re: dma have some SSL security problems
** Description changed:
- Recently, we are trying to find SSL security problems by static
- analysis. For example, as we all know, Hostname verification is an
- important step when verifying X509 certificates, however, people tend to
- miss the step or to misunderstand the APIs when using SSL/TLS, which
- might cause severe man in the middle attack and break the entire TLS
- mechanism. And static analysis is a way of finding whether the APIs are
- called correctly.
+ Recently, our group is trying to find SSL security problems by static
+ analysis. When using Openssl, people tend to miss the step or to
+ misunderstand the APIs when using SSL/TLS, which might cause severe man
+ in the middle attack and break the entire TLS mechanism. And static
+ analysis is a way of finding whether the APIs are called correctly.
+
+ The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
+ Now we just check whether a software verify the certitiface chain when using
Openssl.
+
+ 一. How we ensure whether a software check the certificate chain or not?
+ We make a matching algorithm. If source code doesn't match this, the software
is not secure.
+
+ Typically, when Openssl clients want to verify a certificate, there are
+ the following choices:
+
+ 1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
+ [Example 1]
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+
+ [Example 2]
+
+ //check the built-in verification result after the SSL handshake
+
+ if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
+ {
+//PASS
+ }
+ else
+ {
+ //FAIL
+ }
+
+ 2. Using custom verification.
+
+ [Example 3]
+ X509* usrcert = SSL_get_peer_certificate(ssl);
+ rootCertStore = X509_STORE_new();
+ .. ..
+ ctx = X509_STORE_CTX_new();
+ ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
+ ret = X509_verify_cert(ctx)
+
+ This example read the certificate out using SSL_get_peer_certificate
+ API. Then it use X509 API suite to do certificate verification. X509 API
+ is part of OPENSSL library. Theoretically, a developer can use any API
+ in any libraries to do this verification, but in practice, we only
+ identify the case above: using X509 API suite.
+
+ 3. Add restrictions or relaxations to built-in certificate verification
+
+ The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
+ By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
+
+ [Example 4]
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
+ static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
+ {
+
+
+ return preverify_ok;
+ }
+
+ 二. The analysis result
Now, we find some SSL problems in dma, the following is details:
-
file : dma/dma-0.0.2010.06.17/crypto.c
-
function : smtp_init_crypto
-
SSL method : \
-
call SSL_CTX_set_verify() : NOT FOUND
-
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-
call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom
verification)
-
call SSL_get_verify_result(): NO
-
According to the above result, we think the SSL connection in dma is not
- secure. For instance, missing hostname or expired time check when
- verifying x509 certificate.
+ secure.
- More specifically , we can take function SSL_CTX_set_verify() for
- example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx,
- SSL_VERIFY_NONE, null), we should verify the certificate by calling the
- function SSL_get_peer_certificate() to get the certificate at first.
- Then use X509 APIs or self-define function to verify the certificate we
- get. If the source code does not match this model, then we can deduce
- this code is vulnerable. And other APIs have similar problems.
+ 三. How we prove the result we got?
To verify the result we make, we attack the software manually.
At first, we should configure the
[Bug 1380439] Re: ftp-ssl's ssl connection is not secure
** Description changed:
- Recently, we are trying to find SSL security problems by static
- analysis. For example, as we all know, Hostname verification is an
- important step when verifying X509 certificates, however, people tend to
- miss the step or to misunderstand the APIs when using SSL/TLS, which
- might cause severe man in the middle attack and break the entire TLS
- mechanism. And static analysis is a way of finding whether the APIs are
- called correctly.
- Now, we find some SSL problems in ftp-ssl :
- 1. ftp-ssl miss hostname check when verify x509 certificate
- 2. ftp-ssl miss expired time check when verify x509 certificate
+ Recently, our group is trying to find SSL security problems by static
analysis. When using Openssl, people tend to miss the step or to misunderstand
the APIs when using SSL/TLS, which might cause severe man in the middle attack
and break the entire TLS mechanism. And static analysis is a way of finding
whether the APIs are called correctly.
- More specifically , we can take function SSL_CTX_set_verify() for
- example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx,
- SSL_VERIFY_NONE, null), we should verify the certificate by calling the
- function SSL_get_peer_certificate() to get the certificate at first.
- Then use X509 APIs or self-define function to verify the certificate we
- get. If the source code does not match this model, then we can deduce
- this code is vulnerable. And other APIs have similar problems.
+ The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
+ Now we just check whether a software verify the certitiface chain when using
Openssl.
+
+ 一. How we ensure whether a software check the certificate chain or not?
+ We make a matching algorithm. If source code doesn't match this, the software
is not secure.
+
+ Typically, when Openssl clients want to verify a certificate, there are
+ the following choices:
+
+ 1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
+ [Example 1]
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+
+ [Example 2]
+
+ //check the built-in verification result after the SSL handshake
+
+ if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
+ {
+//PASS
+ }
+ else
+ {
+ //FAIL
+ }
+
+ 2. Using custom verification.
+
+ [Example 3]
+ X509* usrcert = SSL_get_peer_certificate(ssl);
+ rootCertStore = X509_STORE_new();
+ .. ..
+ ctx = X509_STORE_CTX_new();
+ ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
+ ret = X509_verify_cert(ctx)
+
+ This example read the certificate out using SSL_get_peer_certificate
+ API. Then it use X509 API suite to do certificate verification. X509 API
+ is part of OPENSSL library. Theoretically, a developer can use any API
+ in any libraries to do this verification, but in practice, we only
+ identify the case above: using X509 API suite.
+
+ 3. Add restrictions or relaxations to built-in certificate verification
+
+ The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
+ By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
+
+ [Example 4]
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
+ static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
+ {
+
+
+ return preverify_ok;
+ }
+
+ 二. The analysis result
+
+ Now, we find some SSL problems in ftp-ssl, the following is details:
+
+
+ -
+ function : OutboundSSLProtocol::DoHandshake()
+ -
+ SSL method : \
+ -
+ SSL_CTX_set_verify() argument : SSL_VERIFY_NONE
+ -
+ Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
+ -
+ call SSL_get_peer_certificate(): NO
+ -
+ call SSL_get_verify_result(): NO
+ -
+
+ According to the above result, we think crtmpserver doesn't check the
+ certificate chain when using OPENSSL.
To verify the result we make, we attack the software manually.
we take expired time check for example :
1. change the system time to 2200 to guarantee the certificate to be
[Bug 1380453] Re: epic4 have some SSL security problems
attacker.com
+ （46.137.23.30 is a normal irc server）
2. #rainkin@rainkin:~$ epic4 rainkin attacker.com:6697:::OPN:irc-ssl
3. result : succeed!!!
The fetch succeeded, indicating the software didn't check the hostname
against the signee of the certificate.
二. Also for expired time check,
1. change the system time to 2200 to guarantee the certificate to be expired.
2. run epic4 to connect to a normal irc server.
3. result:succeed!!
The fetch succeeded again and no warning was given, indicating the
software didn't check whether the certificate expired or not.
PS: I have saved the SSL connection Wireshark packages, and upload these
files.
for more information, you can see the paper:
http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your
responce.
Thanks.
** Description changed:
Recently, our group is trying to find SSL security problems by static
analysis. When using Openssl, people tend to miss the step or to
misunderstand the APIs when using SSL/TLS, which might cause severe man
in the middle attack and break the entire TLS mechanism. And static
analysis is a way of finding whether the APIs are called correctly.
The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
Now we just check whether a software verify the certitiface chain when using
Openssl.
一. How we ensure whether a software check the certificate chain or not?
We make a matching algorithm. If source code doesn't match this, the software
is not secure.
Typically, when Openssl clients want to verify a certificate, there are
the following choices:
1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
[Example 1]
- /**
- * set VERIFY_PEER flag before the establishment of a SSL connection
- * OPENSSL will drop connection during handshake if verification fails
- * No custom callback function used.
- */
- SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
[Example 2]
//check the built-in verification result after the SSL handshake
if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
{
-//PASS
+ //PASS
}
else
{
- //FAIL
+ //FAIL
}
2. Using custom verification.
[Example 3]
X509* usrcert = SSL_get_peer_certificate(ssl);
rootCertStore = X509_STORE_new();
.. ..
ctx = X509_STORE_CTX_new();
ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
ret = X509_verify_cert(ctx)
This example read the certificate out using SSL_get_peer_certificate
API. Then it use X509 API suite to do certificate verification. X509 API
is part of OPENSSL library. Theoretically, a developer can use any API
in any libraries to do this verification, but in practice, we only
identify the case above: using X509 API suite.
3. Add restrictions or relaxations to built-in certificate verification
The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
[Example 4]
SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
{
return preverify_ok;
}
二. The analysis result
Now, we find some SSL problems in epic4, the following is details:
-
file : epic4/epic4-2.10.1/source/ssl.c
-
function : SSL_FD_init
-
SSL method : \
-
call SSL_CTX_set_verify() : NOT FOUND
-
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-
call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom
verification)
-
call SSL_get_verify_result(): NO
-
According to the above result, we think the SSL connection in epic4 is
not secure.
- More specifically
[Bug 1380439] Re: ftp-ssl's ssl connection is not secure
** Description changed:
Recently, our group is trying to find SSL security problems by static
analysis. When using Openssl, people tend to miss the step or to
misunderstand the APIs when using SSL/TLS, which might cause severe man
in the middle attack and break the entire TLS mechanism. And static
analysis is a way of finding whether the APIs are called correctly.
The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
Now we just check whether a software verify the certitiface chain when using
Openssl.
一. How we ensure whether a software check the certificate chain or not?
We make a matching algorithm. If source code doesn't match this, the software
is not secure.
Typically, when Openssl clients want to verify a certificate, there are
the following choices:
1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
[Example 1]
/**
* set VERIFY_PEER flag before the establishment of a SSL connection
* OPENSSL will drop connection during handshake if verification fails
* No custom callback function used.
*/
SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
[Example 2]
//check the built-in verification result after the SSL handshake
if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
{
//PASS
}
else
{
//FAIL
}
2. Using custom verification.
[Example 3]
X509* usrcert = SSL_get_peer_certificate(ssl);
rootCertStore = X509_STORE_new();
.. ..
ctx = X509_STORE_CTX_new();
ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
ret = X509_verify_cert(ctx)
This example read the certificate out using SSL_get_peer_certificate
API. Then it use X509 API suite to do certificate verification. X509 API
is part of OPENSSL library. Theoretically, a developer can use any API
in any libraries to do this verification, but in practice, we only
identify the case above: using X509 API suite.
3. Add restrictions or relaxations to built-in certificate verification
The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
[Example 4]
SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
{
return preverify_ok;
}
二. The analysis result
Now, we find some SSL problems in ftp-ssl, the following is details:
- ..（add a minute later）
+
+ -
+ function : ssl_init
+ -
+ SSL method : SSLv23
+ -
+ call SSL_CTX_set_verify() : NOT FOUND
+ -
+ Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
+ -
+ call SSL_get_peer_certificate(): NO
+ -
+ call SSL_get_verify_result(): NO
+ -
According to the above result, we think crtmpserver doesn't check the
certificate chain when using OPENSSL.
To verify the result we make, we attack the software manually.
we take expired time check for example :
1. change the system time to 2200 to guarantee the certificate to be expired.
2. run command : ftp-ssl -z debug 192.168.68.130
(PS:192.168.68.130 is a norml ftp server)
3. result:succeed!!
The fetch succeeded again and no warning was given, indicating the
software didn't check whether the certificate expired or not.
PS:
for more information, you can see the paper:
http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your
responce.
Thanks.
** Description changed:
Recently, our group is trying to find SSL security problems by static
analysis. When using Openssl, people tend to miss the step or to
misunderstand the APIs when using SSL/TLS, which might cause severe man
in the middle attack and break the entire TLS mechanism. And static
analysis is a way of finding whether the APIs are called correctly.
The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
Now we just check whether a software verify the certitiface chain when using
Openssl.
一. How we ensure whether a software
[Bug 1380449] Re: citadel-client have some ssl security problems
** Description changed:
- Recently, we are trying to find SSL security problems by static
- analysis. For example, as we all know, Hostname verification is an
- important step when verifying X509 certificates, however, people tend to
- miss the step or to misunderstand the APIs when using SSL/TLS, which
- might cause severe man in the middle attack and break the entire TLS
- mechanism. And static analysis is a way of finding whether the APIs are
- called correctly.
+ Recently, our group is trying to find SSL security problems by static
+ analysis. When using Openssl, people tend to miss the step or to
+ misunderstand the APIs when using SSL/TLS, which might cause severe man
+ in the middle attack and break the entire TLS mechanism. And static
+ analysis is a way of finding whether the APIs are called correctly.
- Now, we find some SSL problems in citadel-client:
- 1. miss hostname check when verify x509 certificate
- 2. miss expired time check when verify x509 certificate
+ The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
+ Now we just check whether a software verify the certitiface chain when using
Openssl.
- More specifically , we can take function SSL_CTX_set_verify() for
- example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx,
- SSL_VERIFY_NONE, null), we should verify the certificate by calling the
- function SSL_get_peer_certificate() to get the certificate at first.
- Then use X509 APIs or self-define function to verify the certificate we
- get. If the source code does not match this model, then we can deduce
- this code is vulnerable. And other APIs have similar problems.
+ 一. How we ensure whether a software check the certificate chain or not?
+ We make a matching algorithm. If source code doesn't match this, the software
is not secure.
+
+ Typically, when Openssl clients want to verify a certificate, there are
+ the following choices:
+
+ 1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
+ [Example 1]
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+
+ [Example 2]
+
+ //check the built-in verification result after the SSL handshake
+
+ if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
+ {
+//PASS
+ }
+ else
+ {
+ //FAIL
+ }
+
+ 2. Using custom verification.
+
+ [Example 3]
+ X509* usrcert = SSL_get_peer_certificate(ssl);
+ rootCertStore = X509_STORE_new();
+ .. ..
+ ctx = X509_STORE_CTX_new();
+ ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
+ ret = X509_verify_cert(ctx)
+
+ This example read the certificate out using SSL_get_peer_certificate
+ API. Then it use X509 API suite to do certificate verification. X509 API
+ is part of OPENSSL library. Theoretically, a developer can use any API
+ in any libraries to do this verification, but in practice, we only
+ identify the case above: using X509 API suite.
+
+ 3. Add restrictions or relaxations to built-in certificate verification
+
+ The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
+ By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
+
+ [Example 4]
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
+ static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
+ {
+
+
+ return preverify_ok;
+ }
+
+ 二. The analysis result
+
+ Now, we find some SSL problems in citadel-client, the following is
+ details:
+
+ -
+ function : CtdlIPCStartEncryption
+ -
+ SSL method : SSLv23
+ -
+ call SSL_CTX_set_verify() : NOT FOUND
+ -
+ Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
+ -
+ call SSL_get_peer_certificate(): NO
+ -
+ call SSL_get_verify_result(): NO
+ -
+
+ According to the above result, we think citadel-client doesn't check the
+ certificate chain when using OPENSSL.
+
+ 三. How we prove the result we got?
To verify the result we make, we attack the software manually.
we take expired time check for example :
1. change the system time to 2200 to guarantee
[Bug 1380452] Re: apf-client doesn't check hostname or expired time when verifying x509 certificate
** Description changed:
- Recently, we are trying to find SSL security problems by static
- analysis. For example, as we all know, Hostname verification is an
- important step when verifying X509 certificates, however, people tend to
- miss the step or to misunderstand the APIs when using SSL/TLS, which
- might cause severe man in the middle attack and break the entire TLS
- mechanism. And static analysis is a way of finding whether the APIs are
- called correctly.
+ Recently, our group is trying to find SSL security problems by static
+ analysis. When using Openssl, people tend to miss the step or to
+ misunderstand the APIs when using SSL/TLS, which might cause severe man
+ in the middle attack and break the entire TLS mechanism. And static
+ analysis is a way of finding whether the APIs are called correctly.
- Now, we find some SSL problems in apf-client:
- 1. miss hostname check when verify x509 certificate
- 2. miss expired time check when verify x509 certificate
+ The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
+ Now we just check whether a software verify the certitiface chain when using
Openssl.
- More specifically , we can take function SSL_CTX_set_verify() for
- example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx,
- SSL_VERIFY_NONE, null), we should verify the certificate by calling the
- function SSL_get_peer_certificate() to get the certificate at first.
- Then use X509 APIs or self-define function to verify the certificate we
- get. If the source code does not match this model, then we can deduce
- this code is vulnerable. And other APIs have similar problems.
+ 一. How we ensure whether a software check the certificate chain or not?
+ We make a matching algorithm. If source code doesn't match this, the software
is not secure.
+ Typically, when Openssl clients want to verify a certificate, there are
+ the following choices:
+
+ 1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
+ [Example 1]
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+
+ [Example 2]
+
+ //check the built-in verification result after the SSL handshake
+
+ if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
+ {
+//PASS
+ }
+ else
+ {
+ //FAIL
+ }
+
+ 2. Using custom verification.
+
+ [Example 3]
+ X509* usrcert = SSL_get_peer_certificate(ssl);
+ rootCertStore = X509_STORE_new();
+ .. ..
+ ctx = X509_STORE_CTX_new();
+ ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
+ ret = X509_verify_cert(ctx)
+
+ This example read the certificate out using SSL_get_peer_certificate
+ API. Then it use X509 API suite to do certificate verification. X509 API
+ is part of OPENSSL library. Theoretically, a developer can use any API
+ in any libraries to do this verification, but in practice, we only
+ identify the case above: using X509 API suite.
+
+ 3. Add restrictions or relaxations to built-in certificate verification
+
+ The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
+ By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
+
+ [Example 4]
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
+ static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
+ {
+
+
+ return preverify_ok;
+ }
+
+ 二. The analysis result
+
+ Now, we find some SSL problems in apf-client, the following is details:
+
+ -
+ function : http_proxy_client
+ -
+ SSL method : SSLv23
+ -
+ call SSL_CTX_set_verify() : NOT FOUND
+ -
+ Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
+ -
+ call SSL_get_peer_certificate(): YES
+ -
+ call SSL_get_verify_result(): NO
+ -
+
+ According to the above result, we think apf-client doesn't check the
+ certificate chain when using OPENSSL.
+
+ 三. How we prove the result we got?
To verify the result we make, we attack the software manually.
- 一. hostnmae check:
- 1. configure the file /etc/hosts in order to simulate DNS hijack:
- hackbyfun.com
[Bug 1381936] Re: SSL connection is not secure in links
** Description changed:
- Recently, we are trying to find SSL security problems by static
- analysis. For example, as we all know, Hostname verification is an
- important step when verifying X509 certificates, however, people tend to
- miss the step or to misunderstand the APIs when using SSL/TLS, which
- might cause severe man in the middle attack and break the entire TLS
- mechanism. And static analysis is a way of finding whether the APIs are
- called correctly.
+ Recently, our group is trying to find SSL security problems by static
+ analysis. When using Openssl, people tend to miss the step or to
+ misunderstand the APIs when using SSL/TLS, which might cause severe man
+ in the middle attack and break the entire TLS mechanism. And static
+ analysis is a way of finding whether the APIs are called correctly.
- Now, we find some SSL problems in links:
- 1. miss hostname check when verify x509 certificate
- 2. miss expired time check when verify x509 certificate
+ The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
+ Now we just check whether a software verify the certitiface chain when using
Openssl.
- More specifically , we can take function SSL_CTX_set_verify() for
- example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx,
- SSL_VERIFY_NONE, null), we should verify the certificate by calling the
- function SSL_get_peer_certificate() to get the certificate at first.
- Then use X509 APIs or self-define function to verify the certificate we
- get. If the source code does not match this model, then we can deduce
- this code is vulnerable. And other APIs have similar problems.
+ 一. How we ensure whether a software check the certificate chain or not?
+ We make a matching algorithm. If source code doesn't match this, the software
is not secure.
- To verify the result we make, we prove the vulnerability manually.
- Result ：we can browse any website with invalid certificate and we won’t get
any warnings.
+ Typically, when Openssl clients want to verify a certificate, there are
+ the following choices:
+
+ 1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
+ [Example 1]
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+
+ [Example 2]
+
+ //check the built-in verification result after the SSL handshake
+
+ if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
+ {
+//PASS
+ }
+ else
+ {
+ //FAIL
+ }
+
+ 2. Using custom verification.
+
+ [Example 3]
+ X509* usrcert = SSL_get_peer_certificate(ssl);
+ rootCertStore = X509_STORE_new();
+ .. ..
+ ctx = X509_STORE_CTX_new();
+ ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
+ ret = X509_verify_cert(ctx)
+
+ This example read the certificate out using SSL_get_peer_certificate
+ API. Then it use X509 API suite to do certificate verification. X509 API
+ is part of OPENSSL library. Theoretically, a developer can use any API
+ in any libraries to do this verification, but in practice, we only
+ identify the case above: using X509 API suite.
+
+ 3. Add restrictions or relaxations to built-in certificate verification
+
+ The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
+ By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
+
+ [Example 4]
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
+ static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
+ {
+
+
+ return preverify_ok;
+ }
+
+ 二. The analysis result
+
+ Now, we find some SSL problems in links, the following is details:
+
+ -
+ function : ssl_want_read（）
+connected（）
+ -
+ SSL method : SSLv23
+ -
+ SSL_CTX_set_verify() argument : SSL_VERIFY_PEER
+ -
+ Have SSL_CTX_set_verify ( SSL_set_verify) callback : YES(accept self-signed
certificate)
+ -
+ call SSL_get_peer_certificate(): /
+ -
+ call SSL_get_verify_result(): /
+ -
+
+ According to the above result, we think links is not secure. links can
+ accept self-signed certificate, we think
[Bug 1381940] Re: suck have ssl security problems
** Description changed:
- Recently, we are trying to find SSL security problems by static
- analysis. For example, as we all know, Hostname verification is an
- important step when verifying X509 certificates, however, people tend to
- miss the step or to misunderstand the APIs when using SSL/TLS, which
- might cause severe man in the middle attack and break the entire TLS
- mechanism. And static analysis is a way of finding whether the APIs are
- called correctly.
+ Recently, our group is trying to find SSL security problems by static
+ analysis. When using Openssl, people tend to miss the step or to
+ misunderstand the APIs when using SSL/TLS, which might cause severe man
+ in the middle attack and break the entire TLS mechanism. And static
+ analysis is a way of finding whether the APIs are called correctly.
- Now, we find some SSL problems in suck:
- 1. miss hostname check when verify x509 certificate
- 2. miss expired time check when verify x509 certificate
+ The source code we analysis was from ubuntu: apt-get source package
name.And we use this command in Ubuntu 12.04.
+ Now we just check whether a software verify the certitiface chain when using
Openssl.
- More specifically , we can take function SSL_CTX_set_verify() for
- example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx,
- SSL_VERIFY_NONE, null), we should verify the certificate by calling the
- function SSL_get_peer_certificate() to get the certificate at first.
- Then use X509 APIs or self-define function to verify the certificate we
- get. If the source code does not match this model, then we can deduce
- this code is vulnerable. And other APIs have similar problems.
+ 一. How we ensure whether a software check the certificate chain or not?
+ We make a matching algorithm. If source code doesn't match this, the software
is not secure.
- To verify the result we make, we prove the vulnerability manually.
- Result ：we can connect to any server with invalid certificate and we won’t
get any warnings.
+ Typically, when Openssl clients want to verify a certificate, there are
+ the following choices:
+
+ 1. Using built-in certificate verification(chain of trust verification,
expired validation, etc)
+ [Example 1]
+ /**
+ * set VERIFY_PEER flag before the establishment of a SSL connection
+ * OPENSSL will drop connection during handshake if verification fails
+ * No custom callback function used.
+ */
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
+
+ [Example 2]
+
+ //check the built-in verification result after the SSL handshake
+
+ if(SSL_get_peer_certificate(ssl)!=NULL
SSL_get_verify_result(ssl)==X509_V_OK)
+ {
+//PASS
+ }
+ else
+ {
+ //FAIL
+ }
+
+ 2. Using custom verification.
+
+ [Example 3]
+ X509* usrcert = SSL_get_peer_certificate(ssl);
+ rootCertStore = X509_STORE_new();
+ .. ..
+ ctx = X509_STORE_CTX_new();
+ ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
+ ret = X509_verify_cert(ctx)
+
+ This example read the certificate out using SSL_get_peer_certificate
+ API. Then it use X509 API suite to do certificate verification. X509 API
+ is part of OPENSSL library. Theoretically, a developer can use any API
+ in any libraries to do this verification, but in practice, we only
+ identify the case above: using X509 API suite.
+
+ 3. Add restrictions or relaxations to built-in certificate verification
+
+ The built-in certificate verification in OPENSSL library can be extended by
using custom callback functions. By default, this callback option is NULL,
indicating completely use built-in verification.
+ By adding this callback function, the developer can decide if they accept the
verify result by openssl, and they can modify the result whenever they what.
+
+ [Example 4]
+ SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
+ static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
+ {
+
+
+ return preverify_ok;
+ }
+
+ 二. The analysis result
+
+ Now, we find some SSL problems in suck, the following is details:
+
+ -
+ function : connect_to_nntphost（）
+ -
+ SSL method : SSLv23
+ -
+ call SSL_CTX_set_verify() : NOT FOUND
+ -
+ Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
+ -
+ call SSL_get_peer_certificate(): NO
+ -
+ call SSL_get_verify_result(): NO
+ -
+
+ According to the above result, we think suck doesn't check the
+ certificate chain.
PS:
+ We test suck in Ubunut 12.04.
for more information, you can see the paper:
[Bug 1378617] [NEW] xxxterm has SSL security problems
Public bug reported: Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. We believe that xxxterm didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate. We found the vulnerability by static analysis, typically, a process of verification involves calling a chain of API, and we can deduce whether the communication process is vulnerable by detecting whether the function call process matches a certain model. For example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate. If the source code does not match this model, then we can deduce this code is vulnerable. What’ more , Gnutls is the same as Openssl. This is the result for xxxterm: /xxxterm-1.10.0/xxxterm.c have problems. Host name verification missing We provide this result to help developers to locate the problem faster. To verify the result: 一. Hostname check 1.configure /etc/hosts in order to simulate DNS hijack 42.62.48.90 www.facebook.com # 42.62.48.90 is the ip of i.mi.com 2. visit the website https://www.facebook.com with xxxterm 3. result : connecting succeed without any warning!!! The fetch succeeded, indicating xxxterm didn't check the hostname against the signee of the certificate. 二.Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run xxxterm to visit any https website, such as https://www.youtube.com. 3. result : succeed without any warning!! The fetch succeeded again and no warning was given, indicating xxxterm didn't check whether the certificate expired or not. I am running xxxterm 1.11.3-1.2 in ubuntu 14.04 LTS. I have save the SSL connecting packages and upload these wireshark files. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. ** Affects: xxxterm (Ubuntu) Importance: Undecided Status: New ** Tags: ssl ** Attachment added: wireshark ssl connecting packages https://bugs.launchpad.net/bugs/1378617/+attachment/4227990/+files/xxxterm.zip ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1378617 Title: xxxterm has SSL security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xxxterm/+bug/1378617/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380022] [NEW] aiccu's SSL connection is not secure
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in aiccu, the following is details: 1. /aiccu-20070115/common/common.c Certificate verification missing Still vulnerable in Ubunutu 14.04 http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/aiccu/trusty/view/head:/common/common.c; 2. /aiccu-20070115/common/common.c Host name verification missing Still vulnerable in Ubunutu 14.04 http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/aiccu/trusty/view/head:/common/common.c; PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, my email : rainkin1...@gmail.com Thanks. ** Affects: aiccu (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380022 Title: aiccu's SSL connection is not secure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1380022/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1376592] Re: X509 certificate verification problem
** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1376592 Title: X509 certificate verification problem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/freetds/+bug/1376592/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1378617] Re: xxxterm has SSL security problems
** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1378617 Title: xxxterm has SSL security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xxxterm/+bug/1378617/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1376595] Re: X509 certificate verification problem
** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1376595 Title: X509 certificate verification problem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/scrollz/+bug/1376595/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380022] Re: aiccu's SSL connection is not secure
** Description changed: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in aiccu, the following is details: - 1. + 1. /aiccu-20070115/common/common.c - Certificate verification missing + Certificate chain verification is missing - Still vulnerable in Ubunutu 14.04 - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/aiccu/trusty/view/head:/common/common.c; + 2. + /aiccu-20070115/common/common.c + Hostname verification is missing - 2. - /aiccu-20070115/common/common.c - Host name verification missing - - Still vulnerable in Ubunutu 14.04 - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/aiccu/trusty/view/head:/common/common.c; + More specifically , we can take hostname check for example, the function + verify_certificate() can only guarantee the validity of the certificate + but cannot guarantee that the host you are trying to connect is the one + you intend to visit, which may lead to man-in-the-middle attack or other + security issues. And other APIs have similar problems. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, my email : rainkin1...@gmail.com Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380022 Title: aiccu's SSL connection is not secure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1380022/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380031] [NEW] hostname and certificate chain check missing when verifying X509 certificate
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in charybdis, the following is details: 1. /charybdis-3.3.0/libratbox/src/gnutls.c Certificate chain verification is missing 2. /charybdis-3.3.0/libratbox/src/gnutls.c Hostname verification is missing More specifically , we can take hostname check for example, the function verify_certificate() can only guarantee the validity of the certificate but cannot guarantee that the host you are trying to connect is the one you intend to visit, which may lead to man-in-the-middle attack or other security issues. And other APIs have similar problems. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, my email : rainkin1...@gmail.com Thanks. ** Affects: charybdis (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380031 Title: hostname and certificate chain check missing when verifying X509 certificate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/charybdis/+bug/1380031/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1376592] Re: X509 certificate verification problem
** Description changed: - Hostname verification is an important step when verifying X509 - certificates, however, people tend to miss the step or to misunderstand - the APIs when using SSL/TLS, which might cause severe man in the middle - attack and break the entire TLS mechanism. - We believe that freetds-bin didn't check whether the hostname matches - the name in the SSL certificate and the expired date of the certificate. + Recently, we are trying to find SSL security problems by static anaylsis. + For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. - We found the vulnerability by static analysis, typically, a process of - verification involves calling a chain of API, and we can deduce whether - the communication process is vulnerable by detecting whether the - function call process matches a certain model. For example, when using - OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), - we should verify the certificate by calling the function - SSL_get_peer_certificate() to get the certificate. If the source code - does not match this model, then we can deduce this code is vulnerable. - What’ more , Gnutls is the same as Openssl. + During the experiment, we find that freetds-bin didn't check whether the + hostname matches the name in the SSL certificate and the expired date of + the certificate. - To verify the result: + + To verify the result, we attack the software manually: 一.Hostname verification: 1. configure the file freetds.conf : # A typical Microsoft server [sqlserver2000] host = hackbyfun.sqlserver.com port = 1433 tds version = 8.0 encrpytion = require 2.wirte the file /etc/hosts in order to simulate DNS hijack: 10.214.146.123 hackbyfun.sqlserver.com (PS: 10.214.146.123 is a normal sql server ip, its domain name is safe.sqlserver.com ) 3.connect with freetds-bin tsql -S sqlserver2000 -U sa -P your password 4.result：connect succeed!! The fetch succeeded, indicating freetds-bin didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. the same as the above process. Run freetds-bin to connect a normal sql server 3. result :connect succeed!! The fetch succeeded again and no warning was given, indicating freetds- bin didn't check whether the certificate expired or not. (PS: I have saved the wireshark packages, and upload these files) I am running freetds-bin 9.1-5 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. ** Description changed: - Recently, we are trying to find SSL security problems by static anaylsis. For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. During the experiment, we find that freetds-bin didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate. - To verify the result, we attack the software manually: 一.Hostname verification: 1. configure the file freetds.conf : # A typical Microsoft server [sqlserver2000] host = hackbyfun.sqlserver.com port = 1433 tds version = 8.0 encrpytion = require 2.wirte the file /etc/hosts in order to simulate DNS hijack: 10.214.146.123 hackbyfun.sqlserver.com (PS: 10.214.146.123 is a normal sql server ip, its domain name is safe.sqlserver.com ) 3.connect with freetds-bin tsql -S sqlserver2000 -U sa -P your password 4.result：connect succeed!! The fetch succeeded, indicating freetds-bin didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. the same as the above process. Run freetds-bin to connect a normal sql server 3. result :connect succeed!! The fetch succeeded again and no warning was given, indicating freetds- bin didn't check whether the certificate expired or not. (PS: I have saved the wireshark packages, and upload these files) I am running freetds-bin 9.1-5 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to
[Bug 1376595] Re: X509 certificate verification problem
** Description changed: - Hostname verification is an important step when verifying X509 - certificates, however, people tend to miss the step or to misunderstand - the APIs when using SSL/TLS, which might cause severe man in the middle - attack and break the entire TLS mechanism. + Recently, we are trying to find SSL security problems by static anaylsis. + For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. - We believe that scrollz didn't check whether the hostname matches the - name in the SSL certificate and the expired date of the certificate. + During the experiment, we find that freetds-bin didn't check whether the + hostname matches the name in the SSL certificate and the expired date of + the certificate.The followind is details: - We found the vulnerability by static analysis, typically, a process of - verification involves calling a chain of API, and we can deduce whether - the communication process is vulnerable by detecting whether the - function call process matches a certain model. For example, when using - OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), - we should verify the certificate by calling the function - SSL_get_peer_certificate() to get the certificate. If the source code - does not match this model, then we can deduce this code is vulnerable. - What’ more , Gnutls is the same as Openssl. + 1. + function: /scrollz-2.1/source/server.c login_to_server() + problem: Hostname verification missing - Static analysis result : - /scrollz-2.1/source/server.c login_to_server() have problems. + 2. + function: /scrollz-2.1/source/server.c login_to_server() + problem: expired date check missing - We provide this result to help developers to locate the problem faster. - To verify the result: + To verify the result, we attack the software manually: + 一.Hostname verification 1. write the file /etc/hosts in order to simulate DNS hijack: 64.32.24.176 irc.mibbit.net 46.137.23.30 chat.freenode.net (PS：exchange the ip between these two irc servers) 2. connecting chat.freenode.net with scrollz /server -ssl irc.mibbit.net:6697 3. result : we connected irc.mibbit.net!! The fetch succeeded, indicating srcollz didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run scrollz to connect a normal irc server, such as irc.mibbit.net(46.137.12.30) 3. result : connect succeed!! The fetch succeeded again and no warning was given, indicating scrollz didn't check whether the certificate expired or not. I am running scrollz 2.1-1.1 in ubuntu 14.04 LTS. - for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1376595 Title: X509 certificate verification problem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/scrollz/+bug/1376595/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1376592] Re: X509 certificate verification problem
** Description changed: Recently, we are trying to find SSL security problems by static anaylsis. For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. - During the experiment, we find that freetds-bin didn't check whether the - hostname matches the name in the SSL certificate and the expired date of - the certificate. + During the experiment, we find that freetds-bin didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate.The following is details: + 1. + file: /freetds-0.91/src/tds/net.c + problem: Hostname verification missing + + 2. + file: /freetds-0.91/src/tds/net.c + problem: Hostname verification missing To verify the result, we attack the software manually: 一.Hostname verification: 1. configure the file freetds.conf : # A typical Microsoft server [sqlserver2000] host = hackbyfun.sqlserver.com port = 1433 tds version = 8.0 encrpytion = require 2.wirte the file /etc/hosts in order to simulate DNS hijack: 10.214.146.123 hackbyfun.sqlserver.com (PS: 10.214.146.123 is a normal sql server ip, its domain name is safe.sqlserver.com ) 3.connect with freetds-bin tsql -S sqlserver2000 -U sa -P your password 4.result：connect succeed!! The fetch succeeded, indicating freetds-bin didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. the same as the above process. Run freetds-bin to connect a normal sql server 3. result :connect succeed!! The fetch succeeded again and no warning was given, indicating freetds- bin didn't check whether the certificate expired or not. (PS: I have saved the wireshark packages, and upload these files) I am running freetds-bin 9.1-5 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1376592 Title: X509 certificate verification problem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/freetds/+bug/1376592/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1376595] Re: X509 certificate verification problem
** Description changed: Recently, we are trying to find SSL security problems by static anaylsis. For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. - During the experiment, we find that freetds-bin didn't check whether the + During the experiment, we find that scrollz didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate.The followind is details: 1. function: /scrollz-2.1/source/server.c login_to_server() problem: Hostname verification missing - 2. + 2. function: /scrollz-2.1/source/server.c login_to_server() problem: expired date check missing - To verify the result, we attack the software manually: 一.Hostname verification 1. write the file /etc/hosts in order to simulate DNS hijack: 64.32.24.176 irc.mibbit.net 46.137.23.30 chat.freenode.net (PS：exchange the ip between these two irc servers) 2. connecting chat.freenode.net with scrollz /server -ssl irc.mibbit.net:6697 3. result : we connected irc.mibbit.net!! The fetch succeeded, indicating srcollz didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run scrollz to connect a normal irc server, such as irc.mibbit.net(46.137.12.30) 3. result : connect succeed!! The fetch succeeded again and no warning was given, indicating scrollz didn't check whether the certificate expired or not. I am running scrollz 2.1-1.1 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. ** No longer affects: scrollz (Ubuntu) ** Summary changed: - X509 certificate verification problem + xface4-mailwatch-plugin have some SSL security problems ** Description changed: Recently, we are trying to find SSL security problems by static anaylsis. For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. - During the experiment, we find that scrollz didn't check whether the - hostname matches the name in the SSL certificate and the expired date of - the certificate.The followind is details: + During the experiment, we find that xface4-mailwatch-plugin didn't check + whether the hostname matches the name in the SSL certificate and the + expired date of the certificate.The followind is details: 1. function: /scrollz-2.1/source/server.c login_to_server() problem: Hostname verification missing 2. function: /scrollz-2.1/source/server.c login_to_server() problem: expired date check missing To verify the result, we attack the software manually: 一.Hostname verification 1. write the file /etc/hosts in order to simulate DNS hijack: 64.32.24.176 irc.mibbit.net 46.137.23.30 chat.freenode.net (PS：exchange the ip between these two irc servers) 2. connecting chat.freenode.net with scrollz /server -ssl irc.mibbit.net:6697 3. result : we connected irc.mibbit.net!! The fetch succeeded, indicating srcollz didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run scrollz to connect a normal irc server, such as irc.mibbit.net(46.137.12.30) 3. result : connect succeed!! The fetch succeeded again and no warning was given, indicating scrollz didn't check whether the certificate expired or not. I am running scrollz 2.1-1.1 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1376595 Title: xface4-mailwatch-plugin have some SSL security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xfce4-mailwatch-plugin/+bug/1376595/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380035] [NEW] scrollz doesn't check hostanem and expired time when verifying x509 certificate
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static anaylsis. For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. During the experiment, we find that scrollz didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate.The followind is details: 1. function: /scrollz-2.1/source/server.c login_to_server() problem: Hostname verification missing 2. function: /scrollz-2.1/source/server.c login_to_server() problem: expired date check missing To verify the result, we attack the software manually: 一.Hostname verification 1. write the file /etc/hosts in order to simulate DNS hijack: 64.32.24.176 irc.mibbit.net 46.137.23.30 chat.freenode.net (PS：exchange the ip between these two irc servers) 2. connecting chat.freenode.net with scrollz /server -ssl irc.mibbit.net:6697 3. result : we connected irc.mibbit.net!! The fetch succeeded, indicating srcollz didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run scrollz to connect a normal irc server, such as irc.mibbit.net(46.137.12.30) 3. result : connect succeed!! The fetch succeeded again and no warning was given, indicating scrollz didn't check whether the certificate expired or not. I am running scrollz 2.1-1.1 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. ** Affects: scrollz (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security ** Description changed: Recently, we are trying to find SSL security problems by static anaylsis. For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. - During the experiment, we find that xface4-mailwatch-plugin didn't check - whether the hostname matches the name in the SSL certificate and the - expired date of the certificate.The followind is details: + During the experiment, we find that scrollz didn't check whether the + hostname matches the name in the SSL certificate and the expired date of + the certificate.The followind is details: 1. function: /scrollz-2.1/source/server.c login_to_server() problem: Hostname verification missing 2. function: /scrollz-2.1/source/server.c login_to_server() problem: expired date check missing To verify the result, we attack the software manually: 一.Hostname verification 1. write the file /etc/hosts in order to simulate DNS hijack: 64.32.24.176 irc.mibbit.net 46.137.23.30 chat.freenode.net (PS：exchange the ip between these two irc servers) 2. connecting chat.freenode.net with scrollz /server -ssl irc.mibbit.net:6697 3. result : we connected irc.mibbit.net!! The fetch succeeded, indicating srcollz didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run scrollz to connect a normal irc server, such as irc.mibbit.net(46.137.12.30) 3. result : connect succeed!! The fetch succeeded again and no warning was given, indicating scrollz didn't check whether the certificate expired or not. I am running scrollz 2.1-1.1 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380035 Title: scrollz doesn't check hostanem and expired time when verifying x509 certificate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/scrollz/+bug/1380035/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1376595] Re: xface4-mailwatch-plugin have some SSL security problems
** Description changed: Recently, we are trying to find SSL security problems by static anaylsis. For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. During the experiment, we find that xface4-mailwatch-plugin didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate.The followind is details: 1. - function: /scrollz-2.1/source/server.c login_to_server() + function: /xfce4-mailwatch-plugin-1.1.0/libmailwatch-core/mailwatchnet-conn.c + xfce_mailwatch_net_conn_make_secure() problem: Hostname verification missing 2. - function: /scrollz-2.1/source/server.c login_to_server() + function: /xfce4-mailwatch-plugin-1.1.0/libmailwatch-core/mailwatchnet-conn.c + xfce_mailwatch_net_conn_make_secure() problem: expired date check missing To verify the result, we attack the software manually: 一.Hostname verification 1. write the file /etc/hosts in order to simulate DNS hijack: 64.32.24.176 irc.mibbit.net 46.137.23.30 chat.freenode.net (PS：exchange the ip between these two irc servers) 2. connecting chat.freenode.net with scrollz /server -ssl irc.mibbit.net:6697 3. result : we connected irc.mibbit.net!! The fetch succeeded, indicating srcollz didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run scrollz to connect a normal irc server, such as irc.mibbit.net(46.137.12.30) 3. result : connect succeed!! The fetch succeeded again and no warning was given, indicating scrollz didn't check whether the certificate expired or not. I am running scrollz 2.1-1.1 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. ** Description changed: Recently, we are trying to find SSL security problems by static anaylsis. For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. During the experiment, we find that xface4-mailwatch-plugin didn't check whether the hostname matches the name in the SSL certificate and the expired date of the certificate.The followind is details: 1. function: /xfce4-mailwatch-plugin-1.1.0/libmailwatch-core/mailwatchnet-conn.c - xfce_mailwatch_net_conn_make_secure() + xfce_mailwatch_net_conn_make_secure() problem: Hostname verification missing 2. function: /xfce4-mailwatch-plugin-1.1.0/libmailwatch-core/mailwatchnet-conn.c - xfce_mailwatch_net_conn_make_secure() + xfce_mailwatch_net_conn_make_secure() problem: expired date check missing To verify the result, we attack the software manually: 一.Hostname verification - 1. write the file /etc/hosts in order to simulate DNS hijack: - 64.32.24.176 irc.mibbit.net - 46.137.23.30 chat.freenode.net - (PS：exchange the ip between these two irc servers) + 1.configure xface4-mailwatch-plugin: + IMAP(SSL) :imap.163.com + Username : 598105904 + Password : Your password + Advanced: Use SSL/TLS on alternate port - 2. connecting chat.freenode.net with scrollz - /server -ssl irc.mibbit.net:6697 + 2. change /etc/hosts in order to simulate the DNS hijack + 113.108.16.116imap.163.com +（113.108.16.116 is QQ’s imap server） - 3. result : we connected irc.mibbit.net!! + 3. run xfce4-mailwatch-plugin to fetch the mail - The fetch succeeded, indicating srcollz didn't check the hostname + 4. result : succeed!!! + + The fetch succeeded, indicating the software didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run scrollz to connect a normal irc server, such as irc.mibbit.net(46.137.12.30) 3. result : connect succeed!! - The fetch succeeded again and no warning was given, indicating scrollz - didn't check whether the certificate expired or not. + The fetch succeeded again and no warning was given, indicating the + software didn't check whether the certificate expired or not. I am running scrollz 2.1-1.1 in ubuntu 14.04 LTS. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. ** Description changed: Recently, we are trying to find SSL security problems by static anaylsis. For example, Hostname verification is an
[Bug 1378617] Re: xxxterm has SSL security problems
** Description changed: - Hostname verification is an important step when verifying X509 - certificates, however, people tend to miss the step or to misunderstand - the APIs when using SSL/TLS, which might cause severe man in the middle - attack and break the entire TLS mechanism. + Recently, we are trying to find SSL security problems by static anaylsis. + For example, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. - We believe that xxxterm didn't check whether the hostname matches the - name in the SSL certificate and the expired date of the certificate. + During the experiment, we find that xxxterm didn't check whether the + hostname matches the name in the SSL certificate and the expired date of + the certificate.The followind is details: - We found the vulnerability by static analysis, typically, a process of - verification involves calling a chain of API, and we can deduce whether - the communication process is vulnerable by detecting whether the - function call process matches a certain model. For example, when using - OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), - we should verify the certificate by calling the function - SSL_get_peer_certificate() to get the certificate. If the source code - does not match this model, then we can deduce this code is vulnerable. - What’ more , Gnutls is the same as Openssl. + 1. + file: /xxxterm-1.10.0/xxxterm.c + problem: Hostname verification missing + 2. + file: /xxxterm-1.10.0/xxxterm.c + problem: expired date check missing - This is the result for xxxterm: - /xxxterm-1.10.0/xxxterm.c have problems. - Host name verification missing + To verify the result, we attack the software manually: - We provide this result to help developers to locate the problem faster. - - - To verify the result: 一. Hostname check 1.configure /etc/hosts in order to simulate DNS hijack - 42.62.48.90 www.facebook.com - # 42.62.48.90 is the ip of i.mi.com + 42.62.48.90 www.facebook.com + # 42.62.48.90 is the ip of i.mi.com 2. visit the website https://www.facebook.com with xxxterm 3. result : connecting succeed without any warning!!! - - The fetch succeeded, indicating xxxterm didn't check the hostname against the signee of the certificate. + The fetch succeeded, indicating xxxterm didn't check the hostname + against the signee of the certificate. 二.Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run xxxterm to visit any https website, such as https://www.youtube.com. 3. result : succeed without any warning!! The fetch succeeded again and no warning was given, indicating xxxterm didn't check whether the certificate expired or not. I am running xxxterm 1.11.3-1.2 in ubuntu 14.04 LTS. I have save the SSL connecting packages and upload these wireshark files. for more information about the importance of checking hostname: see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1378617 Title: xxxterm has SSL security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xxxterm/+bug/1378617/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380039] [NEW] pacemaker-mgmt doesn't chekc expired time and hostname when ssl connecting
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in pacemaker-mgmt, the following is details: 1. file : /pacemaker-mgmt-2.0.0+hg1141/lib/mgmt/mgmt_tls_lib.c problem : Certificate chain verification is missing 2. file : /pacemaker-mgmt-2.0.0+hg1141/lib/mgmt/mgmt_tls_lib.c problem : Hostname verification is missing More specifically , we can take hostname check for example, the function verify_certificate() can only guarantee the validity of the certificate but cannot guarantee that the host you are trying to connect is the one you intend to visit, which may lead to man-in-the-middle attack or other security issues. And other APIs have similar problems. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, my email : rainkin1...@gmail.com Thanks. ** Affects: pacemaker-mgmt (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380039 Title: pacemaker-mgmt doesn't chekc expired time and hostname when ssl connecting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker-mgmt/+bug/1380039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380038] [NEW] SSL problems: doesn't check certificate chain and hostname when ssl connecting
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in pacemaker, the following is details: 1. file : /pacemaker-1.1.6/lib/common/remote.c problem : Certificate chain verification is missing 2. file : /pacemaker-1.1.6/lib/common/remote.c problem : Hostname verification is missing More specifically , we can take hostname check for example, the function verify_certificate() can only guarantee the validity of the certificate but cannot guarantee that the host you are trying to connect is the one you intend to visit, which may lead to man-in-the-middle attack or other security issues. And other APIs have similar problems. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, my email : rainkin1...@gmail.com Thanks. ** Affects: pacemaker (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380038 Title: SSL problems: doesn't check certificate chain and hostname when ssl connecting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1380038/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380298] [NEW] some SSL security problems
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in crtmpserver, the following is details: - file : crtmpserver-apps/crtmpserver-1.0~dfsg/thelib/src/protocols/ssl /outboundsslprotocol.cpp - function : OutboundSSLProtocol::DoHandshake() - SSL method : \ - SSL_CTX_set_verify() argument :SSL_VERIFY_NONE - Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO - call SSL_get_peer_certificate():NO - call SSL_get_verify_result(): NO - According to the above result, we think the SSL connection in crtmpserver is not secure. More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Affects: crtmpserver (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security ** Description changed: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in crtmpserver, the following is details: - function: OutboundSSLProtocol::DoHandshake() - SSL method: \ - SSL_CTX_set_verify() argument: SSL_VERIFY_NONE - Have SSL_CTX_set_verify ( SSL_set_verify) callback: NO -call SSL_get_peer_certificate(): NO - call SSL_get_verify_result(): NO + -function | OutboundSSLProtocol::DoHandshake() + SSL method | \ + SSL_CTX_set_verify() argument | SSL_VERIFY_NONE + Have SSL_CTX_set_verify ( SSL_set_verify) callback | NO + call SSL_get_peer_certificate(): NO + call SSL_get_verify_result(): NO According to the above result, we think the SSL connection in crtmpserver is not secure. More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Description changed: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509
[Bug 1380304] Re: perdition have some SSL security problems
** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380304 Title: perdition have some SSL security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/perdition/+bug/1380304/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380435] [NEW] epic5's SSL connection is not secure
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in epic5, the following is details: - file : epic5/epic5-1.1.2/source/ssl.c - function : ssl_connect - SSL method : \ - call SSL_CTX_set_verify() : NOT FOUND - Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO - call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom verification) - call SSL_get_verify_result(): NO - According to the above result, we think the SSL connection in epic5 is not secure. More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Affects: epic5 (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security ** Description changed: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in epic5, the following is details: - file : epic5/epic5-1.1.2/source/ssl.c - function : ssl_connect - SSL method : \ - call SSL_CTX_set_verify() : NOT FOUND - Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO - call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom verification) - call SSL_get_verify_result(): NO - According to the above result, we think the SSL connection in epic5 is not secure. More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the - function SSL_get_peer_certificate() to get the certificate at first. If - the source code does not match this model, then we can deduce this code - is vulnerable. And other APIs have similar problems. + function SSL_get_peer_certificate() to get the certificate at first. + Then use X509 APIs or self-define function to verify the certificate we + get. If the source code does not match this model, then we can deduce + this code is vulnerable. And other APIs have similar problems. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to
[Bug 1380435] Re: epic5's SSL connection is not secure
** Description changed: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in epic5, the following is details: - file : epic5/epic5-1.1.2/source/ssl.c - function : ssl_connect - SSL method : \ - call SSL_CTX_set_verify() : NOT FOUND - Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO - call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom verification) - call SSL_get_verify_result(): NO - According to the above result, we think the SSL connection in epic5 is not secure. More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. - PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf + To verify the result we make, we attack the software manually. + + 一.Hostname verification + 1. change /etc/hosts in order to simulate the DNS hijack + 46.137.23.30 attacker.com +（46.137.23.30 is a normal irc server） + + 2. #rainkin@rainkin:~$ epic5 rainkin attacker.com:6697:::OPN:irc-ssl + + 3. result : succeed!!! + + The fetch succeeded, indicating the software didn't check the hostname + against the signee of the certificate. + + 二. Also for expired time check, + 1. change the system time to 2200 to guarantee the certificate to be expired. + + 2. run epic5 to connect to a normal irc server. + + 3. result:succeed!! + + The fetch succeeded again and no warning was given, indicating the + software didn't check whether the certificate expired or not. + + PS: I have saved the SSL connection Wireshark packages, and upload these files. + for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Attachment added: wireshark ssl conneting packages https://bugs.launchpad.net/ubuntu/+source/epic5/+bug/1380435/+attachment/4233527/+files/epic5.zip -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380435 Title: epic5's SSL connection is not secure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/epic5/+bug/1380435/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380439] [NEW] ftp-ssl's ssl connection is not secure
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in ftp-ssl : 1. ftp-ssl miss hostname check when verify x509 certificate 2. ftp-ssl miss expired time check when verify x509 certificate More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. To verify the result we make, we attack the software manually. we take expired time check for example : 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run command : ftp-ssl -z debug 192.168.68.130 (PS:192.168.68.130 is a norml ftp server) 3. result:succeed!! The fetch succeeded again and no warning was given, indicating the software didn't check whether the certificate expired or not. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Affects: netkit-ftp-ssl (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380439 Title: ftp-ssl's ssl connection is not secure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netkit-ftp-ssl/+bug/1380439/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380449] [NEW] citadel-client have some ssl security problems
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in citadel-client: 1. miss hostname check when verify x509 certificate 2. miss expired time check when verify x509 certificate More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. To verify the result we make, we attack the software manually. we take expired time check for example : 1. change the system time to 2200 to guarantee the certificate to be expired. 2. use citadel-client to connect to a citadel server with ssl 3. result:succeed!! The fetch succeeded again and no warning was given, indicating the software didn't check whether the certificate expired. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Affects: citadel-client (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380449 Title: citadel-client have some ssl security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/citadel-client/+bug/1380449/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380452] [NEW] apf-client doesn't check hostname or expired time when verifying x509 certificate
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in apf-client: 1. miss hostname check when verify x509 certificate 2. miss expired time check when verify x509 certificate More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. To verify the result we make, we attack the software manually. 一. hostnmae check: 1. configure the file /etc/hosts in order to simulate DNS hijack: hackbyfun.com 127.0.0.1 2. server(127.0.0.1) : afserver -n 127.0.0.1 -p -m -v client (127.0.0.1) : afclient -n hackbyfun.com -p 21 -m -v 3. result : succeed! The fetch succeeded again and no warning was given, indicating the software didn't check hostname. 二. expired time check : 1. change the system time to 2200 to guarantee the certificate to be expired. 2. server : afserver -n 127.0.0.1 -p -m -v client : afclient -n 127.0.0.1 -p 21 -m -v 3. result:succeed!! The fetch succeeded again and no warning was given, indicating the software didn't check the certificate expired. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Affects: apf (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380452 Title: apf-client doesn't check hostname or expired time when verifying x509 certificate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apf/+bug/1380452/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380453] [NEW] epic4 have some SSL security problems
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in epic4, the following is details: - file : epic4/epic4-2.10.1/source/ssl.c - function : SSL_FD_init - SSL method : \ - call SSL_CTX_set_verify() : NOT FOUND - Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO - call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom verification) - call SSL_get_verify_result(): NO - According to the above result, we think the SSL connection in epic4 is not secure. More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. To verify the result we make, we attack the software manually. 一.Hostname verification 1. change /etc/hosts in order to simulate the DNS hijack 46.137.23.30 attacker.com （46.137.23.30 is a normal irc server） 2. #rainkin@rainkin:~$ epic4 rainkin attacker.com:6697:::OPN:irc-ssl 3. result : succeed!!! The fetch succeeded, indicating the software didn't check the hostname against the signee of the certificate. 二. Also for expired time check, 1. change the system time to 2200 to guarantee the certificate to be expired. 2. run epic4 to connect to a normal irc server. 3. result:succeed!! The fetch succeeded again and no warning was given, indicating the software didn't check whether the certificate expired or not. PS: I have saved the SSL connection Wireshark packages, and upload these files. for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. ** Affects: epic4 (Ubuntu) Importance: Undecided Status: New ** Attachment added: wireshark ssl conneting packages https://bugs.launchpad.net/bugs/1380453/+attachment/4233644/+files/epic4.zip ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380453 Title: epic4 have some SSL security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/epic4/+bug/1380453/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380458] Re: dma have some SSL security problems
** Attachment added: wireshark ssl conneting packages https://bugs.launchpad.net/ubuntu/+source/dma/+bug/1380458/+attachment/4233649/+files/dma.zip -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380458 Title: dma have some SSL security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dma/+bug/1380458/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1380458] [NEW] dma have some SSL security problems
*** This bug is a security vulnerability *** Public security bug reported: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in dma, the following is details: - file : dma/dma-0.0.2010.06.17/crypto.c - function : smtp_init_crypto - SSL method : \ - call SSL_CTX_set_verify() : NOT FOUND - Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO - call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom verification) - call SSL_get_verify_result(): NO - According to the above result, we think the SSL connection in dma is not secure. For instance, missing hostname or expired time check when verifying x509 certificate. More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems. To verify the result we make, we attack the software manually. At first, we should configure the software environment: 1. configure the file /etc/dma/dma.conf: # $DragonFly: src/etc/dma/dma.conf,v 1.2 2008/02/04 10:11:41 matthias Exp $ # # Your smarthost (also called relayhost). Leave blank if you don't want # smarthost support. # NOTE: on Debian systems this is handled via debconf! # Please use dpkg-reconfigure dma to change this value. #SMARTHOST SMARTHOST smtp.gmail.com # Use this SMTP port. Most users will be fine with the default (25) #PORT 25 PORT 587 # Path to your alias file. Just stay with the default. #ALIASES /etc/aliases # Path to your spooldir. Just stay with the default. #SPOOLDIR /var/spool/dma # SMTP authentication AUTHPATH /etc/dma/auth.conf # Uncomment if yout want TLS/SSL support SECURETRANSFER # Uncomment if you want STARTTLS support (only used in combination with # SECURETRANSFER) STARTTLS # Uncomment if you have specified STARTTLS above and it should be allowed # to fail (opportunistic TLS, use an encrypted connection when available # but allow an unencrypted one to servers that do not support it) #OPPORTUNISTIC_TLS # Path to your local SSL certificate #CERTFILE # If you want to use plain text SMTP login without using encryption, change # the SECURE entry below to INSECURE. Otherwise plain login will only work # over a secure connection. Use this option with caution. INSECURE # Uncomment if you want to defer your mails. This is useful if you are # behind a dialup line. You have to submit your mails manually with dma -q #DEFER # Uncomment if you want the bounce message to include the complete original # message, not just the headers. #FULLBOUNCE # The internet hostname dma uses to identify the host. # If not set or empty, the result of gethostname(2) is used. # If MAILNAME is an absolute path to a file, the first line of this file # will be used as the hostname. # NOTE: on Debian systems this is handled via debconf! # Please use dpkg-reconfigure dma to change this value. MAILNAME /etc/mailname # Masquerade envelope from addresses with this address/hostname. # Use this if mails are not accepted by destination mail servers because # your sender domain is invalid. # By default, MASQUERADE is not set. # Format: MASQUERADE [user@][host] # Examples: # MASQUERADE john@ on host hamlet will send all mails as john@hamlet # MASQUERADE percolator will send mails as $username@percolator, e.g. fish@percolator # MASQUERADE herb@ert will send all mails as herb@ert 2. configure the file /etc/dma/auth.conf: # $DragonFly: src/etc/dma/auth.conf,v 1.1 2008/02/02 18:24:00 matthias Exp $ # # SMTP authentication entries (currently AUTH LOGIN only) # Format: user|my.smarthost.example.com:password 598105...@qq.com|smtp.gmail.com:Password 3. configure ~/.muttrc： set
[Bug 1380304] Re: perdition have some SSL security problems
** Description changed: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. Now, we find some SSL problems in perdition, the following is details: - file : perdition/perdition-1.19~rc4/perdition/ssl.c - function : __perdition_ssl_connection - SSL method : SSLv23 - SSL_CTX_set_verify() argument : SSL_VERIFY_PEER - Have SSL_CTX_set_verify ( SSL_set_verify) callback : YES (but accept self-signed certificate expired certificate) - call SSL_get_peer_certificate(): NO - call SSL_get_verify_result(): NO - - According to the above result, we think the SSL connection in - crtmpserver is not secure .perdition can accept self-signed certificate - certificate, which means MITM attack is possible. + According to the above result, we think the SSL connection in perdition + is not secure .perdition can accept self-signed certificate + certificate, which means MITM attack is possible. PS: for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf and more details you can contact with us, we will be very glad for your responce. Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380304 Title: perdition have some SSL security problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/perdition/+bug/1380304/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
