[Bug 1376592] [NEW] X509 certificate verification problem
rainkin
598105904 at qq.com
Thu Oct 2 07:47:45 UTC 2014
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. 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
Foundations Bugs, which is subscribed to freetds in Ubuntu.
https://bugs.launchpad.net/bugs/1376592
Title:
X509 certificate verification problem
Status in “freetds” package in Ubuntu:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freetds/+bug/1376592/+subscriptions
More information about the foundations-bugs
mailing list