Potential Vulnerability for X509 Certificate Verification

[Jerry Zhang]

When using OpenSSL, one needs to follow a certain process to ensure the verification of the certificate is successful. But we believe that jabberd2 didn't follow the correct process of verifying X509 certificate which makes certain attacks possible.

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 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 jabberd2:
[PDG]_sx_ssl_handshake
 [Found]SSL_connect()
 [HASH] 2773927385 [LineNo]@ 218[Kind]call-site[Char] SSL_connect()[Src] /home/roca/workspace/codebase/code/ubuntu_pkg/jabberd2/jabberd2-2.2.8/sx/ssl.c
 [Warning] SSL_new() not found!

The result means that jabberd2 uses SSL connection, but it doesn't do this through the SSL_new() API, so the connection will subject to attack since there is no way to verify the certificate this way.

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.

[Tomasz Sterna (smoku)]

These SSL_new() ?
https://github.com/jabberd2/jabberd2/search?q=SSL_new

[Jerry Zhang (jerryzh168)]

In this case, our algorithm is not accurate. Actually it didn't find SSL_new for other reasons. So the above result can't support our conclusion.

But later we verified the code manually and found that jabberd2 didn't call SSL_CTX_set_verify(), so it must be that jabberd2 didn't verify the certificate.

Sorry for the confusion.

[Jerry Zhang (jerryzh168)]

Sorry, another thing to correct. This is not a recent result of our algorithm, we didn't find the vulnerability manually...

[Marc Deslauriers (mdeslaur)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

[Marc Deslauriers (mdeslaur)]

Please disregard the last comment, it was a triaging script error.

[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

[Tomasz Sterna (smoku)]

SRSLY guys, I have already shown you how to use code search feature of GitHub.

If you would bother to enter https://github.com/jabberd2/jabberd2/search?q=SSL_CTX_set_verify you wuld notice, that SSL verify mode is configurable in jabberd2.

I am tired of this "security" guesswork hogging my time and creating false "security" buzz around jabberd2.
I will disregard this "Potential Vulnerability" until you had demonstrated e *real* issue over a real *working* and *current* instance of jabberd2.

[Launchpad Janitor (janitor)]

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