El sistema de control de versiones utilizado por WebKit se corrompió completamente después de que alguien subiese dos PDFs distintos con el mismo SHA1. El problema viene de que el software que gestión de versiones, Apache Subversion (SVN), utiliza SHA1 para hacer seguimiento y combinación de ficheros duplicados. WebKit es el motor de navegadores web utilizando entre otros por Safari.
|
etiquetas: sha1 , webkit , colisión , svn , subversion 
![Primera víctima de la colisión de SHA1: El repositorio de WebKit [ENG]](https://peta.meneame.net/backend/media?type=link&id=2739842&version=0&ts=1487970307&image.jpeg)
¿ Qué clase de sortilegio digno del sabio Frestón es éste?
!Quédome igual leyendo los comentarios otros que no en leyendo nada!
¿Es computacionalmente viable hacer una ataque de preimagen al MD5?
¿Y qué crees que usa Git?
Si creas un blob con el mismo hash que un commit o un tree del repositorio al hacer un push o un clone pasará exactamente lo mismo que en svn: repositorio corrupto.
Yo sin duda prefiero git a svn o hg, pero nunca deja de sorprenderme la cantidad de fanboys de lo que sea que echan pestes sobre otras tecnologías sin saber muy bien por qué.
¿ Qué clase de sortilegio digno del sabio Frestón es éste?
!Quédome igual leyendo los comentarios otros que no en leyendo nada!
De todos modos al no ser centralizado como subversión siempre quedará alguna copia sin actualizar.
Las versiones se guardan en repositorios. Svn usa un repositorio central, en una única máquina, para manejar todas las versiones.
SHA1 es un algoritmo de hash o firma. Hasta ahora, si a un archivo (un conjunto de datos) le aplicabas este algoritmo devolvía un resultado único. Ahora han encontrado que pueden conseguir dos archivos con el mismo resultado.
De este modo, con dos archivos pdf con idéntico hash es posible "corromper" todo un repositorio de miles de archivos.
www.youtube.com/watch?v=cozRkjztWBQ
Que se prepare el lunes ajjaja
news.ycombinator.com/item?id=13719368
security.stackexchange.com/questions/67920/how-safe-are-signed-git-tag
Otra cosa es que tu te lo creas.
Los hash nunca son únicos. Cualquier hash del tamaño que sea tiene repeticiones cuando la cantidad de bits sobre los que aplicas la operación es mayor a la del hash.
Si la distribución es perfecta, para un hash de 160bits tendrías 2 repeticiones al aplicarlo sobre 161 bits y crecería de forma exponencial por cada bit que aumentes.
"Ahora han encontrado que pueden conseguir dos archivos con el mismo resultado."
Lo que han encontrado es una forma para generar es colisiones de forma simple y en un tiempo aceptable.
A no ser que hagas commit+push, que es como trabajar con SVN y al final es lo que la gente hacia.
"Looking through the bug comments and commit log, it seems that the person who checked in the two PDF files did so, not to see what happens in SVN, but because he was creating a testcase for Webkit itself to check whether the SHA1 collision issue couldn't be used for cache poisoning. The test presumably used the two PDF files to generate the behavior needed in the test. It seems he just was a bit careless, not realizing that SVN was also susceptible."
O sea, que querían probar si WebKit se vería afectado por los PDFs con el mismo SHA1 en un escenario de "envenenamiento de caché" y los subieron a SVN sin darse cuenta que SVN también se ve afectado por la misma razón corrompiendo el repositorio.
Vamos, me recuerda a cuando los rusos se pusieron a hacer un test a la central nuclear de Chernobil a ver cuanto aguantaba, ya sabéis como acabó todo...
calmad vuestros corceles
Y os quejais que os pagan 800€.
Y entiendo que tu crees que no hay tal trecho.
pero de ahí a hacer una catástrofe como lo que han hecho con SVN va un trecho
Afortunadamente sistemas como OpenBSD dejaron SHA1 hace tiempo, usando actualmente SHA256, y haciendo su sistema de alguna forma independiente del algoritmo usado, con lo que futuros cambios no supondrán un excesivo trabajo.
rdos.wordpress.com/2009/02/23/usando-la-bola-de-crital-y-el-md5-para-p
Es un pregunta interesante. Yo entiendo que si es fácil encontrar una colisión en ambos por separado (provocada, como parece que es este caso, ver #44), también podría serlo encontrar una colisión en ambos a la vez.
(a ver si alguien con más conocimientos nos responde)
Es muy simple, lo que tú llamas "HTML incorrecto y nada accesibles" en su día fue un estándar 100% válido. Puede parecerte muy sencillo llegar y actualizar la página web, pero... ¿Tu crees que todo el mundo tiene tanto tiempo libre como tú? Y eso si no les vuelve a dar por ahí y declaran lo actual como "deprecated", porque si, por fastidiar.
Hay 3 niveles de seguridad en un algoritmo hash. El más difícil es: dado un fichero con un cierto hash, crear otro que tenga el mismo hash, que es lo que se ha conseguido ahora. Pero no a fuerza bruta, sino aprovechando debilidades en el algoritmo que no son evidentes y que ha costado muchos años investigar.
(Disculpa el negativo... el cambio de iconos del interfaz me ha jugado una mala pasada)
hipertextual.com/2016/02/linux-mint-hackeado
blog.linuxmint.com/?p=2994
Pués tampoco es tan conspiranoia que se pueda modificar un paquete en Debian, digo yo.
Salu2
A menos que utilices Emacs, entonces: C-x M-c M-butterfly
www.xkcd.com/378/
Imagínate que tienes varios trenes de mercancías que van por distintas vías, cada uno de estos trenes siempre sale por una vía distinta (distinto hash). ¿Qué probabilidad hay de que alguno de estos trenes salga por la misma vía que otro? (colisión de hash). Una colisión de hash se produce cuando dos entradas o dos valores aleatorios a partir de una función llamada de hash, producen la misma salida.
Por ejemplo uno de los trenes lleva madera y el otro lleva carbón (distinto mensaje o distinto contenido), eso sí pasan por el mismo punto de carga (función de hash) y siempre salen por una vía distinta a la de otros. Pero si por cualquier circunstancia salen por la misma vía habrá lo que se llama colisión de hash. Porque teniendo que una función de hash, a partir de una entrada llamémosle x, y una salida z. Tenemos que H (x) = z si llamamos a los dos trenes a y b, Y a las salidas zn (z1,z2,z3,z4...) se dará que...
Por ejemplo:
Si H (a) = z1 y H (b) = z5 -> No hay colisión:
Si H (a) = z3 y H (b) = z122 -> No hay colisión
Pero:
Si H (a) = z17 y H (b) = z17 -> ¡Se ha producido una colisión! y se da que H (a) = H (b) (¡coinciden los hash!)
Y esto anterior es muy grave, porque aunque las colisiones más tarde o más temprano se dan (aunque son miles de millones de valores no dejan de ser finitos y como encima son aleatorios es más fácil que se den). Pués hace que no te puedas fiar de la autenticidad de un contenido.
Esta busqueda anterior, por diferentes formas de encontrar una colisión, se denomina ataque de colsión de hash o ataque de colisiones. El problema es que si dentro de los muchos valores que hay vamos uno a uno desde el menor al mayor tardaríamos muchísimo en encontrar una posible colisión. Imaginemos los cien mil primeros valores, aquí no hay colisión y si vamos del 1 al 100.000 no habrá colisión, pero imaginemos que se produce una colisión entre los valores 100.001 y 4.996.678. Es más fácil encontrar estos valores si los elegimos al azar que si vamos del primero al último. Obviamente estos valores los he resumido, porque son miles de millones.
Generalmente es imposible que H (a) = H (b) (es decir que el hash de a coincida con el de b). Pero si se encuentra una colisión si de dará que H(a) = H(b) y aquí tendremos el problema que explicamos.
Salu2
Te cambia la manera de trabajar especialmente en proyectos grandes.
Aviso, vulernabilidad gorda.
Si algún sitio web con cuenta usa cloudflare, cambiad contraseña ya.
Repo github con las vulnerabilidades (joder esto es ridículo
github.com/pirate/sites-using-cloudflare
"Git uses SHA-1 hashes internally; this is a problem because SHA-1 is no longer considered secure. Linus Torvalds has responded that the hash was mostly to guard against accidental corruption, and the security a cryptographically secure hash gives was just an accidental side effect, with the main security being signing elsewhere. Nonetheless, the publication of the first SHA-1 collision attack in 2017 prominently mentioned Git as a possible target for attacks."
en.wikipedia.org/wiki/Git
Toca workaround primero y parcheo cuando sea.
Dentro de poco tanto Chrome como firefox van a dejar de aceptar los certificados sha1 como seguros así que esta via de ataque debería quedar limitada.
¿Qué sabes tú del tiempo libre que tengo yo? ¿de qué me conoces?
#67 y #86 y el dia de release, cuando tu y tus 50 compañeros hagais todos el merge a release, o el dia anterior cuando todos hagais el merge a develop, te encontraras con que es un "marica el ultimo" porque todo el mundo tendra colisiones co otros 6 o 7. De los 60 ficheros que has cambiado en tu rama, 43 coinciden con los que han cambiado otros miembros, asi que tendras que hacer 43 merges si eres el ultimo en mergear. A quien madruga dios le ayuda.
#72 toda la razon del mundo. Cuanto mas aislado, peor, y tener tu propio repositorio te aisla mas.
Un repo es un repo, nada más. No veo problema en usar un svn, ni entiendo echarse las manos a la cabeza.
Yo creo que la mayor complicación a la hora de mantener los navegadores más que de esas web HTML 3.0 que mencionas viene de la enorme maraña de código ineficiente e inaccesible en la que se ha convertido el 99% de la web, siendo un buen ejemplo el framework jQuery. Yo suelo navegar sin Javascript porque el navegador se ralentiza y a veces incluso se cuelga.
La antítesis de esta librería es la recientemente publicada elementalsjs.com que, sin pretender cambiar el comportamiento de Javascript, aporta una serie de funciones para trabajar de forma más limpia.
Hoy día la web no suele cumplir ninguna recomendación de accesibilidad de la WCAG, y las personas con discapacidad cada vez encuentran más difícil encontrar información.
Espero que no los hayas usado todos igual.
Git tiene un sistema de ramas muy superior )los merges, los rebase, la creación y borrado, las ramas locales) , squashing de commits, poder hacer commits parciales de ficheros diferenciando entre git add y git commit y haciendo stash de los cambios que querias mantener...
Esto es de cabeza.
Git es mucho más flexible y potente, lo puedes usar como subversion, pero es un desperdicio.
EDIT: git commit --ammend para ir arreglando los problemas que salgan en review.
Parece que si una página web no ocupa 200 mb de RAM no está bien hecha.
Estoy leyendo cómo se puede hacer eso aquí -> www.kachakil.com/retos/S21_Reto_7.pdf .
La técnica usada para hacer eso, sin embargo, no serviría para manipular un paquete Debian. La clave está en que en lo de la lotería tienes el control de todos los archivos que quieres que colisionen, así que los puedes diseñar de tal forma que la colisión exista. En el caso del paquete Debian, uno de los ficheros es como es, y lo que buscas es diseñar otro que tenga exactamente el mismo hash. El hecho de sólo poder cambiar uno de los ficheros cambia la cosa muchísimo...
#59 En su día leí a alguien que estuvo una semana depurando un programa y al final el problema era que había una colisión que estaba haciendo que una tabla hash devolviera un valor incorrecto... ni me imagino la cara que se te tiene que quedar cuando ves eso
Sigue siendo lo mismo, no saber trabajar en equipo y planificar mal los releases, proyectos con más desarrolladores y con más lineas de código cambiadas al día funcionan a la perfección con Git.