Microsoft brengt fix uit voor screenshot-bug in Windows

Microsoft heeft een fix uitgebracht voor voor de zogenaamde aCropalypse-bug in Windows. Deze bug maakte het mogelijk om weggeknipte info uit afbeeldingen, terug te halen of te reconstrueren. De bug was eerder deze maand ook ontdekt in Android 10.

De fix is vrijdag beschikbaar gemaakt voor het Knippen & Aantekenen-programma in Windows 10 en het Knipprogramma in Windows 11. Beide tools, en de bugfix, kunnen via de Microsoft Store gedownload worden. De fix zorgt ervoor dat weggeknipte info uit screenshots of afbeeldingen voortaan niet meer terug te halen is.

Microsoft gaf de kwetsbaarheid een laag beveiligingsrisico mee. Het bedrijf stelt dat er 'ongewone handelingen' nodig zijn vooraleer het tot eventuele exploitatie van gegevens kan komen.

De aCropalypse-bug werd eerder deze maand ontdekt in Android 10 door software-engineer Chris Blume. Die stelde dat dezelfde exploit ook werkt op Windows-systemen. Onderzoeker David Buchanan bevestigde de bevindingen.

Knipprogramma Windows 11 aCropalypse

Reacties (38)

[ToMaSZ]

Als ze toch met het knipprogramma bezig zijn kunnen ze misschien ook ein-de-lijk een keer fixen dat bij gebruik van 2 schermen met een verschillende schaling maar de helft van het scherm gescreenshot kan worden met win-shift-s

[fjh40]

Ben ik dus niet de enige die hier problemen mee heeft gehad, alleen op kantoor last van gehad. Volgens mij heeft het sterk te maken met Displaylink en is het probleem niet aanwezig zodra de schermen direct op de grafische output aangesloten zitten. Bij mij was het op een gegeven moment gek genoeg dat ik (heb op kantoor vijf schermen inclusief laptop) ongeveeer 3.5 scherm kon screenshotten maar de rest viel af...

Sinds de nieuwe versie van Windows 11 geen last meer van gehad icm HP Thunderbolt Dock G4 en een HP EliteBook 860 G9.

[ToMaSZ]

In mijn geval is het alleen bij 2 of meer schermen met verschillende schaling. Als ik alles op 100 (of alles op 125) procent zet werkt het goed. Zie ook deze Microsoft answers thread
Met Windows 10 kniptooltje nooit last van gehad

[LongTimeAgo]

Oh en ik maar denken dat t aan m'n Dell dock lag haha.
Soms werkt t wel, soms moet ik handmatig gaan knippen in paint.

[sebastienbo]

Bij mij werkt de snipping tool vaak zelfs helemaal niet meer...

[GeroldM]

Als het maken van screenshots een significant deel van je workflow is, kijk dan eens verder en overweeg GreenShot. Frreware en doet zijn werk uitstekend.

[telenut]

shareX als je nog meer wil doen ermee, zoals bijvoorbeeld screen recordings maken

[Poltergeist]

Fenetre, voor als je het simpel wil houden en ook screen recordings wil maken...

[ochhanz]

Dat en de shortcut icon voor screen snip in the quick settings panel weer terughalen zoals W10 dat had (ook vrij willekeurig dat MS dit weggehaald heeft gezien je wel nog de andere quick setting acties kan toevoegen of weghalen).

[Levo75]

Of dat win+shift+s überhaupt werkt.

[StGermain]

Wat mij intrigeert is dat het dezelfde bug is in Android en Windows, is er dan gedeelde code of hebben developers bij beide systemen dezelfde fout gemaakt?

[CyBeR]

Het is een vrij simpele fout om te maken, dus dat ze gewoon dezelfde fout hebben gemaakt is heel aannemelijk.

Je kunt elke image editor ook heel simpel checken op deze fout eigenlijk, neem een file, maak een deel ervan zwart zodat dat deel goed comprimeert of crop een deel weg (indien uncompressed), sla op en kijk of de file van grootte veranderd is. Zo niet heb je een grote kans dat je deze bug te pakken hebt.

[.oisyn]

Het heeft ook niets met afbeeldingen an sich te maken. Het kan elke applicatie die bestanden wegschrijft overkomen.

[sebastienbo]

Misschien een library?

[fre0n]

Hoe haal je verwijderde info (pixels) terug uit een plat plaatje, worden vorige versies meegestuurd (als layer ofzo) in png of jpg???

[Reactie gewijzigd door fre0n op 23 juli 2024 08:57]

[The Zep Man]

Het schijnt dat de bug te maken heeft met het bewerken van een afbeelding (screenshot) in Snip & Sketch. Als het nieuwe bestand kleiner is dan het oude bestand (bijvoorbeeld door cropping), dan houdt Snip & Sketch de originele bestandsgrootte van de oude afbeelding aan bij het opslaan van de afbeelding. Aan het einde van het bestand van een nieuwe afbeelding zit na overschrijven garbage data van een oudere afbeelding, waarmee mogelijk bepaalde 'weggeknipte' delen gereconstrueerd kunnen worden.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:57]

[PsiTweaker]

Je zou dus denken, dat ze bij het verkleinen ( crop ) van een afbeelding, alleen de 'border' van de afbeelding aanpassen en daarna weer de gehele file ( met alle originele data ) opslaan.

Terwijl bij een echt verkleining, natuurlijk de gehele file aangepast ( herschreven ) moet worden en alleen dat opgeslagen wordt, wat te zien.

[Reactie gewijzigd door PsiTweaker op 23 juli 2024 08:57]

[jerisson]

Het is puur een probleem op file-niveau en niet op afbeeldingsniveau.

Ze verkleinen de afbeelding wel degelijk, maar vergeten een truncate (het reduceren van de filesize naar 0, om het eenvoudig uit te leggen) te doen van de bestaande file. Daardoor wordt het eerste deel van de bestaande file overschreven met de nieuwe afbeelding en het laatste deel bevat nog stukken van de oude afbeelding. Als er een truncate zou gebeuren zou de file terug aangroeien bij het wegschrijven, maar zou de oude data er niet inzitten.

Wel of niet truncaten is een kwestie van een flag mee te geven of weg te laten bij het aanroepen van de functie die file open voor schrijven. Zo een bug kan dus redelijk eenvoudig voorkomen als men niet oplet.

[sebastienbo]

.

[Reactie gewijzigd door sebastienbo op 23 juli 2024 08:57]

[jerisson]

Het heeft niks met lui zijn te maken maar met het meegeven van "w" ipv "wt" aan een fopen (file open) functie (afhankelijk van de api). Letterlijk een foutje - door even onoplettend te zijn, de api niet te kennen, of zoals bij Android een api-change, met 1 letter verschil kan hetzelfde probleem veroorzaken bij mspaint.

Als je een file wilt wegschrijven van 100bytes over een file die 1000bytes is dan zal "wt" de file eerst reduceren naar 0 bytes en vervolgens 100 wegschrijven (file is 100 bytes groot.) Gebruik je per ongeluk "w" dan open je de file van 1000 bytes, en schrijf je op de eerste 100bytes nieuwe data. In geval van deze bug is die data gewoon de inhoud van flattened en gecropte afbeelding. De resterende bytes bevatten nog de oude data, die mits analyze ervan toelaten om oorspronkelijke afbeelding te herstellen.

En lui? Een crop functie zit standaard in een beeldverwerkingslibrary. Dat is zowat de eenvoudigste operatie die er is. Het opslaan van verschillende layers of borders zou meer werk zijn omdat dit simpelweg niet ondersteund wordt door de meeste afbeeldingsformaten (en zou problemen opleveren met andere viewers - dat dit niet gebeurd bij deze bug komt door de header van de image file en een eventuele END-tag/bytes aan het einde van de afbeelding (maar niet de file) ).

Dit is gewoon een stomme bug door het verkeerd gebruik van een file-io api. Niets meer, niets minder.

[The Zep Man]

Je verwart twee zaken:
• De afbeelding
• Het bestand.

De bug heeft niets te maken met het bewerken van afbeeldingen, maar enkel met de methode hoe bestanden opgeslagen worden. Dezelfde bug zou in Notepad kunnen zitten voor tekstbestanden.

[sebastienbo]

.

[Reactie gewijzigd door sebastienbo op 23 juli 2024 08:57]

[The Zep Man]

Ik verwar het niet .
Ik ben zelf ook devops.

Dat zegt niets, zo blijkt.

Als je een functie maakte om iets te verkleinen dan vind ik het gewoonweg dom om ongebruikte data in het bestand te laten...

Het heeft niets te maken met het groter of kleiner maken van een afbeelding in aantal pixels. Maak de afbeelding wit en twee keer zo groot. De grootte van het bestand zou kleiner moeten zijn (dankzij compressie), maar wordt dit niet omdat het bestand niet eerst met grootte 0 wordt weggeschreven.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:57]

[sebastienbo]

.

[Reactie gewijzigd door sebastienbo op 23 juli 2024 08:57]

[.oisyn]

Want ik begrijp niets van je antwoorden

Het lijkt er vooral op dat je niets begrijpt van de fout. Misschien daar eerst eens hoogte van krijgen voordat je andere devs als lui bestempelt?

Jij bent dus van mening dat het normaal is dat een developer die de taak heeft gekregen om een crop functie te schrijven, geen invloed zou hebben op de bestandsgrootte?

Als iemand een crop functie schrijft in een applicatie die werkt met plaatjes, dan doe je sowieso al niets met bestanden! Je past het plaatje gewoon aan in het geheugen en klaar, je hebt een crop-functie gemaakt. De fout heeft dan ook niets met het croppen van een plaatje te maken.

De fout zit in de functie die een plaatje wegschrijft naar een bestand, en dan met name hoe het weg te schrijven bestand geopend wordt. De applicatie opent het bestand, schrijft de data weg, en sluit het bestand weer. Door een bug is het bestand met de verkeerde vlaggetjes geopend, wat ervoor zorgt dat het deel van de oude inhoud die niet overschreven wordt bewaard blijft. Nogmaals, dit heeft niets met de crop-functie te maken. Als je een plaatje van 1000 bytes wegschrijft over een ander geheel ongerelateerd bestand dat toevallig al bestaat en 10.000 bytes groot is, dan treedt de bug ook op.

[Reactie gewijzigd door .oisyn op 23 juli 2024 08:57]

[vdws]

Tja... En zo maakt iedereen fouten en slippen die fouten soms zelfs door naar een live omgeving.

Zo maak ik ook fouten en jij ook. De devs in kwestie lui? Denk het niet. Ze zullen er vast van geleerd hebben. (en de testers ook)

[Oon]

Het gaat specifiek om het overschrijven van een groter bestand met een kleinere versie, waarbij de data van de grotere versie niet geheel wordt gewist.

Daarmee geef je in de nieuwe instructies bovenaan het bestand aan dat het een kleiner bestand is, maar blijft de data van het oude bestand bestaan; je overschrijft alleen de data van het ingeknipte stukje.

Als je de instructies dus weer aanpast naar het originele formaat kun je alles dat niet in het nieuwe bestand zit uitlezen, wat dus een ongeknipt screenshot zou kunnen zijn.

[CH4OS]

De data wordt bij opslaan niet verwijderd uit het bestand, het blijft dus beschikbaar en verwezen naar andere informatie.

Edit: mea culpa, ik zie dat ik wat laat reageer.

[Reactie gewijzigd door CH4OS op 23 juli 2024 08:57]

[The Zep Man]

Microsoft brengt fix uit voor screenshot-bug in Windows

De fix is vrijdag beschikbaar gemaakt voor het Knippen & Aantekenen-programma in Windows 10 en het Knipprogramma in Windows 11. Beide tools, en de bugfix, kunnen via de Microsoft Store gedownload geüpdatet worden.

Dit is niet exact een screenshot-bug, maar een bug in hoe het programma Knippen & Aantekenen ('Snip & Sketch') omgaat met bewerkingen en het opslaan van afbeeldingen. De kans is groot dat de 'klassieke' manier van screenshots nemen (print screen -> mspaint.exe -> edit -> save) niet beïnvloed wordt door deze bug, net als third-party programma's om screenshots mee te maken en op te slaan waarschijnlijk geen last hebben van deze bug.

[edit]
Het lijkt dat de bug beperkt is tot Snip & Sketch, en dat zelfs de oude Snipping Tool hier geen last van heeft.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:57]

[JRMBelgium]

Nu nog de mogelijkheid om screenshots te maken op een HDR scherm want dat blijft na jaren nog steeds uit...zucht...

[TheVivaldi]

Ik dacht dat men altijd zei dat bedrijven niet vlak voor het weekend (zouden moeten) uitrollen?

[dannyvanhooy]

Na de bugfix werkt snipping tool niet meer op mijn Win 11. New knop doet niets meer. Enig oplossing?

[MrFax]

Ik snap het hele verhaal niet helemaal: Als de IEND stuk het bestand eindigt, dan is de rest toch aan de filesystem om te verwijderen, of blijft er data aan het bestand zelf plakken? Zo gek is het niet dat als jij een screenshot opslaat, en deze daarna cropt, dat de data die overblijft niet zomaar gelijk wordt verwijderd. Dat is aan de SSD om te doen met de "erase" TRIM-functie. Op harde schijven is het zelfs nog makkelijker om het bestand weer compleet te maken.

[Reactie gewijzigd door MrFax op 23 juli 2024 08:57]

[Anoniem: 450173]

Wat is dat screenshot?

[IDI0CRACY]

Hier is een how to:

https://www.youtube.com/watch?v=S0VQCvClo8E

Jeeeesss hebben jullie geen humor meer hier....die moderatie hier wordt met de dag slechter.. -1 kom op zeg....Dit is gewoon een hilarisch antwoord op de vraag wat een screenshot is..!!
Het is nog waar ook... letterlijk!!

[Reactie gewijzigd door IDI0CRACY op 23 juli 2024 08:57]