{"id":82793,"date":"2020-05-25T07:41:55","date_gmt":"2020-05-25T05:41:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/70-problem-s-bezopasnostyu-v-chromium-vyzvany-oshibkami-pri-rabote-s-pamyatyu"},"modified":"2020-05-25T07:41:55","modified_gmt":"2020-05-25T05:41:55","slug":"70-problem-s-bezopasnostyu-v-chromium-vyzvany-oshibkami-pri-rabote-s-pamyatyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/70-problem-s-bezopasnostyu-v-chromium-vyzvany-oshibkami-pri-rabote-s-pamyatyu","title":{"rendered":"El 70% de los problemas de seguridad en Chromium son causados por errores en la gesti\u00f3n de la memoria.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Los desarrolladores del proyecto Chromium analizaron<\/a><\/noindex> Se identificaron 912 vulnerabilidades peligrosas y cr\u00edticas en las versiones estables de Chrome desde 2015, y se lleg\u00f3 a la conclusi\u00f3n de que el 70% de ellas fueron provocadas por un manejo inseguro de la memoria (errores al trabajar con punteros en c\u00f3digo C\/C++). La mitad de estos problemas (36.1%) fueron causados por accesos a un b\u00fafer despu\u00e9s de liberar la memoria asociada (use-after-free).
\n

\"El<\/a><\/noindex><\/center><\/p>\n

Al dise\u00f1ar Chromium, se consider\u00f3 desde un inicio que en el c\u00f3digo podr\u00edan surgir errores, por lo que se apost\u00f3 fuertemente por la aplicaci\u00f3n de la aislaci\u00f3n sandbox para limitar las consecuencias de las vulnerabilidades. En la actualidad, las capacidades de aplicaci\u00f3n de esta tecnolog\u00eda han alcanzado el l\u00edmite de su potencial y fragmentar a\u00fan m\u00e1s en procesos es poco pr\u00e1ctico en t\u00e9rminos de consumo de recursos.<\/a><\/noindex>Para mantener la seguridad de la base de c\u00f3digo, Google tambi\u00e9n aplica la \" <\/p>\n

Para mantener la seguridad de la base de c\u00f3digo, Google tambi\u00e9n aplica \u00ab\", de acuerdo con la cual cualquier c\u00f3digo que se a\u00f1ada debe cumplir no m\u00e1s de dos condiciones de tres: trabajar con datos de entrada no verificados, utilizar un lenguaje de programaci\u00f3n inseguro (C\/C++) y ejecutarse con privilegios elevados. De esta regla se desprende que el c\u00f3digo para el manejo de datos externos debe ser recortado a privilegios m\u00ednimos (aislado) o debe ser escrito en un lenguaje de programaci\u00f3n seguro.<\/a><\/noindex>\u00ab, de acuerdo con el cual cualquier c\u00f3digo agregado debe cumplir con no m\u00e1s de dos condiciones de tres: trabajar con datos de entrada no verificados, utilizar un lenguaje de programaci\u00f3n inseguro (C\/C++) y ejecutarse con privilegios elevados. De esta regla se deduce que el c\u00f3digo para manejar datos externos debe ser recortado a privilegios m\u00ednimos (aislado) o debe ser escrito en un lenguaje de programaci\u00f3n seguro.<\/p>\n

MTE (Memory Tagging Extension) y la escritura de componentes en lenguajes que aseguran un manejo seguro de la memoria (Java, Kotlin, JavaScript, Rust, Swift).<\/a><\/noindex> Se espera que el trabajo se concentre en dos direcciones:<\/p>\n

Un cambio significativo en el proceso de desarrollo en C++, que no excluir\u00e1 un impacto negativo en el rendimiento (verificaciones adicionales de l\u00edmites y recolecci\u00f3n de basura). En lugar de punteros raw, se propone utilizar en el c\u00f3digo el tipo <\/p>\n