

2018-01-07 15:00 Mise à jour: Site et DriveSort 1.230 Quelques corrections et améliorations liées a la sécurité sont inclues dans DriveSort v1.230: Du code supportant à moitié un usage en ligne de commande inclu par erreur dans la version précédente a été supprimé vu qu'il n'est pas encore prêt. Lorsqu'on essayait de s'en servir il produisait des messages incompréhensibles liés à la validation et ne faisait rien, donc pas une grosse perte. Le dialogue de sélection de disque se tient mieux à jour lorsqu'un disque apparait ou disparait, même quand Windows n'envoie pas de message WM_DEVICECHANGE pour l'occasion. J'ai remarqué que ceci se produit lorsqu'on monte ou démonte des volumes TrueCrypt pendant des tests mais c'est peut être possible avec d'autres périphériques, donc maintenant tant qu'il est affiché le dialogue de selection de disque utilise à la fois un polling sur le masque des lettres de lecteurs et l'écoute du message WM_DEVICECHANGE pour détecter les changements. Le dialogue de notification de nouvelle version offre maintenant un moyen d'ignorer une version sans avoir à désactiver les vérifications periodiques de version si vous ne souhaitez pas recevoir de rappel pour une version particulière. Lorsqu'une nouvelle version est disponible, vous pouvez donc maintenant choisir d'ouvrir la page de téléchargement, d'ignorer la nouvelle version, ou de décider la prochaine fois que la version sera vérifiée (oui / non / annuler). Si vous choisissez Non, la prochaine notification sera à propos de la version suivant celle ignorée, et proposera le même choix. L'user agent HTTP que DriveSort utilise lorsqu'il vérifie la dernière version a changé de "DriveSort Updater" à "DriveSort/1.230" pour mieux respecter la RFC. Ceci ne change pas grand chose vu que la version était déjà présente dans l'URL de vérification de version, mais ça à une meilleure tête sur le réseau. DriveSort tente maintenant d'activer pour son processus les fonctions de sécurité Windows et les politiques d'aténuation d'attaques suivantes lorsqu'il tourne sur une version de Windows qui les supporte: Prévention de l'exécution des données, Randomisation des images, Protection de la pile, Protection du flux de controle, Valider l'intégrité de la heap et de l'utilisation des handles, Bloque les polices non approuvées, Désactiver les points d'extension, Prefere les DLLs de system32, Evite les DLLs du dossier courant. Je n'ai pas remarqué de problème sur Windows 10.1709 qui les permet tous ou sur Windows XP SP3 qui à ma connaissance ne propose que DEP. Si vous remarquez des incompatibilités avec d'autres versions de Windows merci de m'en informer et je verrai ce que je peux faire. J'ai aussi signé les executables de DriveSort avec des certificates que j'ai généré de manière à permettre la vérification simple de leur intégrité a l'aide du dialogue de propriétés de fichier Windows et de son onglet signatures digitales, bien que Windows va se plaindre de problème d'approbation car mes certificats n'ont pas été émis par une autorité de certification approuvée. J'ai appliqué une signature SHA1 et une signature SHA256 pour que les anciennes et nouvelles versions de Windows aie chacune quelque chose de compréhensible. Le contrôle de compte d'utilisateur va afficher le même avertissement orange qu'avant lorsque DriveSort n'était pas signé lors de la demande de droits administrateur (qui sont nécéssaires car DriveSort a besoin d'un accès disque complet pour faire son travail). L'avertissement est parfaitement normal vu que Windows n'a aucune garantie que mon certificat auto-signé m'apartient bien vu que je n'ai pas payé une autorité de certification réputée pour le vérifier, donc la signature offre en pratique peu d'information de confiance en plus vu qu'elle aurait pu être ajoutée par quelqu'un sur un exécutable modifié en utilisant un certificat qui ressemble au mien. A terme j'acheterai peut être un certificat de signature de code à une des autorités de certification approuvées par Windows, mais c'est un peu cher pour un petit projet perso. Pour le moment si vous voulez vérifier que les signatures sont bien les miennes, mes certificats ont tous les deux f63a19f489360788049e2f7945ce4381ce644777 comme identificateur de la clef, le certificat de signature SHA1 a pour empreinte numérique 8272dfdaf3af740c6ead49dfb08dcc92a74c43f1 et le certificat de signature SHA256 a pour empreinte numérique f73185df917d9ae5382db34a5ad0edaa0417ff20. Pendant que je testais comment les signatures se comportaient, j'ai été un peu surpris de découvrir que le contrôle de compte affiche le même avertissement pour un certificat non approuvé que le contenu de l'exécutable corresponde à la signature ou non, j'aurais supposé qu'une signature invalide aurait déclenché le message d'erreur rouge du contrôle de compte et empeché l'exécution vu qu'il semble dangereux de lancer un exécutable corrompu, que ce soit parceque la signature ou le code qu'elle signe qui soit erroné. Le message affiché dans les détails de la signature numérique du dialogue des propriétés du fichier est plus précis, et distingue clairement les deux cas: Lorsque le certificat ayant produit la signature n'est pas approuvé mais que la signature correspond bien au contenu du fichier exécutable. Lorsque l'exécutable a été modifié, peut importe que le certificat soir approuvé ou non. J'ai aussi affiché un hash SHA1 au dessus de certains liens de téléchargement pour permettre à plus d'utilisateurs de vérifier leurs téléchargements. C'est surtout à l'intention d'utilisateurs qui ne souhaiteraient pas installer GPG4Win pour vérifier les signatures numériques des téléchargements avec ma clef publique GPG. Un hash SHA1 peut être calculé par de nombreux programmes tels 7Zip, sha1sum.

2018-01-07 15:00

Mise à jour: Site et DriveSort 1.230

Quelques corrections et améliorations liées a la sécurité sont inclues dans DriveSort v1.230:

Du code supportant à moitié un usage en ligne de commande inclu par erreur dans la version précédente a été supprimé vu qu'il n'est pas encore prêt. Lorsqu'on essayait de s'en servir il produisait des messages incompréhensibles liés à la validation et ne faisait rien, donc pas une grosse perte.
Le dialogue de sélection de disque se tient mieux à jour lorsqu'un disque apparait ou disparait, même quand Windows n'envoie pas de message WM_DEVICECHANGE pour l'occasion. J'ai remarqué que ceci se produit lorsqu'on monte ou démonte des volumes TrueCrypt pendant des tests mais c'est peut être possible avec d'autres périphériques, donc maintenant tant qu'il est affiché le dialogue de selection de disque utilise à la fois un polling sur le masque des lettres de lecteurs et l'écoute du message WM_DEVICECHANGE pour détecter les changements.
Le dialogue de notification de nouvelle version offre maintenant un moyen d'ignorer une version sans avoir à désactiver les vérifications periodiques de version si vous ne souhaitez pas recevoir de rappel pour une version particulière. Lorsqu'une nouvelle version est disponible, vous pouvez donc maintenant choisir d'ouvrir la page de téléchargement, d'ignorer la nouvelle version, ou de décider la prochaine fois que la version sera vérifiée (oui / non / annuler). Si vous choisissez Non, la prochaine notification sera à propos de la version suivant celle ignorée, et proposera le même choix.
L'user agent HTTP que DriveSort utilise lorsqu'il vérifie la dernière version a changé de "DriveSort Updater" à "DriveSort/1.230" pour mieux respecter la RFC. Ceci ne change pas grand chose vu que la version était déjà présente dans l'URL de vérification de version, mais ça à une meilleure tête sur le réseau.
DriveSort tente maintenant d'activer pour son processus les fonctions de sécurité Windows et les politiques d'aténuation d'attaques suivantes lorsqu'il tourne sur une version de Windows qui les supporte: Prévention de l'exécution des données, Randomisation des images, Protection de la pile, Protection du flux de controle, Valider l'intégrité de la heap et de l'utilisation des handles, Bloque les polices non approuvées, Désactiver les points d'extension, Prefere les DLLs de system32, Evite les DLLs du dossier courant. Je n'ai pas remarqué de problème sur Windows 10.1709 qui les permet tous ou sur Windows XP SP3 qui à ma connaissance ne propose que DEP. Si vous remarquez des incompatibilités avec d'autres versions de Windows merci de m'en informer et je verrai ce que je peux faire.

J'ai aussi signé les executables de DriveSort avec des certificates que j'ai généré de manière à permettre la vérification simple de leur intégrité a l'aide du dialogue de propriétés de fichier Windows et de son onglet signatures digitales, bien que Windows va se plaindre de problème d'approbation car mes certificats n'ont pas été émis par une autorité de certification approuvée. J'ai appliqué une signature SHA1 et une signature SHA256 pour que les anciennes et nouvelles versions de Windows aie chacune quelque chose de compréhensible.

Le contrôle de compte d'utilisateur va afficher le même avertissement orange qu'avant lorsque DriveSort n'était pas signé lors de la demande de droits administrateur (qui sont nécéssaires car DriveSort a besoin d'un accès disque complet pour faire son travail). L'avertissement est parfaitement normal vu que Windows n'a aucune garantie que mon certificat auto-signé m'apartient bien vu que je n'ai pas payé une autorité de certification réputée pour le vérifier, donc la signature offre en pratique peu d'information de confiance en plus vu qu'elle aurait pu être ajoutée par quelqu'un sur un exécutable modifié en utilisant un certificat qui ressemble au mien. A terme j'acheterai peut être un certificat de signature de code à une des autorités de certification approuvées par Windows, mais c'est un peu cher pour un petit projet perso. Pour le moment si vous voulez vérifier que les signatures sont bien les miennes, mes certificats ont tous les deux f63a19f489360788049e2f7945ce4381ce644777 comme identificateur de la clef, le certificat de signature SHA1 a pour empreinte numérique 8272dfdaf3af740c6ead49dfb08dcc92a74c43f1 et le certificat de signature SHA256 a pour empreinte numérique f73185df917d9ae5382db34a5ad0edaa0417ff20.

Pendant que je testais comment les signatures se comportaient, j'ai été un peu surpris de découvrir que le contrôle de compte affiche le même avertissement pour un certificat non approuvé que le contenu de l'exécutable corresponde à la signature ou non, j'aurais supposé qu'une signature invalide aurait déclenché le message d'erreur rouge du contrôle de compte et empeché l'exécution vu qu'il semble dangereux de lancer un exécutable corrompu, que ce soit parceque la signature ou le code qu'elle signe qui soit erroné.
Le message affiché dans les détails de la signature numérique du dialogue des propriétés du fichier est plus précis, et distingue clairement les deux cas:

: Lorsque le certificat ayant produit la signature n'est pas approuvé mais que la signature correspond bien au contenu du fichier exécutable.
: Lorsque l'exécutable a été modifié, peut importe que le certificat soir approuvé ou non.

J'ai aussi affiché un hash SHA1 au dessus de certains liens de téléchargement pour permettre à plus d'utilisateurs de vérifier leurs téléchargements. C'est surtout à l'intention d'utilisateurs qui ne souhaiteraient pas installer GPG4Win pour vérifier les signatures numériques des téléchargements avec ma clef publique GPG. Un hash SHA1 peut être calculé par de nombreux programmes tels 7Zip, sha1sum.