Journal La signature de code en Java

Posté par . Licence CC by-sa
30
19
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

  1. 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

  2. Vérification de la chaine
    openssl verify -CAfile cert-chain.txt codesigning.cer

  3. 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

  4. Transformation du PKCS12 en KeyStore Java
    keytool -importkeystore -srckeystore cert-chain.pkcs12 -srcstoretype PKCS12 --destkeystore codesigning.jks -srcalias tomcat

  5. Vérification du keystore
    keytool -list -v -keystore codesigning.jks

  6. 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

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

  8. 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 . É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 . É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 . É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 (page perso) . É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 . É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 . É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 . É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 . É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 . Évalué à 8. Dernière modification le 19/01/14 à 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 . É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 . É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 . É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 . É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 . É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 . É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 . Évalué à 10. Dernière modification le 20/01/14 à 11:25.

        Ce commentaire a été supprimé par l'équipe de modération.

  • # Application-Name requis

    Posté par (page perso) . É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 :)

Suivre le flux des commentaires

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