Since we often have issues with tracking external libs, as we tend to get stuck on a particular version - sometimes even a particular git revision - here's an interesting chance to see how iotivity can react to external changes, and especially to security issues.
iotivity no longer "ships" mbedtls, leaving it to the developer to pull it from the upstream git themselves. however, once they do, we will end up doing: git checkout -f development && git reset --hard mbedtls-2.4.2 before applying the iotivity patch and proceeding. The note below says we should upgrade to 2.6.0 to address the CVE. How should we react to this? -- mats -------- Forwarded Message -------- Subject: [oss-security] mbed TLS: CVE-2017-14032: Bypass of authentication of peer possible when the authentication mode is configured as 'optional' Date: Wed, 30 Aug 2017 22:03:46 +0200 <other envelope details elided> Hi MITRE has assigned CVE-2017-14032 for the following issue in mbed TLS: https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2017-02 > Title Bypass of authentication of peer possible when the authentication > mode is configured as 'optional' > Date 28th August 2017 > Affects All versions of mbed TLS from version 1.3.10 and up, including all > 2.1 and later releases > Not mbed TLS 1.3.9 and earlier > affected > Impact Use of the 'optional' authentication mode can permit the peer to > bypass peer authentication > Severity High > > Vulnerability > ------------- > If a malicious peer supplies an X.509 certificate chain that has more than > MBEDTLS_X509_MAX_INTERMEDIATE_CA intermediates (which by default is 8), it > could bypass authentication of the certificates, when the authentication mode > was set to 'optional' eg. MBEDTLS_SSL_VERIFY_OPTIONAL. The issue could be > triggered remotely by both the client and server sides. > > If the authentication mode, which can be set by the function > mbedtls_ssl_conf_authmode(), was set to 'required' eg. > MBEDTLS_SSL_VERIFY_REQUIRED which is the default, authentication would occur > normally as intended. > > Impact > ------ > Depending on the platform, an attack exploiting this vulnerability could allow > successful impersonation of the intended peer and permit man-in-the-middle > attacks. > > Resolution > ---------- > Affected users should upgrade to mbed TLS 1.3.21, mbed TLS 2.1.9 or mbed TLS > 2.6.0. > > Workaround > ---------- > Users should wherever possible upgrade to the newer version of mbed TLS. Where > this is not practical, users should consider if changing the authentication to > the 'required' mode MBEDTLS_SSL_VERIFY_REQUIRED is practical for their > application. References: - https://github.com/ARMmbed/mbedtls/commit/31458a18788b0cf0b722acda9bb2f2fe13a3fb32 - https://github.com/ARMmbed/mbedtls/commit/d15795acd5074e0b44e71f7ede8bdfe1b48591fc - https://bugs.debian.org/873557 _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
