Los desarrolladores de Apple Safari parchean por tercera vez una vulnerabilidad de hace 9 años

Esta es la tercera vez que Apple Safari parchea la misma vulnerabilidad que se descubrió originalmente en 2013, luego reapareció en 2016 después de una actualización de código, y ahora ha sido descubierto y reparado nuevamente., de acuerdo a un Informe del Proyecto Cero de Google.

Quizás también te interese leer acerca de cómo Fracasado Google experimento “rompió” Chrome en empresas de todo el mundo.

piedra maddie

piedra maddie

El problema en cuestión se rastrea como CVE-2022-22620 (cvss 8.8) y es un uso después de la liberación error en el componente WebKit. La vulnerabilidad podría usarse para ejecutar código arbitrario., y a principios de febrero 2022, Manzana parches lanzados para este problema en Safari, iOS, iPadOS, y MacOS, advirtiendo que la vulnerabilidad puede estar ya bajo ataque.

Es casi la mitad de 2022, y parece que estamos viendo una tendencia hacia tales "vulnerabilidades zombis".. Los atacantes no necesitan nuevos errores para atacar eficazmente a los usuarios con 0-día, en cambio, pueden explotar vulnerabilidades que están estrechamente relacionadas con errores descubiertos previamente..escribe piedra maddie, investigador principal del equipo de Google Project Zero.

El año pasado, Stone ya escribió que una cuarta parte de todas las vulnerabilidades de día cero detectadas por Google Project Zero en 2022 eran estrechamente relacionado con antiguas vulnerabilidades que fueron divulgados públicamente. Como una regla, esto sucede debido a correcciones de errores incompletas.

Sin embargo, la situación con Safari es ligeramente diferente. En este caso, Apple solucionó completamente el problema en 2013, pero el parche era “dañado” en 2016, después de reestructurar el código.

No sabemos durante cuánto tiempo los atacantes aprovecharon esta vulnerabilidad., pero se sabe que la vulnerabilidad estaba presente en el código (de nuevo) por cinco años: desde diciembre 2016 a enero 2022.piedra escribe.

El experto dijo que el original 2013 El problema y un error relacionado descubierto este año están relacionados con la API History y podrían explotarse utilizando contenido web especialmente diseñado para ejecutar código arbitrario de forma remota..

Este es el mismo error, pero su activación se logra de otra manera. Esta es la razón por la que 2013 El caso de prueba no bloqueó la versión de WebKit que debería ser vulnerable a CVE-2022-22620.el investigador explicó.

Según piedra, La refactorización de código es uno de los principales problemas que enfrentan los desarrolladores.. El hecho es que los desarrolladores y los equipos de seguridad necesitan tiempo para probar las correcciones., especialmente aquellos que están relacionados con la seguridad.

En este caso, nueve años después de que se clasificara la vulnerabilidad, fijado, y el parche probado y lanzado, todo el proceso tuvo que repetirse nuevamente, sólo que esta vez bajo la presión de una explotación continua.Piedra resume.

Sobre el Autor

carina wilson

Con más de 10 años de experiencia escribiendo para medios impresos y en línea, Soy un experto en entregar una copia clara y convincente..

He escrito para una agencia líder de redacción SEO y también para algunas de las marcas más conocidas del Reino Unido., revistas y periodicos.

Deja un comentario