aiccu's SSL connection is not secure

[rainkin]

Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, 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.

Now, we find some SSL problems in aiccu, the following is details:

1.
"/aiccu-20070115/common/common.c
 Certificate chain verification is missing

2.
"/aiccu-20070115/common/common.c
 Hostname verification is missing

More specifically , we can take hostname check for example, the function verify_certificate() can only guarantee the validity of the certificate but cannot guarantee that the host you are trying to connect is the one you intend to visit, which may lead to man-in-the-middle attack or other security issues. And other APIs have similar problems.

PS: 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, my email : <email address hidden>

Thanks.

[Jeroen Massar (massar)]

On 2014-10-11 10:24, rainkin wrote:
> ** Description changed:
>
> Recently, we are trying to find SSL security problems by static
> analysis. For example, as we all know, Hostname verification is an
> important step when verifying X509 certificates, however, 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.

While static analysis is a good thing to identify possible problems, it
does not match the intent of code.

> Now, we find some SSL problems in aiccu, the following is details:

As tic.sixxs.net (and other TIC server instances) had a CAcert or
self-signed certificate, the check for the certificate is not present
and cannot be enforced.

Adding a hostname check or a certificate chain check would thus break
deployed systems.

The only thing that the TLS support adds is hiding of the ephemeral
tunnel key that is transmitted for heartbeat and AYIYA tunnels.
That key changes every once in a while, thus it does not matter.

Any organization that is able to intercept/redirect traffic or change
DNS can break the TIC procedure already, in a same way they can perform
that attack on the actual tunnel.

Note that the actual tunnels are also in clear text. If the adversary
can redirect/intercept traffic, they can better target that.

Greets,
 Jeroen

[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 aiccu (Ubuntu) because there has been no activity for 60 days.]