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

[Ravikumar Chennaparapu]

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> 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> 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
>> strongSwan - the Open Source VPN Solution!          www.strongswan.org
>> Institute for Networked Solutions
>> University of Applied Sciences Rapperswil
>> CH-8640 Rapperswil (Switzerland)
>> ===========================================================[INS-HSR]==
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20180105/f8b04874/attachment.html>