¿Por qué sigue siendo válida una firma .jar si se ha agregado un archivo al jar?

Question

¿Por qué sigue siendo válida una firma .jar si se ha agregado un archivo al jar?

#1 de Lie Ryan (2 votos)
#2 de BaconWaifu (0 votos)
#3 de symcbean (0 votos)

4

Estaba leyendo la página de manual para el jarsigner herramienta que viene con el JDK. Esta línea me sorprendió:

Una verificación aún se considera exitosa si ninguno de los archivos que estaban en el archivo JAR cuando se generó la firma se ha cambiado desde entonces, lo cual es el caso si los hashes en las secciones sin encabezado del archivo .SF son iguales Los hashes de las secciones correspondientes en el archivo de manifiesto.

Esto no tiene sentido para mí. ¿No pudo un atacante ocultar código malicioso en un archivo jar ya firmado?

Actualización: Aquí hay un ejemplo de este escenario. Parece que jarsigner marcará el tarro como que contiene archivos adicionales, pero todavía lo considera verificado.

=> jar -cf twelfthnight.jar TwelfthNight.html
=> keytool -genkey -alias signFiles -keystore examplestore
=> jarsigner -keystore examplestore twelfthnight.jar signFiles
Enter Passphrase for keystore:
jar signed.

Warning:
The signer certificate will expire within six months.
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2016-10-16) or after any future revocation date.

=> jarsigner -verify twelfthnight.jar
jar verified.

Warning:
This jar contains entries whose certificate chain is not validated.
This jar contains entries whose signer certificate will expire within six months.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2016-10-16) or after any future revocation date.

Re-run with the -verbose and -certs options for more details.

=> jar uf twelfthnight.jar Hamlet.html

=> jarsigner -verify twelfthnight.jar
jar verified.

Warning:
This jar contains unsigned entries which have not been integrity-checked.
This jar contains entries whose certificate chain is not validated.
This jar contains entries whose signer certificate will expire within six months.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2016-10-16) or after any future revocation date.

Re-run with the -verbose and -certs options for more details.

java code-signing

pregunta T.D. Smith 18.07.2016 - 15:45

fuente

3 respuestas

0

Por lo que puedo decir, la carpeta generada llamada META-INF contiene firmas y hashes para cada clase inicialmente dentro del archivo JAR. La razón por la que agregar una clase no cambia la firma es porque no hay una firma general para el JAR en sí.
Un ejemplo de esto es el modding de Minecraft. Antes de forjar la API, era necesario eliminar la carpeta de firmas, ya que modificaba las clases que tenían firmas, pero ahora simplemente reemplazan los archivos de firmas con uno firmado por su propia clave, ya que ayuda a garantizar la integridad de los datos del contenido JAR p>

respondido por el BaconWaifu 18.07.2016 - 16:19

fuente

0

Pero los archivos se pueden agregar al jar después de la firma sin invalidarla.

erm, no - jar está haciendo lo que dijo que haría, ninguno de los archivos firmados ha cambiado. Pero sí, acabas de demostrar que el emperador no tiene ropa: esta verificación de la jarra no sirve para nada.

respondido por el symcbean 17.08.2016 - 23:05

fuente

Lea otras preguntas en las etiquetas java code-signing

Obtención y almacenamiento de una clave AES para SQLite DB en iOS ¿Se sabe que el malware monta volúmenes?

score 2 · Accepted Answer

Al leer esto, sí, un atacante podría insertar código malicioso en el contenedor. Sin embargo, a menos que haya un código en la parte firmada de la que intenta cargar el archivo malicioso, el archivo malicioso está inerte y no puede hacer nada significativo.

Errores y advertencias

Durante el proceso de firma o verificación, el comando jarsigner puede emitir varios errores o advertencias.

Si hay un error, el comando jarsigner sale con el código 1. Si no hay un error, pero hay una o más advertencias graves, el comando jarsigner sale con el código 0 cuando no se especifica la opción -strict, o sale con el valor OR de los códigos de advertencia cuando se especifica el -stricto. Si solo hay advertencias informativas o ninguna advertencia, el comando siempre sale con el código 0.

...

Advertencias graves

Nota: las advertencias graves se informan como errores si especifica la opción -strict.

Las razones por las que el comando jarsigner emite una advertencia grave incluyen el certificado utilizado para firmar que el archivo JAR tiene un error o el archivo JAR firmado tiene otros problemas.

...

hasUnsignedEntry      Código 16. Este contenedor contiene entradas sin firmar que no se han verificado con integridad.

...

En cualquier caso, si observa todas las demás posibles advertencias graves en la documentación, se vuelve bastante obvio que hacer --verificar sin --strict es bastante inútil para usos de scripting.