Vulnerabilidades

El sistema Micca KE700 se basa en una porción de 6 bits de un identificador para la autenticación dentro de códigos rotatorios, lo que proporciona solo 64 combinaciones posibles. Esta baja entropía permite a un atacante realizar un ataque de fuerza bruta contra un componente del código rotatorio. La explotación exitosa simplifica a un atacante predecir el siguiente código rotatorio válido, lo que otorga acceso no autorizado al vehículo.

El sistema adolece de la ausencia de una verificación de firma de módulo del kernel. Si un atacante puede ejecutar comandos en nombre del usuario root (debido a vulnerabilidades adicionales), entonces también puede cargar módulos del kernel personalizados al espacio del kernel y ejecutar código en el contexto del kernel. Dicha falla puede llevar a tomar el control de todo el sistema.<br /> <br /> Identificado por primera vez en un Nissan Leaf ZE1 fabricado en 2020.

La falla específica existe dentro de la pila Bluetooth desarrollada por Alps Alpine de la ECU de infoentretenimiento fabricada por Bosch. El problema se debe a la falta de validación adecuada de límites de los datos proporcionados por el usuario, lo que puede resultar en un desbordamiento de búfer basado en pila al recibir un paquete específico en el canal L2CAP de capa superior establecido. Un atacante puede aprovechar esta vulnerabilidad para obtener ejecución remota de código en la ECU de infoentretenimiento con privilegios de root.<br /> <br /> Identificado por primera vez en Nissan Leaf ZE1 fabricado en 2020.

El fallo específico existe dentro de la pila Bluetooth desarrollada por Alps Alpine de la ECU de infoentretenimiento fabricada por Bosch. El problema resulta de la falta de validación adecuada de límites de los datos proporcionados por el usuario, lo que puede resultar en un desbordamiento de búfer basado en pila al recibir un paquete específico en el canal L2CAP de capa superior establecido. Un atacante puede aprovechar esta vulnerabilidad para obtener ejecución remota de código en la ECU de infoentretenimiento con privilegios de root.<br /> <br /> Identificado por primera vez en el Nissan Leaf ZE1 fabricado en 2020.

Hay una vulnerabilidad de configuración errónea dentro de la ECU de infoentretenimiento fabricada por BOSCH. La vulnerabilidad se produce durante la fase de inicio de un servicio systemd específico y, como resultado, se activarán las siguientes funciones de desarrollador: el cortafuegos deshabilitado y el servidor SSH iniciado.<br /> <br /> Identificada por primera vez en el Nissan Leaf ZE1 fabricado en 2020.

El protocolo de comunicación RF en el sistema de alarma de coche Micca KE700 no cifra sus tramas de datos. Un atacante con una herramienta de intercepción de radio (p. ej., SDR) puede capturar el número aleatorio y los contadores transmitidos en texto claro, lo cual es información sensible necesaria para la autenticación.

El fallo específico existe dentro de la pila Bluetooth desarrollada por Alps Alpine de la ECU de infoentretenimiento fabricada por Bosch. El problema se debe a la falta de validación adecuada de límites de los datos proporcionados por el usuario, lo que puede resultar en un desbordamiento de búfer basado en pila al recibir un paquete específico en el canal L2CAP de capa superior establecido. Un atacante puede aprovechar esta vulnerabilidad para obtener ejecución remota de código en la ECU de infoentretenimiento con privilegios de root.<br /> <br /> Identificado por primera vez en un Nissan Leaf ZE1 fabricado en 2020.

La ECU de infoentretenimiento fabricada por Bosch utiliza un módulo RH850 para la comunicación CAN. El RH850 está conectado al infoentretenimiento a través de la interfaz INC mediante un protocolo personalizado. Existe una vulnerabilidad durante el procesamiento de solicitudes de este protocolo en el lado V850 que permite a un atacante con ejecución de código en el SoC principal de infoentretenimiento realizar ejecución de código en el módulo RH850 y posteriormente enviar mensajes CAN arbitrarios a través del bus CAN conectado.<br /> <br /> Identificada por primera vez en el Nissan Leaf ZE1 fabricado en 2020.

El plugin Ecwid by Lightspeed Ecommerce Shopping Cart para WordPress es vulnerable a la escalada de privilegios en todas las versiones hasta la 7.0.7, inclusive. Esto se debe a una comprobación de capacidad faltante en la función &amp;#39;save_custom_user_profile_fields&amp;#39;. Esto permite que atacantes autenticados, con permisos mínimos como un suscriptor, suministren el parámetro &amp;#39;ec_store_admin_access&amp;#39; durante una actualización de perfil y obtengan acceso de administrador de tienda al sitio.

El plugin Element Pack Addons para Elementor para WordPress es vulnerable a lecturas de archivos arbitrarios en todas las versiones hasta, e incluyendo, 8.3.17 a través del widget SVG y una falta de validación suficiente de archivos en la función &amp;#39;render_svg&amp;#39;. Esto hace posible que atacantes autenticados, con acceso de nivel de colaborador y superior, lean el contenido de archivos arbitrarios en el servidor, que pueden contener información sensible.

El plugin de protección contra el correo no deseado, Antispam, Cortafuegos de CleanTalk para WordPress es vulnerable a la instalación arbitraria de plugins no autorizada debido a una omisión de autorización mediante suplantación de DNS inverso (registro PTR) en la función &amp;#39;checkWithoutToken&amp;#39; en todas las versiones hasta la 6.71, inclusive. Esto permite a atacantes no autenticados instalar y activar plugins arbitrarios, lo que puede aprovecharse para lograr la ejecución remota de código si otro plugin vulnerable está instalado y activado. Nota: Esto solo es explotable en sitios con una clave API no válida.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: tegra210-quad: Proteger la comprobación de curr_xfer en el manejador IRQ<br /> <br /> Ahora que todos los demás accesos a curr_xfer se realizan bajo el bloqueo, proteger la comprobación de NULL de curr_xfer en tegra_qspi_isr_thread() con el spinlock. Sin esta protección, la siguiente condición de carrera puede ocurrir:<br /> <br /> CPU0 (hilo ISR) CPU1 (ruta de tiempo de espera)<br /> ---------------- -------------------<br /> if (!tqspi-&amp;gt;curr_xfer)<br /> // ve no-NULL<br /> spin_lock()<br /> tqspi-&amp;gt;curr_xfer = NULL<br /> spin_unlock()<br /> handle_*_xfer()<br /> spin_lock()<br /> t = tqspi-&amp;gt;curr_xfer // ¡NULL!<br /> ... t-&amp;gt;len ... // ¡Desreferencia de NULL!<br /> <br /> Con este parche, todos los accesos a curr_xfer están ahora correctamente sincronizados.<br /> <br /> Aunque todos los accesos a curr_xfer se realizan bajo el bloqueo, en tegra_qspi_isr_thread() comprueba si es NULL, libera el bloqueo y lo vuelve a adquirir más tarde en handle_cpu_based_xfer()/handle_dma_based_xfer(). Existe la posibilidad de una actualización intermedia, lo que podría causar una desreferencia de puntero NULL.<br /> <br /> Para manejar esto, añadir una comprobación de NULL dentro de los manejadores después de adquirir el bloqueo. Esto asegura que si la ruta de tiempo de espera ya ha limpiado curr_xfer, el manejador regresará de forma segura sin desreferenciar el puntero NULL.