X509 certificate verification problem

[Jerry Zhang]

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 prayer-accountd 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 prayer-accountd:
[PDG]ssl_start_client
 [Found]SSL_connect()
 [HASH] 282435988 [LineNo]@ 660[Kind]call-site[Char] SSL_connect()[Src] /home/roca/workspace/codebase/code/ubuntu_pkg/prayer-accountd/prayer-1.3.4-dfsg1/lib/ssl.c
 [INFO] API SSL_new() Found! --> [HASH] 1396692037 [LineNo]@ 651[Kind]call-site[Char] SSL_new()[Src] /home/roca/workspace/codebase/code/ubuntu_pkg/prayer-accountd/prayer-1.3.4-dfsg1/lib/ssl.c
 [INFO] API SSL_CTX_new() Found! --> [HASH] 3247568991 [LineNo]@ 410[Kind]call-site[Char] SSL_CTX_new()[Src] /home/roca/workspace/codebase/code/ubuntu_pkg/prayer-accountd/prayer-1.3.4-dfsg1/lib/ssl.c
 [Warning] No secure SSL_Method API found! Potentially vulnerable!!!

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.

[Magnus Holmgren (holmgren)]

You're right, the client code doesn't seem to verify certificates, making TLS mostly pointless. However, traffic between prayer/prayer-session, prayer-accountd, and the backend LDAP server typically is over the loopback interface or at least a trusted LAN, not over the public Internet, making the impact low. I'll see what I can do though.

[Jerry Zhang (jerryzh168)]

Thanks Magnus, we are glad to hear that.

2014-10-17 4:04 GMT+08:00 Magnus Holmgren <email address hidden>:

> You're right, the client code doesn't seem to verify certificates,
> making TLS mostly pointless. However, traffic between prayer/prayer-
> session, prayer-accountd, and the backend LDAP server typically is over
> the loopback interface or at least a trusted LAN, not over the public
> Internet, making the impact low. I'll see what I can do though.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1374731
>
> Title:
> X509 certificate verification problem
>
> Status in “prayer” package in Ubuntu:
> New
>
> 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 prayer-accountd 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 prayer-accountd:
> [PDG]ssl_start_client
> [Found]SSL_connect()
> [HASH] 282435988 [LineNo]@ 660[Kind]call-site[Char]
> SSL_connect()[Src]
> /home/roca/workspace/codebase/code/ubuntu_pkg/prayer-accountd/prayer-1.3.4-dfsg1/lib/ssl.c
> [INFO] API SSL_new() Found! --> [HASH] 1396692037 [LineNo]@
> 651[Kind]call-site[Char] SSL_new()[Src]
> /home/roca/workspace/codebase/code/ubuntu_pkg/prayer-accountd/prayer-1.3.4-dfsg1/lib/ssl.c
> [INFO] API SSL_CTX_new() Found! --> [HASH] 3247568991 [LineNo]@
> 410[Kind]call-site[Char] SSL_CTX_new()[Src]
> /home/roca/workspace/codebase/code/ubuntu_pkg/prayer-accountd/prayer-1.3.4-dfsg1/lib/ssl.c
> [Warning] No secure SSL_Method API found! Potentially vulnerable!!!
>
> 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.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/prayer/+bug/1374731/+subscriptions
>

[Magnus Holmgren (holmgren)]

Although ... I forgot that Prayer uses the UW IMAP C client library to connect to the IMAP server. That library does verify the server name against the certificate subject name(s). Only the connections to prayer-accountd are insecure, which I guess is all you said to begin with. accountd is even less likely to run on a remote host, or at all, however.

[Magnus Holmgren (holmgren)]

Actually, SSL/TLS isn't even enabled in accountd (nor in the accountd client code in prayer-session) and in fact requires some patching to get working.