L’outil Capture d’écran ne supprime pas toutes les données après un recadrement, ce qui les laisse accessibles à tout individu malveillant.
4 « J'aime »
Ça m’en bouge une sans toucher l’autre… 
5 « J'aime »
je trouve cela dingue de pouvoir retrouver une partie de l’image qui n’est pas sur l’image.
Merci de l’info.
J’espère que mon soft de capture sous linux Mageia n’est pas concerné.
(spectacle sous KDE Plasma)
2 « J'aime »
Ça montre à quel point on se préoccupe plus d’optimiser l’espace de stockage. On imagine le poids superflu de ces fichiers depuis pas mal d’années…
1 « J'aime »
Après si l’individu malveillant est dans mon secteur et que je le chope, c’est XFCE jusqu’à la fin de ses jours!
Sous FreeBsd! 
3 « J'aime »
Pire, MacOS !!! 
1 « J'aime »
Donc si j’ai rien compris du tout, le risque c’est que je fais une copie d’écran, et comme en même temps j’ai une page ouverte ou j’achète un film porno avec ma carte bleue l’image contient donc mes données de CB. Ensuite je recadre l’image pour envoyer à mon chef juste une partie de l’écran pour lui montrer un truc super important. Mon chef reçoit mon image, et comme il est vicieux il analyse l’image et retrouve tout mon écran et pas seulement la partie recadrée, et du coup il peut me prendre ma CB pour acheter des sextoys?
J’ai bon?
3 « J'aime »
L’expression correcte est « Cela m’en touche une sans faire bouger l’autre », expression popularisée par notre ancien Président Jacques Chirac (à ne pas confondre avec Patrick).
https://fr.wiktionary.org/wiki/cela_m’en_touche_une_sans_faire_bouger_l’autre
3 « J'aime »
Sauvés sur Windows 10 
Enfin en théorie la faille est censée y être aussi vu qu’il s’agit du même programme…
Non, justement, ce n’est pas le même. Il a juste le même nom, mais il a été très fortement modifié, et ça m’étonnerait pas qu’il ait même été intégralement réécrit, celui de Windows 10 étant une application Win32 classique alors que dans Windows 11 c’est une application UWP.
A moi les clés Cryptos !
Il suffit de prendre une capture d’écran sous Windows 11 avec son outil intégré, de l’enregistrer immédiatement, puis de la recadrer avant de l’enregistrer à nouveau dans le même fichier. Normalement, après cette seconde sauvegarde, le fichier devrait être plus léger qu’avant. Or, ce n’est pas le cas. Pourquoi ? Parce que la plupart des données de la première version sont encore présentes.
Clairement une faille de flemme de programmeurs …
Combien de softs de recadrage sont touché ?
Non, même pas.
Simplement que le fichier est ouvert en mode écriture au lieu de écriture avec troncature. Dans le premier mode, on réécrit simplement par-dessus les données du fichier, sans effacer les anciennes (et donc si la nouvelle version du fichier est plus petite que la nouvelle, il peut rester des anciennes données non écrasées), dans le second monde on commence pas tronquer le fichier à 0 octet avant de le réécrire.
Mais pour le développeur de l’application, c’est strictement le même effort dans les deux cas, c’est simplement la valeur du flag indiquant le mode d’ouverture du fichier qui diffère.
En gros, le développeur a écrit un truc de ce genre (ça c’est un exemple avec le open de la norme POSIX, mais celui de Windows doit être assez proche) :
fd = open(filepath, O_RDWR)
Au lieu de
fd = open(filepath, O_RDWR | O_TRUNC)
C’est un oubli, pas de la flemme. Et sans doute parce que beaucoup ne savent même pas qu’il faut ajouter O_TRUNC, les API de beaucoup de langages surchargeant de toute façon open avec O_TRUNC par défaut quand on ouvre un fichier en écriture.
C’est par exemple le cas de PHP :
Ou encore de Python :
4 « J'aime »
Simplement que le fichier est ouvert en mode écriture au lieu de écriture avec troncature.
Ok !
Je ne pensais pas qu’il y’avait 2 modes à ce niveaux …
Mais pour le développeur de l’application, c’est strictement le même effort dans les deux cas, c’est simplement la valeur du flag indiquant le mode d’ouverture du fichier qui diffère.
Selon vos explications effectivement, ça va donc prendre 1 sec à patcher !
Et je retire ce que j’ai dis …
2 « J'aime »
bonjoçur
je vous cite :
" En fin de compte, si l’image tronquée n’a pas le même poids que la capture d’écran originale, tout va bien. Du moins, normalement."
Je ne comprends pas le raisonnement. L’image n’aura jamais le même poids une fois retouchée (quelle que soit la modification).
Bon, elle pourrait peser pareil mais ce serait un coup du hasard.
Soit plus soit moins. Et normalement toujours plus dans le cas d’une mise à jour du fichier d’origine.
Cependant on peut très bien modifier une image, l’enregistrer dans un nouveau fichier et qu’elle soit aussi plus lourde.
1 « J'aime »
Justement, dans le cas du bug, si, elle a la même taille. Parce que la nouvelle image est plus petite et a été réécrite par dessus le début de l’ancienne image, mais que le fichier n’a ensuite pas été tronqué à la nouvelle taille, l’OS croit donc que le fichier n’a pas changé de taille, et à la fin du fichier il reste des données non écrasées de l’ancien fichier.
Pour faire une analogie, imagine que tu as un carton rempli de cannettes de 33cl. Tu décides d’y mettre à la place le même nombre de canettes de 12cl.
La bonne pratique, c’est de d’abord vider complètement le carton, puis de mettre tes nouvelles canettes dedans. Ainsi, plus de trace des anciennes canettes. C’est ce qu’il se passe normalement quand on ouvre un fichier en écriture avec le flag O_TRUNC.
Ce qui se passe dans le cas du bug, c’est qu’au lieu de vider le carton d’abord, tu remplaces simplement les canettes petit à petit, en enlevant une 33cl quand tu as besoin de faire de la place. Tu en enlèves une, tu met une 12, tu enlèves une seconde 33, tu met deux 12, tu enlèves une 3ème 33, etc, jusqu’à ce que tu ais rentré tes nouvelles canettes. Il reste alors des grosses canettes dans le carton.
1 « J'aime »
une image BMP de X_pixels /Y_pixels aura toujours le même poids; même si tu redessines dessus.
Par contre, j’ai fais le test sur W10 : quand on réduit X_pixels /Y_pixels et qu’on resauvegarde, le poids de l’image est réduit.
Donc, pas de « bug » sur W10… 
En attendant sous macos pas besoin de logiciel tiers pour enregistrer écran. Cmd + 3 copie d’écran, Cmd+4 tu choisis la partie que tu veux capturer. Cmd+5 tu peux enregistrer en vidéo ton écran (et tu choisis quelle partie tu veux enregistrer) pas besoin de perdre son temps à recadrer dans paint ou d’installer un logiciel tiers de plus pour combler une fonction que n’a pas l’os…
@MattS32 @Peggy10Huitres
Ou alors un retaillage correct du filestream est manquant a la fin de l’écriture.
Dans tous les cas, il est probable que la faille ne touche pas que les images, puisqu’elle concerne en réalité le traitement du flux écrit sur un flux existant.
1 « J'aime »
Sous Windows, c’est natif aussi hein, au moins depuis Windows 10, et il me semble que c’était même déjà dans Windows 7.
Et pas besoin non plus de recadrer à posteriori, tu peux faire directement une capture avec le bon cadrage (mais ça peut arriver de se tromper ou d’oublier de cadrer, d’où le fait de le faire parfois à posteriori).
En attendant sous macos pas besoin de logiciel tiers pour enregistrer écran. Cmd + 3 copie d’écran, Cmd+4 tu choisis la partie que tu veux capturer. Cmd+5 tu peux enregistrer en vidéo ton écran (et tu choisis quelle partie tu veux enregistrer) pas besoin de perdre son temps à recadrer dans paint ou d’installer un logiciel tiers de plus pour combler une fonction que n’a pas l’os…
Et pour une capture entière d’une page web qui défile c’est Cmd + Quoi ?
En général on utilise des logiciels tiers quand l’outils natif n’est pas assez « puissant » pour notre utilisation. Je n’utilise aucun outils Natif, même pas le File Manager de Windows, c’est dire …