Google está pagando más a los desarrolladores este año para proteger sus kernels de Linux. Es probable que este gesto sea el comienzo de la compañía para reforzar su control sobre el código abierto.
El movimiento de Google se produce después de la creciente amenaza a Linux del año pasado, ya que los piratas informáticos recurrieron a nuevas tácticas, como escribir cepas de malware en el lenguaje de programación Go.
La velocidad a la que se propaga el malware es asombrosa. El año pasado, hubo un aumento del 500 % en los incidentes de códigos infectados. Según Google, eso es un aumento del 2,000 por ciento desde 2017.
Sin duda, este aumento se debe a que Go permite a los piratas informáticos ser versátiles y apuntar a Windows, Mac y Linux desde la misma base de código. Además de esto, solo en 2020, hubo un aumento del 40 % en las familias de malware relacionadas con Linux.
Podemos especular sobre la cantidad de factores que impulsan este cambio, como acelerar la adopción de la nube. Pero es innegable que la brecha de mercado es muy grande.
Cápsula 8 es una empresa que se especializa en asegurar entornos de producción basados en Linux. Su científico jefe y fundador, Brandon Edwards, no espera que desaparezca esta tendencia de exploits de Linux.
«Sé que han estado trabajando en la seguridad del kernel de Linux a nivel de desarrollador. Y, obviamente, ha sido un trabajo desafiante, porque obtener la revisión y aprobación del código que se incluye en el kernel siempre parece ser una lucha». Edwards le dijo a LinuxInsider.
Tabla de Contenidos
Todo sobre la seguridad del núcleo
Los escritores de códigos tienen dos modos de operación, explicó Edwards. Uno es el modo de integridad, en el que aún puede recopilar ciertos puntos de datos del kernel que pueden ser útiles para la visibilidad.
El segundo es el modo confidencial, ni siquiera puedes hacer eso. La idea es que en el modo de integridad no se puede modificar ningún código del kernel. Pero aún puede observar el comportamiento en el kernel.
La visibilidad del código es clave para revisar la codificación de código abierto. Cómo planea intervenir Google es la principal preocupación de Edwards.
«Mi preocupación es cuando Google traza la línea. Si sus codificadores de software eliminan la visibilidad, en realidad están comprometiendo más la seguridad», advierte Edwards.
Razonó, especialmente cuando fingir o asumir las precauciones que tomaron significaba que ya no necesitaban visibilidad.
Las mitigaciones de seguridad casi siempre se pueden omitir. Por lo general, se pasa por alto de una manera que puede generalizarse. Según Edwards, las mitigaciones no son de ninguna manera un obstáculo que un adversario deba sortear de inmediato.
“Pero si tiene visibilidad u observabilidad confiables, eso significa que los atacantes deben pensar en cómo cada artefacto o efecto secundario del movimiento revela su presencia”, detalla.
Por lo tanto, la visibilidad debería poder observar las mismas medidas de mitigación de accidentes que fueron diseñadas para prevenir el accidente. Al mismo tiempo, los codificadores deben tener en cuenta los sesgos que generan mitigaciones, advierte.
«Cuando creas observabilidad, definitivamente tienes sesgos. Pero esos sesgos aún ayudan a observar cosas que no sabías que iban a suceder. Esto se puede usar por consideraciones de seguridad», dijo Edwards.
La conexión de Google con el código abierto
Google y Fundación Linux Recientemente se anunció que Google financiará a dos desarrolladores de seguridad de Linux a tiempo completo para que se centren por completo en proteger el kernel.
Este tipo de apoyo no es sorprendente para el Grupo de Google. Google ha cofinanciado a desarrolladores de seguridad de Linux para proyectos de código abierto, según funcionarios de Linux. Por ejemplo, a principios de febrero, Google donó $350 000 a la Python Software Foundation para apoyar proyectos enfocados en mejorar la seguridad de la cadena de suministro.
La organización también es miembro fundador de la Open Source Security Foundation. OSSF es un proyecto de la Fundación Linux dedicado a mejorar la seguridad del software de código abierto.
El interés de Google en mejorar la seguridad de Linux proviene de su papel como productor de software de fuente abierta, según Dan Lorenc, líder de ingeniería del equipo de seguridad de fuente abierta de Google.
«Nuestro equipo es responsable de hacer que sea fácil y seguro para Google usar software de código abierto que usamos como nuestras dependencias para impulsar casi toda nuestra infraestructura», dijo. «Además, facilite a los ingenieros de Google la producción y entrega seguras de software de código abierto en dispositivos como Chrome, Android y la nube, en todo Google».
Ambos desarrolladores de seguridad de Linux financiados por Google tienen experiencia en el mantenimiento del kernel de Linux. Eso es normal para el curso, dijo Lorenc, porque la forma en que Google lanza programas de seguridad en proyectos de software existentes es trabajar con personas que ya se han unido como mantenedores activos.
qué sucedió
Un atacante experimentado comprometió el servidor oficial PHP Git al intentar plantar malware en el código base del proyecto PHP. El pirata informático impulsó dos intentos de confirmación maliciosos utilizando el nombre y las credenciales del repositorio.
El desarrollador y mantenedor del lenguaje de programación PHP, Nikita Popov, dijo que se agregaron dos confirmaciones maliciosas al repositorio php-src a su nombre y al del creador de PHP, Rasmus Lerdorf. Las autoridades dicen que aún no saben cómo sucedió exactamente esto.
Pero según el ingeniero de software senior Nikita Popov, esto parece ser un compromiso del servidor git.php.net, no una cuenta personal de git. JetBrains y miembros grupo PHPComo resultado, el servidor git.php.net ha decidido oficialmente que mantener su propia infraestructura git es un riesgo de seguridad innecesario y detendrá el servidor git.php.net.
En su lugar, los repositorios en GitHub que anteriormente solo se reflejaban se convertirán en modeloEsto significa que los cambios deben enviarse directamente a GitHub en lugar de a git.php.net.
«Las puertas traseras en el código fuente de PHP no son nada nuevo. Pero las mitigaciones en acción subrayan cómo el código abierto y la comunidad de código abierto pueden detectar y prevenir el caos. No lo detenga, pero tal vez lo mitigue», dijo Lorenc a LinuxInsider.
Dado que PHP ejecuta el 80 por ciento de Internet, el ejemplo de PHP es un buen ejemplo, agregó, y señaló que Google se basa en Linux y que la seguridad comienza con el kernel.
«Cualquier mejora que hagamos aquí beneficiará directamente a nuestros usuarios», dijo.
Posibilidad de consecuencias graves
Compromisos como este muestran que la superficie de ataque de nuestra cadena de suministro de software es mucho más amplia de lo que parece. Los componentes como los sistemas de compilación, las herramientas de administración de código fuente y los repositorios de artefactos deben considerarse entornos críticos para la producción, como recomienda Lorenc.
«La realidad es que este incidente podría tener consecuencias de gran alcance, pero el equipo de PHP hizo un gran trabajo al detectar esto temprano y evitar que el código comprometido llegara a los usuarios finales», dijo Lorenc.
Él espera que este evento sirva como un recordatorio de que la seguridad de nuestros sistemas de compilación y control de código fuente es tan importante como nuestro entorno de producción. Los números no mienten.
no hay solución fácil
Google y otras grandes empresas tecnológicas pueden hacer o deshacer la comunidad de código abierto en función de su apoyo (a veces financiero). El objetivo es hacer que el entorno Linux sea más seguro.
«Apoyar a los mantenedores que ya están trabajando para mejorar la seguridad de código abierto es un gran primer paso», coincide Lorenc. «Pero debemos tomar la ofensiva y comenzar a desarrollar tecnología que evite todos los problemas».
Un buen ejemplo aquí es la programación con lenguajes y herramientas seguros para la memoria, agregó. Fuzzing hace un gran trabajo al encontrar errores, pero los programadores no pueden solucionarlos todos. Continuó diciendo que el nuevo modelo de desarrollo evita que se introduzcan estos errores.
El mayor desafío al que se enfrentan las grandes empresas tecnológicas para lograr estos objetivos de seguridad es no perder la batalla de la seguridad con el software de código abierto.
Esto sin duda ha llamado la atención de la industria. Pero las soluciones requieren consenso sobre los desafíos y cooperación en la implementación.
Lorenc agregó: “El problema es complejo y debe cubrir muchos aspectos: la cadena de suministro, la gestión de dependencias, la identidad y la creación de canales para principiantes.
Ahora observe dónde pertenece
Automatización de DevOps para empresas de gobierno de código abierto patrón de sonido Se estima que al menos el 80% del código en los sistemas modernos es de código abierto. Pero Lorenc señaló que no se ha acercado más a ese nivel de atención o recursos desde el punto de vista de la seguridad. El mayor desafío al que nos enfrentamos como industria es priorizar la seguridad del software de código abierto.
«La seguridad del software de código abierto llama legítimamente la atención de la industria, pero las soluciones requieren un consenso sobre los desafíos de implementación y la colaboración», instó.
