Perché una firma .jar è ancora valida se nel jar è stato aggiunto un file?

Question

Perché una firma .jar è ancora valida se nel jar è stato aggiunto un file?

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)

4

Leggevo la pagina man per la jarsigner strumento fornito con JDK. Questa linea mi ha sorpreso:

A verification is still considered successful if none of the files that were in the JAR file when the signature was generated have been changed since then, which is the case if the hashes in the non-header sections of the .SF file equal the hashes of the corresponding sections in the manifest file.

Questo non ha senso per me. Non è possibile che un utente malintenzionato nasconda un codice dannoso in un file jar già firmato?

Aggiornamento: ecco un esempio di questo scenario. Sembra che jarsigner contrassegni il jar come contenente file aggiuntivi, ma continua a considerarlo verificato.

=> 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

posta T.D. Smith 18.07.2016 - 15:45

fonte

3 risposte

0

Da quello che posso dire, la cartella generata chiamata META-INF contiene le firme e gli hash per ogni classe inizialmente all'interno del file JAR. Il motivo per cui l'aggiunta di una classe non modifica la firma è perché non esiste una firma generale per la JAR stessa
Un esempio di questo è il modding di Minecraft. Prima dell'API di forge, richiedeva l'eliminazione della cartella della firma in quanto modificava le classi con firme, ma ora sostituisce semplicemente i file delle firme con uno firmato con la propria chiave, poiché garantisce l'integrità dei dati dei contenuti del JAR

risposta data 18.07.2016 - 16:19

fonte

0

But files can be added to the jar after the signature without invalidating it.

erm, no - jar sta facendo quello che ha detto che avrebbe fatto - nessuno dei file firmati è cambiato. Ma sì, hai appena dimostrato che l'imperatore non ha vestiti: questa verifica del barattolo è inutile.

risposta data 17.08.2016 - 23:05

fonte

Leggi altre domande sui tag java code-signing

Il malware è noto per montare i volumi? In quali circostanze è possibile aggirare il blocco dello schermo e ottenere dati su Android?

score 2 · Accepted Answer

Da quando ho letto questo, sì, un utente malintenzionato potrebbe inserire codice dannoso nel contenitore. Tuttavia, a meno che non ci sia un codice nella parte firmata di quello che tenta di caricare il file dannoso, il file dannoso è solo lì inerte e incapace di fare qualcosa di significativo.

Errors and Warnings

During the signing or verifying process, the jarsigner command may issue various errors or warnings.

If there is a failure, the jarsigner command exits with code 1. If there is no failure, but there are one or more severe warnings, the jarsigner command exits with code 0 when the -strict option is not specified, or exits with the OR-value of the warning codes when the -strict is specified. If there is only informational warnings or no warning at all, the command always exits with code 0.

...

Severe Warnings

Note: Severe warnings are reported as errors if you specify the -strict option.

Reasons why the jarsigner command issues a severe warning include the certificate used to sign the JAR file has an error or the signed JAR file has other problems.

...

hasUnsignedEntry Code 16. This jar contains unsigned entries which have not been integrity-checked.

...

In ogni caso, se osservi tutti gli altri possibili avvertimenti gravi nella documentazione, diventa abbastanza ovvio che fare --verify senza --strict è praticamente inutile per gli usi di scripting.