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.
|
etiquetas: hackeado , repositorio , código fuente , php , lenguaje de programación 
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.
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.
/cc #2
Bueno, ahí está un posible beneficiado
freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/
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.
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.
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!
- Documentación de Git: git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
- Documentación de Github: help.github.com/en/github/authenticating-to-github/signing-commits
- Documentación de Gitlab: docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/
Cada uno de mis compañeros hace sus subidas con su cuenta. ¿Para qué serviría firmarlos?
No tengo ni pu.. idea de informática.
Descalificaciones e insultos debajo de la línea, please
_______________________________________________________
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.
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.
Por otro lado, los ataques a PHP por su calidad como lenguaje solo pueden hacerse desde un conocimiento poco actualizado de su evolución.
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?
jira.atlassian.com/browse/BCLOUD-3166
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
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.
Aquí el problema es que alguien subió código malicioso, otra persona (s) lo revisó y lo aceptó, y el código fue publicado.
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.
blog.gruntwork.io/how-to-spoof-any-user-on-github-and-what-to-do-to-pr
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...
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.
"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.
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.
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.
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?
jira.atlassian.com/browse/BCLOUD-3166
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: 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:
stackoverflow.com/questions/7892749/traits-in-php-any-real-world-examp
Para proyectos realmente serios, es un mínimo obligatorio.
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.
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.