Hello,

(In reply to ekaratsiolis from comment #0)
> for a project we evaluate the certification path construction and validation
> of different libraries and applications. One application on this set is
> KMail 5.1.3 with Kleopatra 2.2.0. We found a few issues which I present to
> you. Please find them at the end of the email.

Which GnuPG Version did you use for testing?

You can directly use GnuPG to test mails e.g.:

 ~/arbeit/kf5/build/gnupg/tools/gpgparsemail --crypto smime/CERT_PATH_ALGO_STRENGTH_01.eml

Most of the issues here need to be fixed upstream as KMail itself does not do any crypto, certificate checking or CRL fetching / caching. This is all done by the GnuPG System. KMail is just a fronted.
These issues should have been raised in the GnuPG tracker ( https://dev.gnupg.org ) or on one of the GnuPG Mailing lists. So apologies for the late reply but it was overlooked here a bit as the KMail developers are not really responsible.

I've opened an upstream report https://dev.gnupg.org/T3948
 
> Especially CERT_PATH_COMMON_05 is interesting. In this case a certificate
> with wrong encoding is placed in the S/MIME structure. In this case the
> signature is ignored totally and the email appears as a standard email
> without signature.

This indeed appears to be a kmail issue. Although I would argue that showing an invalid signed mail as secure as an unsigned mail is not very harmful. 

> Also the CRL tests could not be performed. Every CRL for each test is placed
> in a distinct crldp on the same server. Once the first test where one CRL is
> downloaded runs, it seems that for all later tests only the first CRL is
> used (cahcing), the new CRLs are not downloaded and the application
> evaluates the first CRL for resolving the revocation status of a
> certificate. Therefore almost every CRL test fails.

I can't really reproduce this there are crlDp's like:

 http://certpath_test_host:8095/cert_path_crl_02/cert_path_crl_02_sub_ca_crl.crl
 ldap://certpath_test_host:389 CN=cert_path_crl_02_sub_ca_crl,OU=cert_path_crl_02,dc=certpath_test_host?certificateRevocationList?base?objectClass=cRLDistributionPoint

which of course won't work for me. Again. This should be reproducible by just using GPGSM without KMail.


> Test Name | Evaluation | Expected Result | Application result |

I'll try to give it a more detailed look on Monday in the GnuPG tracker, afterwards I can probably better say if there is something that KMail does wrong, although I don't expect it (except for the minor problem where an invalid signature is not shown)


Best Regards,
Andre Heinecke

I don't think that any of the issues raised here are a big (or any) security concern. Because mails are only ever valid if the corresponding root certificate is trusted.

If you only have trustworthy root certificates (as you should) which work in your infrastructure you don't have any problem. The whole concept of GPGSM is not to trust any root certificates by default and leave it to Administrators to make the decision which roots they trust. And if they trust a root that does MD5 Signatures,.. well ok. Maybe GPGSM should no longer allow that by default. We'll look into it but so far I don't see any critical priority problem here.

I've now split this issue dump up into multiple issues assigned to their proper components. I still only see one KMail issue here, which I moved out into a standalone bug.

My evaluation is that CERT_PATH_COMMON_10 is the most serious issue as it might result in a visible good signature for an expired certificate.

I'm resolving this as upstream because all issues are reported upstream or moved into a standalone issue.


The split is:

For CERT_PATH_ALGO_STRENGTH_01 CERT_PATH_ALGO_STRENGTH_02 https://dev.gnupg.org/T3952

For CERT_PATH_COMMON_05 Bug 393675 But it might still turn out to be a GPGME issue.

For CERT_PATH_COMMON_08 CERT_PATH_COMMON_10 https://dev.gnupg.org/T3953

For CERT_PATH_COMMON_13 https://dev.gnupg.org/T3954

For CERT_PATH_EMAIL_04 https://dev.gnupg.org/T3955

You can reconstruct all test cases, certification paths and provide a pool of certificates by running the tool which is in the meanwhile online:

https://github.com/MTG-AG/cpt/

The tool creates signed emails automatically, therefore it is quite easy to test the functionality of KMail or other mail programms. You may consider integrating into a testing procedure.

Could you please tell me if publishing the report in this form is ok for you?

Thanks for the link to the testing tool.

Can you clarify which Report you mean? I have not yet received the report you had attached to the other bug. Could you please send it to me ( aheinecke@intevation.de ) or to security@gnupg.org ?

My OpenPGP Key is: https://k.gnupg.net/94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1

In general I think your findings are valid and I was able to reproduce them with gpgsm / gpgparsemail on the command line.
I would be interested about which kinds of attack you think are possible, in a properly setup PKI, through the reported issues. Please feel free to comment in the split issues I've linked in Comment 3 if you think that I underestimated the significance of an issue.

Best Regards,
Andre Heinecke

Hi,

report is on the way. About the anaylsis of the test cases I will revisit them and report in this ticket. As far as I remember revocation checking is a big issue, since the CRL is cached probably not using the CRL distribution points setting in the certificate (I believe so because each certificate has a distinct CRLDP). Therefore, if a CA produces certificates with different CRLDPs which point to CRLs with different content, the cached CRL is used for every certificate and checking revocation is not infeasible. This behaviour did not allow us to perform functional tests for example about the validity of a CRL, therefore we cannot do not know whether other issues concerning CRLs exist. Emptying the cache from within KMail/Kleopatra, which was the target application, did not produce the desired results.

Best Regards

Vangelis

Hallo,

please find an evaluation of the test cases below:

CERT_PATH_ALGO_STRENGTH_01 (and ..._02).

Lots of libraries still accept weak algorithms for compatibility reasons. This does not prohibit the user for example to use them for verifying a digital signature and accept rogue (or valid) certificates. The possibility to configure which algorithms are accepted could be an option here.

CERT_PATH_COMMON_05.

For KMail this leads to present the email as a normal email. Here someone could just flip a few bits and the receiver cannot notice that there was a problem. Wrongly encoded certificates are infamous for buffer overflows.

CERT_PATH_COMMON_08 (and ..._10).

This is important since expired certificates are allowed to be removed from the CRL. Not checking whether a certificate has expired may result to a missed revocation.

Please note that there are other so called validity models (chain model and hybrid model) where this check is not that important, in the internet PKI however the shell model is used (everything must be valid in verification time) and this check is important.

CERT_PATH_COMMON_13

This is not conforming to the specification, which allows self-signed certificates in the path. This does not happen often in practice.

CERT_PATH_EMAIL_04

This is not conforming to the specification, which mandates this certain extended key usages (see RFC 5280 [Sec. 4.2.1.12] and RFC 5750 [Sec. 4.4.4]). If a CA needs to limit the usage of a certificate (for whatever reason) this is not taken into consideration by the client.

Best Regards

Vangelis

Hi, 

thank you very much for that input.

(In reply to ekaratsiolis from comment #7)
> CERT_PATH_ALGO_STRENGTH_01 (and ..._02).
> 
> Lots of libraries still accept weak algorithms for compatibility reasons.
> This does not prohibit the user for example to use them for verifying a
> digital signature and accept rogue (or valid) certificates. The possibility
> to configure which algorithms are accepted could be an option here.

Our (GnuPG) Idea is that administrators should take care when setting up
the PKI for their Organizations, and if they don't accept root CA's which use weak
algorithms and that it is basically similar to "configure which algorithms are accepted".
That said, I do agree, MD5 Signatures should be rejected by default. That is why I opened
an issue for that.

> CERT_PATH_COMMON_05.
> 
> For KMail this leads to present the email as a normal email. Here someone
> could just flip a few bits and the receiver cannot notice that there was a
> problem.

In my opinion KMail should not show an invalid signed mail worse as an unsigned mail. An attacker could just remove the signature and be done with it. Although I agree that the error should be shown, albeit not very prominently. I really really hate the Red color in signature verification from a user experience standpoint. ;-)

In short:
As an attacker I would either send an unsigned mail or remove the signature before I change a signed mail to make it invalid. So the invalid state does not need to be shown more prominent then the unsigned state.

> Wrongly encoded certificates are infamous for buffer overflows.

I hope that the fuzzing tests which the Community regularly does against GnuPG would have detected such a problem. There were indeed several Problems in LibKSBA (the X509 Parser lib) which were fixed after fuzzing tests.

> CERT_PATH_COMMON_08 (and ..._10).
> 
> This is important since expired certificates are allowed to be removed from
> the CRL. Not checking whether a certificate has expired may result to a
> missed revocation.
> 
> Please note that there are other so called validity models (chain model and
> hybrid model) where this check is not that important, in the internet PKI
> however the shell model is used (everything must be valid in verification
> time) and this check is important.

Yes. This is bad in the GnuPG System. I raised this issue to high priority and see to it that it will be fixed in the next release of either GPGME or GnuPG, which will automatically fix any KMail version using such releases.

> CERT_PATH_COMMON_13
> 
> This is not conforming to the specification, which allows self-signed
> certificates in the path. This does not happen often in practice.

In agreement here. We have an Issue but nothing serious.

> CERT_PATH_EMAIL_04
> 
> This is not conforming to the specification, which mandates this certain
> extended key usages (see RFC 5280 [Sec. 4.2.1.12] and RFC 5750 [Sec.
> 4.4.4]). If a CA needs to limit the usage of a certificate (for whatever
> reason) this is not taken into consideration by the client.

The extended usage attributes not well supported by GnuPG. It was not yet a priority for our users / customers to fix that. But yes, it's an issue.

Thanks again,
Andre