Home Assistant Core is an open source home automation that puts local control and privacy first. Affected versions are subject to a…
GitHub_M·CWE-940·Published 2025-02-18
Home Assistant Core is an open source home automation that puts local control and privacy first. Affected versions are subject to a potential man-in-the-middle attacks due to missing SSL certificate verification in the project codebase and used third-party libraries. In the past, `aiohttp-session`/`request` had the parameter `verify_ssl` to control SSL certificate verification. This was a boolean value. In `aiohttp` 3.0, this parameter was deprecated in favor of the `ssl` parameter. Only when `ssl` is set to `None` or provided with a correct configured SSL context the standard SSL certificate verification will happen. When migrating integrations in Home Assistant and libraries used by Home Assistant, in some cases the `verify_ssl` parameter value was just moved to the new `ssl` parameter. This resulted in these integrations and 3rd party libraries using `request.ssl = True`, which unintentionally turned off SSL certificate verification and opened up a man-in-the-middle attack vector. This issue has been addressed in version 2024.1.6 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
Home Assistant Core is an open source home automation that puts local control and privacy first. Affected versions are subject to a potential man-in-the-middle attacks due to missing SSL certificate verification in the project codebase and used third-party libraries. In the past, `aiohttp-session`/`request` had the parameter `verify_ssl` to control SSL certificate verification. This was a boolean value. In `aiohttp` 3.0, this parameter was deprecated in favor of the `ssl` parameter. Only when `ssl` is set to `None` or provided with a correct configured SSL context the standard SSL certificate verification will happen. When migrating integrations in Home Assistant and libraries used by Home Assistant, in some cases the `verify_ssl` parameter value was just moved to the new `ssl` parameter. This resulted in these integrations and 3rd party libraries using `request.ssl = True`, which unintentionally turned off SSL certificate verification and opened up a man-in-the-middle attack vector. This issue has been addressed in version 2024.1.6 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
## Summary Problem: Potential man-in-the-middle attacks due to missing SSL certificate verification in the project codebase and used third-party libraries. ## Details In the past, `aiohttp-session`/`request` had the parameter `verify_ssl` to control SSL certificate verification. This was a boolean value. In `aiohttp` 3.0, this parameter was deprecated in favor of the `ssl` parameter. Only when `ssl` is set to `None` or provided with a correct configured SSL context the standard SSL certificate verification will happen. When migrating integrations in Home Assistant and libraries used by Home Assistant, in some cases the `verify_ssl` parameter value was just moved to the new `ssl` parameter. This resulted in these integrations and 3rd party libraries using `request.ssl = True`, which unintentionally turned off SSL certificate verification and opened up a man-in-the-middle attack vector. Example: https://github.com/home-assistant/core/blob/c4411914c2e906105b765c00af5740bd0880e946/homeassistant/components/discord/notify.py#L84 When you scan the libraries used by the integrations in Home Assistant, you will find more issues like this. The general handling in Home Assistant looks good, as `homeassistant.helpers.aoihttp_client._async_get_connector` handles it correctly. ## PoC 1. Check that expired.badssl.com:443 gives an SSL error in when connecting with curl or browser. 2. Add the integration adguard with the setting `host=expired.badssl.com`, `port=443`, `use-ssl=true`, `verify-ssl=true`. 3. Check the logs - you get a HTTP 403 response. Expected behavior: 1. The integration log shows an `ssl.SSLCertVerificationError`. The following code shows the problem with `ssl=True`. No exception is raised when `ssl=True` (Python 3.11.6). ``` import asyncio from ssl import SSLCertVerificationError import aiohttp BAD_URL = "https://expired.badssl.com/" async def run_request(verify_ssl, result_placeholder: str): async with aiohttp.ClientSession() as session: exception_fired: bool = False try: await session.request("OPTIONS", BAD_URL, ssl=verify_ssl) except SSLCertVerificationError: exception_fired = True except Exception as error: print(error) else: exception_fired = False print(result_placeholder.format(exception_result=exception_fired)) # Case 1: ssl=False --> expected result: No exception asyncio.run(run_request(False, "Test case 1: expected result: False - result: {exception_result}")) # Case 2: ssl=None --> expected result: Exception asyncio.run(run_request(None, "Test case 2: expected result: True - result: {exception_result}")) # Case 3: ssl=True --> expected result: No Exception asyncio.run(run_request(True, "Test case 3: expected result: False - result: {exception_result}")) ```
## Summary Problem: Potential man-in-the-middle attacks due to missing SSL certificate verification in the project codebase and used third-party libraries. ## Details In the past, `aiohttp-session`/`request` had the parameter `verify_ssl` to control SSL certificate verification. This was a boolean value. In `aiohttp` 3.0, this parameter was deprecated in favor of the `ssl` parameter. Only when `ssl` is set to `None` or provided with a correct configured SSL context the standard SSL certificate verification will happen. When migrating integrations in Home Assistant and libraries used by Home Assistant, in some cases the `verify_ssl` parameter value was just moved to the new `ssl` parameter. This resulted in these integrations and 3rd party libraries using `request.ssl = True`, which unintentionally turned off SSL certificate verification and opened up a man-in-the-middle attack vector. Example: https://github.com/home-assistant/core/blob/c4411914c2e906105b765c00af5740bd0880e946/homeassistant/components/discord/notify.py#L84 When you scan the libraries used by the integrations in Home Assistant, you will find more issues like this. The general handling in Home Assistant looks good, as `homeassistant.helpers.aoihttp_client._async_get_connector` handles it correctly. ## PoC 1. Check that expired.badssl.com:443 gives an SSL error in when connecting with curl or browser. 2. Add the integration adguard with the setting `host=expired.badssl.com`, `port=443`, `use-ssl=true`, `verify-ssl=true`. 3. Check the logs - you get a HTTP 403 response. Expected behavior: 1. The integration log shows an `ssl.SSLCertVerificationError`. The following code shows the problem with `ssl=True`. No exception is raised when `ssl=True` (Python 3.11.6). ``` import asyncio from ssl import SSLCertVerificationError import aiohttp BAD_URL = "https://expired.badssl.com/" async def run_request(verify_ssl, result_placeholder: str): async with aiohttp.ClientSession() as session: exception_fired: bool = False try: await session.request("OPTIONS", BAD_URL, ssl=verify_ssl) except SSLCertVerificationError: exception_fired = True except Exception as error: print(error) else: exception_fired = False print(result_placeholder.format(exception_result=exception_fired)) # Case 1: ssl=False --> expected result: No exception asyncio.run(run_request(False, "Test case 1: expected result: False - result: {exception_result}")) # Case 2: ssl=None --> expected result: Exception asyncio.run(run_request(None, "Test case 2: expected result: True - result: {exception_result}")) # Case 3: ssl=True --> expected result: No Exception asyncio.run(run_request(True, "Test case 3: expected result: False - result: {exception_result}")) ```
Home Assistant Core es una automatización de origen de código abierto que pone primero el control local y la privacidad. Las versiones afectadas están sujetas a los posibles ataques de hombre en el medio debido a la verificación de certificado SSL faltante en la base de código del proyecto y usaron de terceros librerías. En el pasado, `aiohttp-session`/` request 'tenía el parámetro `verify_ssl` para controlar la verificación del certificado SSL. Este era un valor booleano. En `aiohttp` 3.0, este parámetro estaba desapercibido a favor del parámetro` SSL`. Solo cuando `SSL` se establece en` None` o se proporciona con un contexto SSL configurado correcto, la verificación de certificado SSL estándar ocurrirá. Al migrar las integraciones en el Asistente de inicio librerías Aries utilizados por el Asistente de inicio, en algunos casos el valor del parámetro `Verify_SSL` se movió al nuevo parámetro` SSL`. Esto dio como resultado estas integraciones y librerías usando `request.ssl ??= true`, que desactivó involuntariamente la verificación del certificado SSL y abrió un vector de ataque de hombre en el medio. Este problema se ha abordado en la versión 2024.1.6 y se recomienda a todos los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 3.1 | Primary | cve.org | 7.0 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L |
| 3.1 | Primary | cve.org | 7.0 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L |
| 3.1 | Secondary | NVD | 7.0 | 2.2 | 4.7 | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L |
| 3.1 | Secondary | GHSA | 7.0 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L |