Otro día, otro accidente en el software de dispositivos automotrices.
Esta vez, el error se encontró en el sistema de infoentretenimiento de modelos Mazda más antiguos de 2014-2017. Los conductores informaron que sus receptores de radio HD colapsaron cuando se conectaban a una estación de radio local. La radio y su pantalla, las capacidades de bluetooth, los mapas incorporados y los relojes digitales estaban todos fritos.
Según los informes , la falla del sistema se produjo por un simple error de codificación que se produjo cuando la emisora de radio transmitió imágenes sin la extensión requerida en los nombres de los archivos.
Si bien los frustrados propietarios de Mazda que esperaban su nueva CMU (Unidad maestra de conectividad) de $ 1500 podrían no estar de acuerdo, este error en particular era relativamente inofensivo, lo que resultó en un daño mínimo.
Desafortunadamente, es probable que sigamos escuchando informes de fallas de software en los sistemas de los vehículos y, a medida que los vehículos dependen cada vez más del código , los riesgos de vulnerabilidades que afectan la seguridad crecen exponencialmente. ¿Quién sabe cómo afectará el próximo error a los conductores?
Cómo un simple error de codificación corrompió los sistemas conectados de Mazda
No se publicaron los detalles completos del error de codificación que condujo al bloqueo de las CMU de Mazda, pero podemos suponer que se trataba de un tipo de vulnerabilidad de desreferencia NULL.
Así es como funciona:
En el lenguaje de programación C, existe una función llamada strchr. Esta función recibe dos parámetros: un puntero a una cadena y un carácter, e intenta encontrar el carácter dentro de la cadena, devolviendo un puntero al resultado encontrado. Si la función falla, se devuelve un puntero NULL.
Entonces, el programa probablemente intentará comprender la extensión del archivo específico que recibió.
Para encontrar la extensión, probablemente se use una función similar a strcmp. Esta función recibe dos punteros y compara sus contenidos. Eventualmente, la comparación se realiza a través de un puntero de desreferenciación.
Desreferenciar es la acción de tomar el valor al que apunta el puntero.
En este caso específico, el puntero NULL se envió a esta función y, aunque la función intentó desreferenciar el valor de NULL, obtuvo una excepción.
Este tipo de vulnerabilidad en el código se puede evitar fácilmente comprobando si el puntero recibido es diferente de NULL.
Prevención y Mitigación
La prevención de este tipo de problema en la etapa de desarrollo requiere que los ingenieros de software sigan estándares de codificación seguros que definen cómo escribir código para evitar vulnerabilidades de seguridad en el software del dispositivo.
Sin embargo, aunque la codificación segura es clave para prevenir vulnerabilidades de software, es solo un factor.
La codificación siempre será propensa a errores humanos, incluso cuando la escriban los programadores más experimentados. Además de eso, la mayoría de los productos en los que confiamos hoy dependen en gran medida de una cadena de suministro que incluye software de código abierto y de terceros en el que sus programadores no participaron en la escritura.
Los coches inteligentes necesitan una seguridad más inteligente
Los fabricantes de automóviles están invirtiendo mucho en sofisticados controles de seguridad automatizados, desde la dirección y los frenos hasta la detección de puntos ciegos y todo lo demás. Teniendo en cuenta el hecho de que estos sistemas se han vuelto cada vez más dependientes del software, ¿por qué no se presta la misma atención a la seguridad del software automotriz ?
El costo de una vulnerabilidad de software en dispositivos automotrices se dispara si se descubre después de que el automóvil sale a la carretera. Más allá del precio de pausar la producción o emitir retiros, los errores de software podrían resultar en más que la inconveniencia de un sistema de información y entretenimiento averiado. Cuando se encuentran en características críticas de seguridad, en realidad podrían afectar vidas humanas.
La atención insuficiente a la seguridad del software en los dispositivos automotrices puede convertir a los automóviles en bombas de relojería. Los automóviles altamente automatizados de hoy en día exigen que los OEM amplíen su enfoque más allá de la seguridad física del automóvil para incluir la seguridad del software, desde las primeras etapas de diseño hasta el seguimiento de las versiones de software que ya están en la carretera.
El camino hacia la seguridad automotriz: software seguro
Garantizar dispositivos automotrices seguros y libres de vulnerabilidades requiere pasos adicionales más allá de la codificación segura o el seguimiento manual de errores. Es por eso que el firmware y el código en todos los dispositivos deben monitorearse continuamente en busca de vulnerabilidades, para detectar y corregir errores rápidamente. La seguridad de productos automatizada ayuda a los equipos a abordar los riesgos de seguridad antes, no después, de que las empresas aparezcan en los titulares.
Una plataforma avanzada de seguridad de productos automotrices, como Cybellum , permite a los equipos de seguridad de productos rastrear cada línea de código en su software, ya sea que se haya creado internamente u obtenido de un tercero o de código abierto, y garantizar que se detecten las vulnerabilidades del software. y abordarse de manera temprana, antes de que puedan causar lesiones costosas a las personas y daños graves a la reputación de los fabricantes.
El accidente de información y entretenimiento de Mazda demuestra una vez más que un simple error de codificación puede causar un caos imprevisto. Afortunadamente, esta vez, el daño se limitó al infoentretenimiento y a los conductores frustrados temporalmente, además de algunos titulares. Los fabricantes de automóviles deben comenzar a priorizar la seguridad de los dispositivos para garantizar que todo el software en el que se basan sus productos no los desvíe de la carretera.
Fuente: https://www.bleepingcomputer.com
