dma have some SSL security problems

[rainkin]

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.

三. How we prove the result we got?

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
<email address hidden>|smtp.gmail.com:Password

3. configure ~/.muttrc：
set sendmail="/usr/sbin/dma -f <email address hidden>"
set folder="~/Mail"
set mbox="~/Mail/inbox"
#set mbox_type=maildir
set spoolfile="~/Mail/inbox"
set postponed="~/Mail/postponed"
set record="~/Mail/sent"
my_hdr From: <email address hidden>

Ok ,let's start!

for expired time check,
1. change the system time to 2200 to guarantee the certificate to be expired.

2. run mutt to send email

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.

[Marc Deslauriers (mdeslaur)]

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/SecurityTeam/UpdateProcedures

[Launchpad Janitor (janitor)]

[Expired for dma (Ubuntu) because there has been no activity for 60 days.]