Journal La signature de code en Java

Posté par Coren le 19 janvier 2014 à 21:04. Licence CC By‑SA.

Étiquettes :

jan.

2014

Cher Journal,

Depuis quelques jours, Oracle a décidé d'interdire l'exécution des applets ne précisant pas leur nom d'application (Application-Name) dans le fichier de description MANIFEST.MF.

Bien entendu, un des sites qui est sous ta charge utilise des applets, l'éditeur de celle-ci a mis la clé sous la porte mais ça ne devrait pas t'arrêter: normalement, il suffit juste d'ajouter quelques lignes dans ~~un fichier zip~~ une archive jar.

Bien sûr, si tu pensais juste pouvoir modifier le fichier MANIFEST et que ça allait marcher, tu pouvais te mettre l'octet dans l'archive. Ton applet est signé. Toute modification que tu souhaites y apporter nécessite de pouvoir la re-signer.

Passons à la signature. Il va te falloir un certificat valide, et attention, pas n'importe quel certificat, un certificat pour signer du code (Java).

Une fois muni de la clé privée et publique de ton certificat, il te faudra aussi récupérer les certificats intermédiaire, root, etc, sinon ce serait trop simple.

Voici les étapes pour parvenir à re-publier cet applet avec de nouveaux paramètres

Fabrication de la chaine de certification (nécessaire pour l'étape 3, qui n'accepte qu'un seul fichier)
cat codesigning.cer intermediate1.cer gscodesigng2.crt Root-R1.crt > cert-chain.txt
Vérification de la chaine
openssl verify -CAfile cert-chain.txt codesigning.cer
Export au format pkcs12, utilisable par les outils Java (NB: Il est OBLIGATOIRE de mettre un mdp et un alias)
openssl pkcs12 -export -inkey codesigning.key -in cert-chain.txt -out cert-chain.pkcs12 -name tomcat
Transformation du PKCS12 en KeyStore Java
keytool -importkeystore -srckeystore cert-chain.pkcs12 -srcstoretype PKCS12 --destkeystore codesigning.jks -srcalias tomcat
Vérification du keystore
keytool -list -v -keystore codesigning.jks
Création du fichier d'ajout au Manifest de l'applet des paramètres en question:
cat addToManifest.txt

Permissions: all-permissions
Codebase: *
Application-Name: Hello World
Amélioration du Manifest, qu'il faut faire sur l'ensemble des archives de code
for i inls /path/to/*.jar; do jar ufm "$i" addToManifest.txt; done
Remplacement de la signature existante par la nouvelle
for i inls /path/to/*.jar; do jarsigner -keystore /path/to/codesigning.jks "$i" tomcat; done

NB: Le paramètre Permissions n'a que 2 valeur possibles: aucun droit (sandbox) ou tous les droits (all-permissions)

# Crache pas dans la soupe !

Posté par jigso le 19 janvier 2014 à 22:18. Évalué à 10.

C'est ça qui te fait vivre : on ne remerciera jamais assez Oracle - et les autres - de créer tout un tas de contraintes qui nous permettent de justifier nos salaires devant les "daïcideurs". C'est l'immuable paradoxe de l'informatique : celui qui a plein de boulot à cause de ses bugs ou de ceux des autres, il passe pour un héros alors que celui qui a bien fait son travail et qui du coup a peu de maintenance et peut faire évoluer ses applis sans tout casser passe pour un glandeur…
- [^] # Re: Crache pas dans la soupe !
  
  Posté par barmic le 19 janvier 2014 à 23:08. Évalué à 4.
  
  celui qui a plein de boulot à cause de ses bugs ou de ceux des autres, il passe pour un héros
  
  Ça dépend de la fréquence à la quelle on doit l'appeler. Ça ne plaît pas plus aux utilisateurs que ça d'être sans cesse bloqué dans leur utilisation.
  
  Mais je ne vois pas ce qu'il y a de critiquable à forcer la signature d'un code s'exécutant sur la machine. C'est un peu ce que font les distributions avec les gestionnaires de paquets. C'est contraignant pour le développeurs, mais c'est aussi contraignant pour un développeur de créer un paquet pour Debian qui suit bien les règles litian et qui soit signé, c'est contraignant de se casser la tête pour savoir comment sauvegarder ses mots de passe, etc.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Crache pas dans la soupe !
    
    Posté par jigso le 19 janvier 2014 à 23:32. Évalué à 9.
    
    "il passe pour un heros" … aux yeux de sa hiérarchie ! (pas aux yeux des utilisateurs, bien sûr). Par ex, j'ai souvent vu comme indicateur de "performance" le nombre de bug corrigés : quand une équipe a 99%, on la félicite, même si le nombre de bug est bien supérieur à celle qui a 50% (car elle n'a corrigé qu'un bug… sur 2 !)
    
    Je ne critiquais pas vraiment la signature en elle-même, juste qu'une petite modif - finalement peu utile du point de vue de la sécurité - entraîne un boulot non trivial (pour l'avoir déjà fait, la première fois c'est assez galère). Et je remercie au passage l'auteur du journal d'avoir rassemblé ici toutes les commandes nécessaires à ce pensum.
  - [^] # Re: Crache pas dans la soupe !
    
    Posté par Zenitram (site web personnel) le 19 janvier 2014 à 23:33. Évalué à 2.
    
    je n'ai pas lu de critique sur la signature, seulement sur les changements de règles qui fait que ce qui marchait avant (signé) ne marche plus aujourd'hui.
    
    J'en profite pour demander quel est l'intérêt sécurité de changer cette règle (l'app-name)
    - [^] # Re: Crache pas dans la soupe !
      
      Posté par barmic le 19 janvier 2014 à 23:44. Évalué à 2.
      
      je n'ai pas lu de critique sur la signature, seulement sur les changements de règles qui fait que ce qui marchait avant (signé) ne marche plus aujourd'hui.
      
      Si tu veux que ce qui marchais avant marche aujourd'hui, tu ne fais pas de mise à jour sans un vrai protocole de test de ces dernières.
      Si tu n'a pas de contrôle sur les mises à jours alors tu peut avoir tout qui passe ou pas du jour au lendemain parce que l'un utilise le jdk sun en version 6, l'autre OpenJDK7 et un dernier s'amuse avec jrokit.
      Bref rien que du très banale.
      
      J'en profite pour demander quel est l'intérêt sécurité de changer cette règle (l'app-name)
      
      Je pense que c'est pour forcer la signature.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Crache pas dans la soupe !
        
        Posté par Elfir3 le 22 janvier 2014 à 00:34. Évalué à 2.
        
        Si tu veux que ce qui marchais avant marche aujourd'hui, tu ne fais pas de mise à jour sans un vrai protocole de test de ces dernières.
        
        Je pense pas qu'on contrôle toujours les machines sur lesquelles s'installent les logiciels java. D'ailleurs Java, c'est pas le truc qui râle à chaque ouverture de windows pour faire une mise à jour ?
        
        [^] # Re: Crache pas dans la soupe !
        
        Posté par barmic le 22 janvier 2014 à 09:00. Évalué à 2.
        
        C'est bien tu as lu ma première phrase. Maintenant passe au niveau 2 en lisant la seconde !
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Crache pas dans la soupe !
        
        Posté par Elfir3 le 22 janvier 2014 à 11:31. Évalué à 2.
        
        Traitresse de fatigue !
        
        Désolé pour le bruit…
- [^] # Re: Crache pas dans la soupe !
  
  Posté par Zylabon le 19 janvier 2014 à 23:13. Évalué à 1.
  
  Vu ce que permet le HTML, le CSS et le JS, les gens n'ont plus aucun intérêt à prendre le risque d’exécuter du java… ya eu tellement de failles par le passé ! N’exécuter plus que les applications signées c'est je suppose une manière de sauver les meubles et limiter de recul de la technologie.
  
  Please do not feed the trolls
  - [^] # Re: Crache pas dans la soupe !
    
    Posté par ckyl le 19 janvier 2014 à 23:46. Évalué à 8. Dernière modification le 19 janvier 2014 à 23:48.
    
    N’exécuter plus que les applications signées c'est je suppose une manière de sauver les meubles et limiter de recul de la technologie.
    
    Heu vu que signer un applet permet de le faire sortir de la sandbox…
    
    C'est ca qui est marrant avec le modèle de secu foireux des applets. Un non signé, il est confiné comme on s'y attendrait (modulo les 200 failles). Un signé, ca te donne l'impression que c'est plus sure. Sauf qu'en fait ça le fait sortir automatiquement de tout confinement, sans choix possible, et tu fais donc une confiance aveugle dans le publisher. Je suis pas certain que tout le monde en ait conscience quand il clique sur le bouton en se disant "chouette c'est plus secure".
    - [^] # Re: Crache pas dans la soupe !
      
      Posté par Buf (Mastodon) le 20 janvier 2014 à 08:43. Évalué à 1.
      
      Sauf qu'en fait ça le fait sortir automatiquement de tout confinement, sans choix possible
      
      Je sais pas si ça a changé, mais à l'époque où je faisais du Java, il ne suffisait pas que le code soit signé pour sortir de la sandbox, il fallait également une autorisation explicite de l'utilisateur.
      - [^] # Re: Crache pas dans la soupe !
        
        Posté par ckyl le 20 janvier 2014 à 08:57. Évalué à 2.
        
        AFAIK non. On mélange allégrement autentification et autorisation. Il semble que depuis u25 on puisse demander à ce qu'un applet ne puisse tourner qu'en sandbox (ca demande un manifest specifique et un markup approprié dans la page) mais ca ne me semble pas regler le problème de l'applet malicieux à la base.
        
        Bref 15 ans après les applet sont toujours ce qu'ils sont.
        
        [^] # Re: Crache pas dans la soupe !
        
        Posté par Buf (Mastodon) le 20 janvier 2014 à 09:30. Évalué à 1.
        
        En fait, après réflexion, je confonds peut-être avec Java Web Start. Là, il me semble qu'on peut régler plus finement les permissions.
      - [^] # Re: Crache pas dans la soupe !
        
        Posté par groumly le 22 janvier 2014 à 06:07. Évalué à 1.
        
        Non, comme le dit ckyl, applet signée = la fete a mémé, tu fais ce que tu veux.
        Acces au disque en veux tu en voila, tout du moins dans la config par defaut.
        Et apres yen a qui se demande pourquoi apple shippe sans java et desactive les applets apres un mois.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Crache pas dans la soupe !
        
        Posté par barmic le 22 janvier 2014 à 09:03. Évalué à 2.
        
        Ça veut dire quoi shipper ? La seule référence que j'ai trouvé c'est ça : http://en.wiktionary.org/wiki/shippe
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Crache pas dans la soupe !
        
        Posté par groumly le 22 janvier 2014 à 18:16. Évalué à 0.
        
        To ship. En anglais, "expedier, envoyer", utiliser dans le soft pour une release au public.
        Livrer j'imagine en francais?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 20 janvier 2014 à 11:23. Évalué à 10. Dernière modification le 20 janvier 2014 à 11:25.
    
    Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: Crache pas dans la soupe !
      
      Posté par jigso le 20 janvier 2014 à 12:38. Évalué à 0.
      
      Désolé, c'est Java qui gagne encore une fois : http://www.zdnet.fr/actualites/cybercriminalite-les-pirates-adorent-java-39797189.htm
      
      Bref, LEDEVSAPUECÉPASECURE !
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 20 janvier 2014 à 12:50. Évalué à 3.
        
        Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: Crache pas dans la soupe !
      
      Posté par Zylabon le 20 janvier 2014 à 19:34. Évalué à 2.
      
      D'accord… Je suis trop naïf.
      
      Je vais abandonner le web et m'en tenir à Gopher.
      
      Please do not feed the trolls
# Application-Name requis

Posté par kaliko (site web personnel) le 20 janvier 2014 à 11:03. Évalué à 1.
```
Depuis quelques jours, Oracle a décidé d'interdire l'exécution des applets ne précisant pas leur nom d'application (Application-Name) dans le fichier de description MANIFEST.MF.
```
Un petit lien concernant la source de cette information ?

merci :)
- [^] # Re: Application-Name requis
  
  Posté par lay le 20 janvier 2014 à 12:44. Évalué à 1.
  
  Ce n'est pas la source de cette affirmation mais cela peut éclaircir la chose :
  
  http://www.java.com/en/download/help/java_blocked.xml
- [^] # Re: Application-Name requis
  
  Posté par Boa Treize (site web personnel) le 20 janvier 2014 à 13:52. Évalué à 3.
  Deux liens qui donnent des détails sur les nouvelles restrictions de sécurité :
  - New security requirements for RIAs in 7u51 (January 2014)
  - Update Release Notes – Java™ SE Development Kit 7, Update 51 (JDK 7u51)
  Je ne trouve pas le texte « Application-Name » dans ces deux liens… Ce sont les attributs « Permissions » et « Codebase » qui sont maintenant obligatoires d'après le premier lien.
  - [^] # Re: Application-Name requis
    
    Posté par Coren le 22 janvier 2014 à 14:30. Évalué à 1.
    La source de cette information, me concernant, ça a été les utilisateurs qui avaient mis à jour.
    
    Ils ne pouvaient plus utiliser l'applet et ils avaient droit à ce message dans la console:
```
 Missing Application-Name manifest attribute for: https://xxx/path/to.jar
 Plug-in Java 10.51.2.13
 Utilisation de la version JRE 1.7.0_51-b13 Java HotSpot(TM) Client VM
```

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.