[strongSwan-dev] CERT payload (X.509 certificates) validation issue

[Andreas Steffen]

Hi Ravi,

locally loaded certificate are always trusted even if the X.509
trustchain is not complete. This also allows the use of self-signed
certificates.

Regards

Andreas

On 05.01.2018 14:10, Ravikumar Chennaparapu wrote:
> Hi Andreas,
> 
> We did some analysis and observed that issue is only seen if we use same
> certificates on both sides. 
> 
> We observed that when verify_trust_chain invokes issued_by, it is always
> referencing local certificate instead the peer certificate which is
> tampered. 
> 
> Local certificate is valid one so validation is successful and tunnel
> got established with tampered peer certificate.(only certificate
> signature content is modified).
> 
> Could you check this from your side. If needed more info regarding this
> issue, please let me know. 
> 
> Thanks and Regards,
> Ravi
> 
> 
> 
> 
> 
> On Thu, Jan 4, 2018 at 5:49 PM, Ravikumar Chennaparapu
> <ravikumar.ece at gmail.com <mailto:ravikumar.ece at gmail.com>> wrote:
> 
>     Hi Andreas,
> 
>     Thanks for the quick reply.
> 
>     Could you point out the code where peer remote cert validation
>     happens for CERT payload?
> 
>     Regards,
>     Ravi
> 
> 
> 
>     On Thu, Jan 4, 2018 at 2:18 AM, Andreas Steffen
>     <andreas.steffen at strongswan.org
>     <mailto:andreas.steffen at strongswan.org>> wrote:
> 
>         Hi Ravi,
> 
>         we are not adding received certificates to any trusted cache.
>         Per default remote certificates are never trusted and are
>         temporarily
>         added to the auth_cfg object of the IKE_SA. Full X.509 trust chain
>         verification then happens at a later stage.
> 
>         Regards
> 
>         Andreas
> 
> 
>         On 03.01.2018 14:47, Ravikumar Chennaparapu wrote:
> 
>             Hi,
> 
>             We found an issue with strongswan 5.2.2; peer is accepting
>             CERT payload
>             even though  digital signature field in CERT payload is
>             tampered.
> 
>             As per the below code, there is no validation for the peer's
>             pub key
>             certificate; peer's public key is added to the cache without any
>             validation. We do see this as a security vulnerability,
>             could you check
>             this? Is our understanding correct ?
> 
> 
>             static void process_x509(cert_payload_t *payload, auth_cfg_t
>             *auth,
>             cert_encoding_t encoding, bool *first)
>             {
>             certificate_t *cert;
>             char *url;
> 
>             cert = try_get_cert(payload);
>             if (cert)
>             {
>             if (*first)
>             { /* the first is an end entity certificate */
>             DBG1(DBG_IKE, "received end entity cert \"%Y\"",
>             cert->get_subject(cert));
>             auth->add(auth, AUTH_HELPER_SUBJECT_CERT, cert);
>             *first = FALSE;
>             }
>             else
>             {
>             DBG1(DBG_IKE, "received issuer cert \"%Y\"",
>             cert->get_subject(cert));
>             auth->add(auth, AUTH_HELPER_IM_CERT, cert);
>             }
>             }
>             else if (encoding == ENC_X509_HASH_AND_URL)
>             {
>             /* we fetch the certificate not yet, but only if
>             * it is really needed during authentication */
>             url = payload->get_url(payload);
>             if (!url)
>             {
>             DBG1(DBG_IKE, "received invalid hash-and-url "
>             "encoded cert, ignore");
>             return;
>             }
>             url = strdup(url);
>             if (*first)
>             { /* first URL is for an end entity certificate */
>             DBG1(DBG_IKE, "received hash-and-url for end entity cert
>             \"%s\"",
>             url);
>             auth->add(auth, AUTH_HELPER_SUBJECT_HASH_URL, url);
>             *first = FALSE;
>             }
>             else
>             {
>             DBG1(DBG_IKE, "received hash-and-url for issuer cert
>             \"%s\"", url);
>             auth->add(auth, AUTH_HELPER_IM_HASH_URL, url);
>             }
>             }
>             }
> 
>             Thanks and Regards,
>             Ravi
> 
> 
>         -- 
>         ======================================================================
>         Andreas Steffen                       
>          andreas.steffen at strongswan.org
>         <mailto:andreas.steffen at strongswan.org>
>         strongSwan - the Open Source VPN Solution!         
>         www.strongswan.org <http://www.strongswan.org>
>         Institute for Networked Solutions
>         University of Applied Sciences Rapperswil
>         CH-8640 Rapperswil (Switzerland)
>         ===========================================================[INS-HSR]==
> 
> 
> 

-- 
======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2945 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20180106/fdb7f31f/attachment.bin>