Hackeado el repositorio del código fuente de PHP: fuerte alarma para el lenguaje usado por casi el 80% de todas las webs

Este domingo 28 de marzo, hackers lograron acceder al repositorio Git interno del lenguaje de programación PHP y lograron añadir una puerta trasera a su código fuente. Estamos hablando del lenguaje del lado del servidor más usado en toda la web y que se calcula está en uso en el 79.1% de todos los sitios web. Como explican en las listas de correo de PHP, el ataque insertó dos cambios maliciosos en el repositorio php-src, y aunque aún se desconoce la causa y ya hay una investigación, todo apunta a que el servidor git.php.net fue comprometido.

[#1 mecha]

Un rato sensacionalista el titular, ya que el fallo se ha resuelto rápido y en caso de no haberlo hecho solo afectaría a la última versión de PHP, que se debe usar en el 0% de las webs públicas, calculo. El titular habla de un 80% .
La noticia en sí es interesante de cualquier manera. Cuidado con el código, que cualquiera puede tocar 2 líneas y volver un proyecto sensible a ataques.

[#2 Desactivado]

#1 y más teniendo en cuenta que hay por ahí cosas que apenas funcionan en las primeras ramas de la 5

[#3 mr_b]

#1 Bueno, el titular habla del lenguaje en sí (a eso se refiere lo del “casi el 80%”), no de la última versión (la hackeada). Pero ciertamente estuve a punto de quitar esa parte del titular por, precisamente sensacionalismo, aunque al final no lo hice por no desvirtuar la noticia real ¯\_(ツ)_/¯

/cc #2

[#11 Desactivado]

#3 Al final, todo mal.

[#28 ny80]

#3 Sí, técnicamente el titular no dice ninguna mentira, pero es como tantos titulares manipuladores, en los que se ponen juntos dos conceptos para que en una lectura rápida parezca otra cosa. Y como la mayoría de la gente lee en diagonal incluso un titular de dos líneas pues ya está liada, pues parece que afecta al 80% de las webs en vez de ser solo un apunte sobre el uso general de cualquier versión PHP que, básicamente, sobraba en el titular y estaba mejor, si acaso, en el cuerpo del artículo.

[#6 almoss]

#1 dejo esto por aquí, que me llamó mucho la atención en su día
https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/

[#10 Remenad0r]

#0 #1 duplicada

[#15 mecha]

#10 ¿y el original? no lo ví

[#12 coderspirit]

#1 La alarma no creo que sea tanto en sí por los efectos concretos de este ataque como por lo que supone que se haya podido llevar a cabo. Ahora quien narices se fía de los miles de commits anteriores. Y si no me crees, busca en Google "SolarWinds": https://en.wikipedia.org/wiki/SolarWinds#2019%E2%80%932020_supply_chain_attacks

[#19 Nuevo_1666]

#1 totalmente de acuerdo.



No tengo ni pu.. idea de informática.

[#27 chavi]

#1 Los desarrolladores no firman los push?

[#41 LLort_II]

#27 Todas las subidas de código son trazables a un usuario.

Aquí el problema es que alguien subió código malicioso, otra persona (s) lo revisó y lo aceptó, y el código fue publicado.

[#37 Desactivado]

#1 habla que el lenguaje lo usan el 80% de las webs, no que se vean afectadas el 80%

[#7 coderspirit]

Y firmad criptográficamente vuestros putos commits! me cago en dios. Que nadie lo hace, y es trivial automatizar eso.

[#8 Heni]

#7 "El código malicioso que se añadió al código fuente se hizo a través de las cuentas de dos de los miembros del equipo core de PHP, Rasmus Lerdorf and Nikita Popov, pero ya ambos expresaron no estar involucrados"

Entiendo que les juankearon las cuantas (posiblemente los pcs) daría igual que se firmasen o no los commits, dicho de otra manera, si pudieron subirlo con sus cuentas oficiales el intruso también podría haber firmado el commit con su certificado ya que debió conseguir acceso a sus equipos.

[#9 coderspirit]

#8 No habría dado igual. No les hackearon cuenta alguna, hackearon directamente el servidor git. Sin firma criptográfica es trivial hacer commits en nombre de otra persona, atribuyéndoles maliciosamente la autoría de estos.

Ahondando en eso, yo puedo hacer commits en nombre de mis compañeros de trabajo, sin hackearles las cuentas, ni hackear nada en absoluto... porque no firman sus commits.

Si resulta que los desarrolladores habituales firman sus commits, un commit no firmado canta a la vista, e incluso puede ser rechazado de forma automática. Si al atacante le da por firmar el commit con otra clave, entonces se da que:
1. Se podría verificar la firma contra un listado verificado de claves válidas.
2. Si no hubiera listado de claves válidas, aun seria posible (y mas fácil que sin firmas) ver que hay algo raro ahí, por el cambio súbito en la clave usada para firmar.
3. Y en caso de haber listado de claves válidas, sí, también es cierto que este podría verse comprometido. Pero eso requiere mas tiempo, recursos y conocimiento, al punto de que seguramente no estaría al alcance de muchos atacantes.

[#20 Heni]

#9 Gracias por la info

[#22 coderspirit]

#17 A esto https://blog.gruntwork.io/how-to-spoof-any-user-on-github-and-what-to-do-to-prevent-it-e237e95b8deb , lo explico en #9 , aunque sin entrar en detalles.

[#35 Desactivado]

#22 Gracias. Parece que bitbucket, lo que uso y llevo usando vidas, aún no lo tiene. Habrá que esperar.

https://jira.atlassian.com/browse/BCLOUD-3166

[#14 mecha]

#7 hace ya años, cuando empecé con esto de git descubrí que en los commits puedes poner el autor al hacer el envío sin más. Ojiplático me quedé.
Es cierto que se pueden firmar como tu bien dices, pero sorprendentement no siempre se hace esto y luego llegan los commits sospechosos y cualquiera dice nada. ¡Hay que firmar los commits apropiadamente!

[#23 Desactivado]

#14 en los commits puedes poner el autor al hacer el envío sin más

Eso tiene mucho sentido. Aunque suele ser transparente para el usuario, en cada commit hay dos sujetos: author y commiter.

Si, por ejemplo, yo te envío un parche para que lo apliques sobre el código, lo normal es que me incluyeses a mí como author y a ti como commiter. En este caso de lo que se habla es de la autenticación del commiter.

Otro caso común es de un cliente que comita en tu nombre (como puede ser el cliente web de GitHub). Tú te autenticas contra un tercero (el servidor de autenticación) y el cliente firma como commiter incluyéndote ti como author.

[#16 coderspirit]

#7 Por si hay interés, aquí 3 guías sobre como hacer lo de firmar commits con PGP:

- Documentación de Git: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
- Documentación de Github: https://help.github.com/en/github/authenticating-to-github/signing-commits
- Documentación de Gitlab: https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/

[#17 Desactivado]

#7 Hola, ¿a qué te refieres?

Cada uno de mis compañeros hace sus subidas con su cuenta. ¿Para qué serviría firmarlos?

[#43 daphoene]

#17 Da igual con qué cuenta se suban, tú puedes hacer un commit como si lo hiciera un compañero tuyo:

https://blog.gruntwork.io/how-to-spoof-any-user-on-github-and-what-to-do-to-prevent-it-e237e95b8deb

Por eso, si es importante en tu organización diferenciar quién ha subido qué, se deben firmar los commits.

No uses esta información para hacer el mal...

[#49 Desactivado]

#43 En bitbucket aún no se puede


https://jira.atlassian.com/browse/BCLOUD-3166

[#51 daphoene]

#49 Muy mal por su parte.

Para proyectos realmente serios, es un mínimo obligatorio.

[#24 Desactivado]

#7 Nada como rechazar automáticamente cualquier commit sin firma para que esa recomendación no caiga en saco roto

[#5 Desactivado]

La Wordpress Web.

[#13 Tefnet]

#5 WordPress es usado por el 40% de las webs aprox. De lejos es el proyecto php mas extendido. El otro 40% son otros proyectos php de todo tipo.

[#32 SalsaDeTomate]

#5 ¿Y eso a qué viene? Se está hablando de un lenguaje de programación, no de que un software use ese lenguaje.

[#33 Desactivado]

#32 Viene a que el mayor contribuidor individual a que casi toda la web sea PHP es WordPress.

[#18 LeDYoM]

Lo bueno del PHP es que sólo puede mejorar

[#34 Desactivado]

#18 me estoy imaginando a los hackers solucionando vulnerabilidades para hacer su trabajo un poco más emocionante

[#21 xyria]

Que seis líneas de código —si no recuerdo mal— puedan comprometer el 80% de la web, dice poco, o mucho, según se mire, del lenguaje de ¿programación? subyacente.

Descalificaciones e insultos debajo de la línea, please
_______________________________________________________

[#25 Desactivado]

#21 Desde luego no es fácil elogiar a PHP. Pero me temo que en este caso cualquier lenguaje de alto nivel es susceptibe de un ataque similar (los de bajo nivel también, pero serían unas cuantas líneas más ). Lo que dice este ataque es mucho, pero nada bueno, del flujo de desarrollo de PHP.

[#30 tunic]

#c-25" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3481299/order/25">#25 Desde luego no es fácil elogiar a PHP.

No te creas, es bien fácil. Por ejemplo, PHP permite herencia horizontal mediante Traits desde PHP 5.4 (marzo de 2012), cosa si no me equivoco ha añadido por ejemplo C# en 2019, o que tiene Rust desde que salió, que fue después, en 2015. O el rendimiento que tiene, por encima de otros lenguajes interpretados. O todas sus capacidades, que lo hacen multiparadigma, con cosas como closures, funciones anónimas (lo de funciones as first class citizens) o sintaxis para generadores como yield.

Y a ver, PHP tiene el operador battleship que es tal que así:



¿Cómo no va a molar un lenguaje con un operador que se llama battleship y que tiene esa forma?

[#36 Desactivado]

#30 Los traits cubren un hueco que en otros lenguajes llenan las interfaces con default methods o los mixins. Hasta Go, que puede presumir de la peor implementación de una orientación a objetos de las últimas décadas, cuenta ya con mecanismos similares.

PHP estuvo muy bien en su momento, pero en su nicho principal, web backend, hay varios lenguajes (dependiendo de las necesidades) mucho más recomendables para iniciar un nuevo proyecto que PHP. La caída de PHP es imparable y eso en sí mismo ya es un argumento de peso en contra de su uso.

Ahora, el argumento de Battleship es incontestable Está un punto (y un carácter) por encima de operadores como Elvis ?: o Walrus :=

[#45 daphoene]

#36 "que puede presumir de la peor implementación de una orientación a objetos de las últimas décadas"

muy fino.

"PHP estuvo muy bien en su momento, pero en su nicho principal, web backend, hay varios lenguajes (dependiendo de las necesidades) mucho más recomendables para iniciar un nuevo proyecto que PHP. La caída de PHP es imparable y eso en sí mismo ya es un argumento de peso en contra de su uso."

Me gustaría que listaras esos lenguajes mucho más recomendables que php para backend. Que no digo que no sean buenos, pero todos tienen sus muertos bajo la alfombra...

PHP proviene de unas bases muy chungas, no te lo niego, pero después de muchos años y lenguajes, sigo utilizándolo porque mantiene un equilibrio suficiente que muchos otros no consiguen. Si java se hubiera detenido en la versión 7, seguramente sería mi preferido, pero decidió phpizarse o javascriptizarse y ha quedado como el "Ciudadanos" de los lenguajes, en lugar de ser fiel a sus principios. Y para hacer el indio con un lenguaje sucio, prefiero quedarme con el original, que tiende a ser más limpio con los años*, en lugar de llevar el camino contrario.

* Irónicamente, imitando al java anterior.

[#39 cosmonauta]

#30 Te voto positivo por lo del battleship.

Respecto a todo lo demás, no creo que se tan significativo lo que tiene sino lo que le sobra, que también es mucho. La inconsistencia de sintaxis, el type hinting opcional y muy rarete, el PHP.ini que te puede volver loco...y mucho más

. Si puedo, no vuelvo.

[#46 daphoene]

#39 Cuando necesitas llegar a cierta profundidad, todos los sistemas tienen apartados sucios, complejos, y de difícil trato.

PHP simplemente te lo pone en los morros el primer día ( php.ini )

Pero que no lo veas en tu IDE más limpio que una patena, no quiere decir que no exista por debajo, ni que tarde o temprano no tengas que llegar a ello.

Y cuando llegues, te aseguro que de tanto intentar esconderlo, suele ser bastante peor que en PHP.

[#47 tunic]

#39 La inconsistencia de la sintaxis es totalmente irrelevante, no te complica la vida prácticamente nada, pero es lo primero que se dice, y diría que es porque no se encuentran mucha más críticas.

El type hinting opcional es una feature: te permite usarlo o no, siendo más flexible o más estricto según quieras o necesites.

El PHP.ini no sé que problema tiene, te permite configurar el entorno, y no se queda en el PHP.ini, hay varios niveles de sobrescritura de configuración.

¿Algo más que añadir?

Por supuesto, cada uno tiene sus gustos, pero es gracioso que cuando que hay una noticia de PHP siempre hay unos cuantos dando caña a PHP con los mismo argumentos ya caducos.

[#44 daphoene]

#30 Te voto positivo porque lo mereces

Pero:

Eso que llamas "herencia horizontal", es un remedo de la herencia múltiple que ya tenía C++, y que si no se ha copiado mucho es porque en general no es muy buena idea, a nivel de arquitectura.

Que te ahorra curro, no te lo niego. Y como todo, será una buena herramienta en algún caso muy concreto.

Pero como idea, es mala, en general. Yo anotaría otras virtudes de php, que pese a mis reticencias iniciales cuando lo conocí - eran otros tiempos, y eran tiempos muy chungos - las tiene, y no son pocas. Sin tener por qué esconder sus defectos, que también los tiene.

[#48 tunic]

#c-44" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3481299/order/44">#44 Eso que llamas "herencia horizontal", es un remedo de la herencia múltiple que ya tenía C++, y que si no se ha copiado mucho es porque en general no es muy buena idea, a nivel de arquitectura.

Lo de herencia horizontal es más bien composición horizontal, como dicen en el manual de PHP. Es una solución diferente a la herencia múltiple, que en su día (hace bastante tiempo, eso sí) daba un montón de problemas a la hora de la resolución de métodos y propiedades y en general se recomendaba no usar. Puede que haya mejorado, como digo hace bastante tiempo que ya no toco C++.

En cuanto a si los traits son una mala idea.. bueno, como digo los acaban de meter a C#, como quien dice, y te aseguro que prácticos son muy prácticos. ¿Por que son una mala idea? ¿Qué problema generan?

[#50 daphoene]

#48 No he dicho que los traits en sí sean una mala idea, son una herramienta más, pero ciertas herramientas permiten unos malos usos que cuando son mal entendidas, generan problemas. ¿ Es eval() una mala idea ? No, no lo es, permite "hacer cosas", y eso es bueno, pero un mal uso puede abrir un boquete de seguridad enorme.

A nivel de arquitectura, lo que solucionan los traits es permitir la herencia múltiple, que tiene sus propios problemas. Citas los mixins, pero éstos por definición son state-less, a diferencia de los traits.

La herencia múltiple tiene sus varios problemas asociados ( por ejemplo este clásico, pero no solamente: https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem ), y lenguajes posteriores a C++ han tratado de evitarla ( como Java, o PHP en sus inicios ) debido a los problemas de arquitectura que plantea.

Como digo al inicio, los traits no tienen por qué ser una mala idea, si quien los usa es consciente de todo lo que le permite la arquitectura sin ellos, y cómo se deben hacer las cosas, y dado un problema muy concreto, resulta ser la solución más diáfana o clara, siendo consciente de lo que implican. El problema es ese, que se usen porque parezca "más cómodo", sin comprender todo el resto, cuando no es necesario usarlos.

Pero como toda capacidad de un lenguaje, bien utilizados, son una herramienta más.

Aquí diferentes opiniones válidas, en mi modesta opinión:
https://stackoverflow.com/questions/7892749/traits-in-php-any-real-world-examples-best-practices

[#52 tunic]

#50 Ese ejemplo que pones de StackOverflow es muy pobre. Obviamente no vas a usar un Trait para meterle un logger, para eso usas inyección de dependencias. Los traits tiene otro usos.

Pero que le foco es PHP como lenguaje: es un lenguaje potente y moderno, pero a la gente le gusta meterse con él, igual que con JavaScript, por razones peregrinas o porque no entienden el lenguaje completamente.

[#53 daphoene]

#52 "ero que le foco es PHP como lenguaje: es un lenguaje potente y moderno, pero a la gente le gusta meterse con él, igual que con JavaScript, por razones peregrinas o porque no entienden el lenguaje completamente."

Es la herencia recibida, una tradición, de cuando PHP no era más que un parser, y se hacían verdaderas barbaridades con él. Pero estoy contigo, es como criticar a una marca de coches por cómo hacían sus modelos hace cuarenta años, o como los chistes basados en estereotipos desfasados.

Supongo que a la gente le hace sentir importante pensar que "conducen" el mejor lenguaje de programación, como si el "coche" condujera por ti, o ganase las carreras en las que participa él solo.

[#26 perroloco]

#21 En el kernel de linux la comprobacion de capabilities de un ejecutable es literalmente una linea... cambia una linea y has comprometido chorrocientos servidores.

Vamos que sacar un baremo de fiabilidad de algo basandose en el numero de lineas que se han de escribir para abrir un boquete... pues es un poco de churramerinismo como minimo.

[#29 tunic]

#21 Prácticamente puedes comprometer cualquier software con 6 líneas de código. El ataque seguramente podría haberse hecho con cualquier otro lenguaje que se ejecute en servidor.

Por otro lado, los ataques a PHP por su calidad como lenguaje solo pueden hacerse desde un conocimiento poco actualizado de su evolución.

[#31 flixter]

#21 2 lineas de codigo en el kernel de linux habrian podido comprometer todos los sistemas corriendo ese kernel en 2000 y poco, si no recuerdo mal.

[#38 Desactivado]

#21 lee bien el titular

[#42 LLort_II]

#21 Pues en principio que el código malicioso va por libre del lenguaje de programación.

Luego, que lo de que afecta al 80% de internet es obviamente falso (algo así ocuparía telediarios)

Por último, si lo de ¿programación? lo pones porque no crees que PHP lo sea, también te equivocas.

Probablemente te equivocas también en lo de que son exactamente 6 líneas, no me interesa tanto como para ponerme a comprobar eso.

[#4 Desactivado]

A partir de ahora los repositorios en GitHub que antes eran solo mirrors, pasarán a ser los principales

Bueno, ahí está un posible beneficiado

[#40 Jesuo]

Fijo que han sido mis vecinitas