X509 certificate verification problem

Bug #1374729 reported by Jerry Zhang
264
This bug affects 3 people
Affects Status Importance Assigned to Milestone
up-imapproxy (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism.

We believe that imapproxy 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 verfication involves calling a chain of API, and we can deduce whether the communication process is vulnerable by detecting whether the process satisfies a certain relation.
The result format is like this:
notice: Line Number@Method Name, Source File

We provide this result to help developers to locate the problem faster.

This is the result for imapproxy:
[PDG]Get_Server_conn
 [Found]SSL_connect()
 [HASH] 1168817039 [LineNo]@ 680[Kind]call-site[Char] SSL_connect()[Src] /home/roca/workspace/codebase/code/ubuntu_pkg/imapproxy/up-imapproxy-1.2.7/src/imapcommon.c
 [INFO] API SSL_new() Found! --> [HASH] 1396359115 [LineNo]@ 663[Kind]call-site[Char] SSL_new()[Src] /home/roca/workspace/codebase/code/ubuntu_pkg/imapproxy/up-imapproxy-1.2.7/src/imapcommon.c
 [Warning] SSL_CTX_new() not found!

We don't have a POC because we didn't succeed in configuring this software or don't know the way to verify the vulnerability. But through the analysis of the source code, we believe it breaks the ssl certificate verfication protocol.

for more information about the importance of checking hostname:
see http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf

Thanks.

Jerry Zhang (jerryzh168)
information type: Private Security → Public
Jerry Zhang (jerryzh168)
information type: Public → Public Security
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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

Changed in up-imapproxy (Ubuntu):
status: New → Incomplete
Revision history for this message
Roca (heboyuan) wrote :

We have contacted the upstream and check out their latest SVN. We are sure that IMAPproxy in Ubuntu packages(all version) is vulnerable due to the missing of SSL certificate validation. This is fixed in the upstream on Jan 20th 2014. Please check their latest version, the changes are mainly in https://svn.code.sf.net/p/squirrelmail/code/trunk/imap_proxy/src/main.c. The developer from upstream "added support for up to TLS v1.2; added support for ECDHE ciphers; added ability to manually specify TLS ciphers; added server certificate validation (all thanks to Emmanuel Dreyfus)". They add a option to let user decide if they want to enforce SSL certificate validation. So please fix as the upstream did.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in up-imapproxy (Ubuntu):
status: Incomplete → Expired
Richard Laager (rlaager)
Changed in up-imapproxy (Ubuntu):
status: Expired → Confirmed
Revision history for this message
Simon Arlott (sa.me.uk) wrote :

The upstream changes are still not good enough, it doesn't verify that the configured server hostname matches a name on the certificate.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.