perdition have some SSL security problems
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
perdition (Ubuntu) |
Expired
|
Undecided
|
Unassigned |
Bug Description
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_
[Example 2]
//check the built-in verification result after the SSL handshake
if(SSL_
{
//PASS
}
else
{
//FAIL
}
2. Using custom verification.
[Example 3]
X509* usrcert = SSL_get_
rootCertStore = X509_STORE_new();
.. ..
ctx = X509_STORE_
ret = X509_STORE_
ret = X509_verify_
This example read the certificate out using SSL_get_
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_
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/
-------
function : __perdition_
-------
SSL method : SSLv23
-------
SSL_CTX_
-------
Have SSL_CTX_set_verify ( SSL_set_verify) callback : YES (but accept self-signed certificate & expired certificate)
-------
call SSL_get_
-------
call SSL_get_
-------
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://
and more details you can contact with us, we will be very glad for your responce.
Thanks.
information type: | Private Security → Public Security |
description: | updated |
description: | updated |
description: | updated |
Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https:/ /wiki.ubuntu. com/SecurityTea m/UpdateProcedu res