Bug in populaire SATA-ssd Crucial MX500 maakt buffer overflow mogelijk

Een bug in een populaire SATA-ssd van Crucial kan leiden tot een bufferoverflow. Het probleem zit in ieder geval in de recentste firmware van de Crucial MX500. Deze ssd is ook in de Pricewatch nog steeds erg populair.

Een beveiligingsonderzoeker heeft details over de bug online gezet. Het gaat om een kwetsbaarheid die wordt getrackt als CVE-2024-42642 in de Crucial MX500. Dat is een SATA-ssd uit 2018 die, ondanks de leeftijd, ook onder tweakers nog erg populair is. De bug maakt het mogelijk een bufferoverflow te veroorzaken als de ssd in een pc is ingebouwd.

De onderzoeker die het lek ontdekte, zegt dat het mogelijk is om specifieke ATA-packets uit te geven vanuit de host. Daarmee kan een bufferoverflow ontstaan waarmee data kan worden achterhaald. De kwetsbaarheid zit in ieder geval in de recentste versie van de firmware, M3CR046. Het is niet duidelijk of ook oudere firmwareversies kwetsbaar zijn, maar dat lijkt wel aannemelijk. De onderzoeker heeft de bug getest op een pc die op Ubuntu 22.04 draait, maar weet niet of het ook mogelijk is de bug op andere besturingssystemen te misbruiken.

Opvallend is dat de onderzoeker veel details over de kwetsbaarheid heeft gepubliceerd en ook een proof-of-concept online heeft gezet waarmee de bug kan worden uitgebuit, maar niets schrijft over contact met Crucial. Het is niet bekend of het bedrijf inmiddels een firmware-update voor de ssd's heeft uitgebracht. Ook de CVE-notering wordt momenteel nog onderzocht, zegt de onderzoeker.

Reacties (51)

[koboy]

Is de gepubliceerde kwetsbaarheid wel gelezen door iemand van Tweakers of is er een stukje overgetikt?

De publicatie beschrijft 3 bugs in het firmware update systeem aan de SSD kant. De eerste twee lijken (voorlopig) alleen te leiden naar een crash van de controller in de SSD, de laaste heeft POTENTIEEL mogelijkheden om de firmware te modificeren en daarmee lastiger op te merken data lekken/corruptie te veroorzaken.

Leuk gevonden, maar om deze bugs in te zetten heb je kernel-level toegang tot te hardware nodig. Je hebt dan al dusdanige toegang tot de SSD dat het nemen van een rare omweg via firmware exploits niet voor de hand ligt. Het is dan alsof je een pakketje naar de buren stuurt via DHL ofzo ipv gewoon even aan te bellen.

[Floris4970]

Mogelijkheid om permanent virus te installeren dmv geïnfecteerde SSD firmware?

[koboy]

Kenmerk van een virus is dat het zich verspreid. Daarbij is de firmware grootte vrij beperkt dus heel veel ruimte heb je niet.
Verspreiden zou dan ook weer kwetsbaarheden in de SATA controller op het moederbord nodig hebben, aangezien SATA volgens mij een point to point protocol is. Dan kom je bij de volgende uitdaging dat je dan weer van de SATA controller bij het OS niet komen, en een stapje verder etc.

Al met al wordt het best een complex ding dat je moet schrijven, wat waarschijnlijk niet binnen het kleine stukje ruimte past dat over is in de firmware. Ja, je zou de SSD kunnen gaan gebruiken als opslag, maar het wordt wel allemaal erg vergezocht voor een SSD die al meer dan 10 jaar geleden geïntroduceerd is en toch wel langzaam EOL gaat.
Maar je bent afhankelijk van een dusdanige hoeveelheid exploits in ook andere delen van de computer dat het patchen van 1 daarvan genoeg is om al het werk dat je hebt gedaan om zeep te helpen. Eerste kandidaat voor de aanpak hier is de benodigde exploit in de SATA driver van het OS als die al aanwezig is.....

Mijn verwachting is dat er een firmware update komt vanuit Crucial, en dit alles een stille dood gaat sterven. De hele publicatie stinkt trouwens naar irresponsible disclosure aangezien er nog geen CVE nummer/severity is, en er ook geen blijk van gegeven wordt dat er contact met Crucial is geweest.

[uiltje]

Ik heb me er net even op in proberen te lezen, maar het lijkt erop dat de 32 bit RISC SoC's die vaak in dit soort SSD's zit een kleine bootrom hebben, en daarna de meer complexere aansturing (e.g. wear leveling) van de flash halen. Dus die firmware hoeft zich niet per se te houden aan enige ruimte beperkingen. Verder kan het virus simpelweg bestanden detecteren en infecteren, zodat het virus via het OS of applicaties zichzelf verder kan verspreiden. Tenminste, dat is wat ik hier uit af kan leiden; als je informatie hebt die dat tegenspreekt hoor ik het graag. Maar voor nu lijkt het me logischer dat de restricties die je noemt niet van toepassing zijn.

[koboy]

Zoals ik in een latere reactie al schreef: voor complexere zaken zou de controller de ssd als firmware plaats moeten kunnen gebruiken.
De wear leveling data opslaan op de nand chips is natuurlijk logisch, net als de gereserveerde ruimte voor slijtage. Dat gebeurde op draaiend roest ook al. Hier zit dus potentieel een risico op bijvoorbeeld persistente virussen wanneer de OS boot bestanden aangepast worden vanuit de SSD firmware.

Ik zet hier heel bewust potentieel. De onderzoekers hebben een serie commando's ontdekt (bug3) die de controller niet zou moeten accepteren, maar die de controller niet laat crashen zoals bij bug 1 en 2. Ik ben het met ze eens dat hier een MOGELIJKHEID ligt voor remote code execution, maar ook dat hiervoor nog meer onderzoek nodig is.

De vraag is dus of hackers de moeite willen steken in
1. überhaupt werken aan een SSD die 10 jaar geleden is geïntroduceerd, minimaaln2 revisies met verschillende controllers heeft en richting EOL gaat
2. het hacken/documenteren van de SSD firmware
3. het ontwikkelen van een rootkit

Dit alles in de context dat het gaat om een component die zeker de afgelopen 8 jaar een selectieve doelgroep aanspreekt en voor de massa inmiddels is vervangen door goedkopere opties, en dat er eenvoudiger opties zijn om bijna hetzelfde te bereiken (EFI infecteren bijvoorbeeld). Voor staats hackers misschien interessant als bekend is dat deze SSD bij hun doelgroep in gebruik is als bootdisk.
N.B. het betreft hier een SATA SSD, die dus over het algemeen niet meer ingezet zal worden als bootdisk. SATA is als boot medium al jaren vervangen door M.2-PCI-E, zowel in prijs als prestaties.

Edit: nogmaals: de manier waarop de disclosure plaatsvond, zonder toegewezen severity of contact met Crucial wijst er op dat de onderzoekers ook donders goed weten dat de verwachtte impact minimaal is en ze nog even zo snel mogelijk hun 5 minutes of fame wilden maximaliseren.

[Reactie gewijzigd door koboy op 15 september 2024 10:06]

[uiltje]

Het probleem met je post is niet zozeer dat de conclusie fout is maar dat het foute informatie bevat:

1. Er is niet echt een limiet aan de firmware omdat waarschijnlijk alleen de boot loader zich in de SoC bevind: de reset zit in de flash. Je geeft zelf echter aan dat "de firmware grootte beperkt is". Bij een SSD heb je ruimte voor 512 GiB aan flash. En ik had het over de aansturing van de wear leveling, niet de wear leveling zelf.

2. Je zou op een of andere manier de SATA controller aan moeten vallen. Ik zie niet in waarom dat het geval zou zijn als je direct de files op een computer aan kan passen.

Ik vind het fijn dat je probeert op mijn kritiek te reageren, maar ik zie niet hoe je verhaal deze punten aanstipt. Dat betekend naar mijn mening dat er een +2 post is met aantoonbaar foute informatie (of in ieder geval ongestaafde beweringen).

[Reactie gewijzigd door uiltje op 15 september 2024 16:46]

[koboy]

Sorry voor de kortere reactie die nu volgt, maar ik had een uitgebreide klaarstaan, tikte een keer te veel op terug, en toen werd niet alleen mijn andere app gesloten maar ook mijn reactie verdween naar /dev/null.

TLDR van die reactie:
Je hebt gelijk, ik heb dit in mijn reactie op jou niet goed verwoord, excuses daarvoor. afleiding staat een goed resultaat in de weg.
Je schrijft zelf dat WAARSCHIJNLIJK de controller alleen een boot rom bevat, ik heb ook gezocht en geen eenduidig antwoord kunnen vinden. Echt veel opslag is er niet nodig omdat de bootable iso voor update van de mx500 wel 24mb groot is, en het hebben van dat beetje opslag ook voordelen heeft. Vergeet niet dat de MX500 indertijd bekend stond als een product met premium features.

Disqualificeert deze mogelijke/waarschijnlijke fout een +2 informatief? Naar mijn mening niet; het maakt het werk van de hacker onafhankelijk van exploits in de rest van de hardware, maar de rest van het verhaal dat er op volgt blijft nog steeds correct.

[laurxp]

In theorie ja, maar alleen als het doelwit geen Bitlocker gebruikt. Met full-disk encryption kan de SSD vrij weinig kwaad doen.

[iRob87]

Waarom zou de mallware niet steeds opnieuw geladen kunnen worden vanuit de firmware eeprom in het systeemgeheugen van het OS?

[laurxp]

Hoe zou dat moeten gebeuren? De SSD kan niet zomaar naar willekeurige geheugenlocaties schrijven. Er zou dan een driver in het OS moeten zitten die bewust bij iedere boot malware uitleest - maar die driver is foetsie bij een schone install.

Het enige stuk dat unencrypted is, is de bootloader/kernel - maar met Secure Boot is het onmogelijk om dat aan te passen. Het BIOS weigert simpelweg om dan op te starten.

[vrilly]

Meestal hebben moderne embedded systemen, waaronder ssd controllers wel een vorm van "secure boot". De bootloader met de public key van crucial wordt in de microcontroller gebrand op moment van productie en de upgradebare firmware in de externe flash chip wordt alleen uitgevoerd als de code signing op orde is.
De aanvaller kan wellicht tijdelijk code uitvoeren op de mcu door deze bugs, maar op het moment dat je iets permanent wil aanpassen zal de ssd bij de volgende boot dienst weigeren.

[WillySis]

Voor een hacker is het nemen van een omweg niet vreemd.
Als een pakketje met de post versturen inhoud dat jezelf anoniem kan blijven (en ook niet binnen het bereik van een camera komt) zou iemand die kwaadwillend is die omweg graag nemen. Wel lullig als het daarna bij de buren (dus de afzender) wordt bezorgd.

[koboy]

Doel voor een hacker is in eerste instantie kernel level toegang te krijgen. Dat gaat vaak via omwegen bijvoorbeeld een lekke API van een videochat programma, dat praat met een lekke webcam driver, etc, tot er kernel level access is. Op dat moment kan de hacker doen wat hij wil.
Om deze bugs te gebruiken is al kernel level toegang nodig. Enige mogelijke kwetsbaarheid is een persistentie in de SSD firmware afdwingen, maar om weer terug te komen naar het reguliere OS heb je weer een hele keten van andere exploits nodig, en dat alles voor een stukje hardware wat allang niet meer zo populair is.

N.B. ik heb er zelf 3, jaren oud en gekocht omdat het 1 van de weinige betaalbare SSD's was met stroomuitval bescherming.

[DataGhost]

Je interpretatie van de analogie is fout omdat je erbij verzint dat eventueel anoniem versturen een voordeel zou kunnen zijn. Het is meer als het hebben van de sleutel van het huis van de buren, maar toch kiezen via het openstaande kleine toiletraampje op de bovenverdieping naar binnen te gaan. In beide gevallen ben je binnen zonder sporen/braakschade maar toegang had je toch van tevoren al gekregen, en de tweede manier is ongelofelijk veel omslachtiger. Enig voordeel van de omslachtige methode heb je niet. Of dus weer terug naar het pakketje: je hebt er met koeienletters op geschreven "groeten van de buren op nr XX" en op geen enkele manier anoniem verstuurd, terwijl je die dus veel makkelijker gewoon langs had kunnen brengen.

[Reactie gewijzigd door DataGhost op 13 september 2024 13:02]

[kuurtjes]

Het artikel zegt inderdaad alleen maar "specifieke ATA-packets uit te geven vanuit de host". Dat lijkt me echt niet iets dat je zomaar kan gaan doen.

[The Zep Man]

Een goed gevonden kwetsbaarheid. Deze aanval is niet zo interessant als je als aanvaller zelfgekozen ATA-pakketten over de SATA bus kan sturen. Je hebt dan al zoveel toegang dat het aanvallen van storage devices niet veel zal toevoegen.

[Reactie gewijzigd door The Zep Man op 13 september 2024 10:06]

[GertMenkel]

De pakketten werden gewoon met root-toegang verstuurd, daar heb je geen directe hardwaretoegang tot de bus voor nodig.

De remote code execution op de firmware van de SSD vind ik toch wel naar. Dat je data kan lezen is niet zo'n probleem, op zich. Het risico hierin zit hem in een SSD-rootkit, of eventueel het extraheren van de hardwareencryptiesleutel om daarmee ATA Secure Erase onbruikbaar te maken.

[The Zep Man]

De pakketten werden gewoon met root-toegang verstuurd, daar heb je geen directe hardwaretoegang tot de bus voor nodig.

Het hebben van rootrechten is effectief gelijk aan directe hardwaretoegang hebben. Als een aanvaller al die rechten heeft, dan is misbruik van de SATA-bus het minste van je zorgen.

Het risico hierin zit hem in een SSD-rootkit, of eventueel het extraheren van de hardwareencryptiesleutel om daarmee ATA Secure Erase onbruikbaar te maken.

Een rootkit enkel op de SSD installeert een aanvaller niet zomaar. En eenmaal een systeem gecompromitteerd is vertrouw je natuurlijk niet op een interne verwijderfunctie. Sterker nog, er zijn voldoende bedrijven die dat sowieso niet doen. Storage gaat gewoon de shredder in.

[Reactie gewijzigd door The Zep Man op 13 september 2024 10:22]

[GertMenkel]

Als een aanvaller al die rechten heeft, dan is misbruik van de SATA-bus het minste van je zorgen.

Ten eerste is zelfs root niet almachtig (SELinux/AppArmor bestaat), ten tweede heb je nog steeds SMM en andere hardwaremodi waar root niet zomaar bij kan komen, zelfs niet als die kerneldrivers in kan laden. Firmware-updates worden niet zomaar zonder handtekening toegepast, en root op je laptop geeft je niet de private key van Crucial.

Een rootkit enkel op de SSD installeert een aanvaller niet zomaar. En eenmaal een systeem gecompromitteerd is vertrouw je natuurlijk niet op een interne verwijderfunctie. Sterker nog, er zijn voldoende bedrijven die dat sowieso niet doen. Storage gaat dan gewoon de shredder in.

Ik betwijfel dat iemand zijn hele SSD de shredder in gooit nadat er een keer een virus op gestaan heeft. Na Wannacry zijn de meeste PC's gewoon opnieuw geïnstalleerd en is de hardware hergebruikt. Kwestie van de timestamp van bestanden op de schijf monitoren en het virus kan een jaar later spontaan weer verschijnen.

Bedrijven die storage de shredder in doen, hebben toch het geld wel om geen Crucial-SSD's te kopen.

[Reactie gewijzigd door GertMenkel op 13 september 2024 10:26]

[The Zep Man]

Ik betwijfel dat iemand zijn hele SSD de shredder in gooit nadat er een keer een virus op gestaan heeft.

Ik doe dat al zou ik last hebben van malware. Geen shredder, maar wel effectieve vernietiging.

Bedrijven die storage de shredder in doen, hebben toch het geld wel om geen Crucial-SSD's te kopen.

Bedrijven maken zich niet druk om welk merk SSD's gebruikt wordt. En ja, ook duurdere merken verdwijnen gewoon in de shredder bij sommige bedrijven.

[nullbyte]

Dan kan je net zo goed je hele PC wegmieteren. Voor in het geval van een mogelijke rootkit.

[MSalters]

"root toegang"- nee, dat is een intern OS concept. Dan zou WIndows veilig zijn, want geen root.

Nee, wat je hiervoor nodig hebt is kernel-level access. In een normaal OS is de SATA driver verantwoordelijk voor het zenden van SATA pakketjes. Maar er is geen harde scheiding tussen drivers, en een andere driver zal het doorgaans dus ook kunnen.

[The Zep Man]

"root toegang"- nee, dat is een intern OS concept. Dan zou WIndows veilig zijn, want geen root.

Windows gebruikt een andere term voor hetzelfde: "LOCAL SYSTEM".

[MSalters]

Nope. Root is simpelweg user 0. Windows heeft een veel gedetailleerder systeem. Je hebt Administrator (S-(S-1-5-*-500, user account), Administrators (S-1-5-32-544, een groep van user accounts), LOCAL_SYSTEM (S-1-5-18), Local Service (S-1-5-19), en Network Service (S-1-5-20).

[GertMenkel]

All these bugs were verified on an Ubuntu 22.04 64-bit machine using the standard Linux SCSI driver over the SG_IO interface.

De exploit is ontwikkeld op Linux dus daarom root-toegang. In theorie kan het ook zonder root (/dev/sd* zijn op mijn machines van de groep "disk" met -rw als groepstoegang, dus ieder account in die groep zou het voor elkaar moeten kunnen krijgen).

Wil je op Windows handmatig commando's sturen, dan roep je DeviceIoControl aan met IOCTL_ATA_PASS_THROUGH of misschien IOCTL_ATA_PASS_THROUGH_DIRECT. Daarvoor heb je lees+schrijfrechten nodig op het apparaat, dus je hebt administratortoegang nodig.

Voor zover ik weet heb je op Windows geen NT AUTHORITY\SYSTEM nodig om dat apparaat te openen dus vanuit een technisch oogpunt heb je wellicht nog minder permissies nodig dan op Linux. Vanuit een praktisch oogpunt kan zo'n beetje elk administratoraccount wel SYSTEM benaderen natuurlijk, al genereert dit wel weer wat extra verdachte logregels die je antivirusoplossing hopelijk kan detecteren.

In theorie kunnen zowel Linux als Windows deze exploit voorkomen door drivercode aan te passen. Het nadeel daarvan is dat hdparm/crystal disk mark dan allerlei functies verliezen. Speciale berichten worden ook onder andere gebruikt voor firmware-updates van SSD's/HDD's, programma's die drive self tests uitvoeren, secure erase aanroepen, en meer van dat soort dingen.

[P-e-t-j-e]

Local system is als administrator simpel te impersonaten via bv psexec? Of begrijp ik het verkeerd?

[Reactie gewijzigd door P-e-t-j-e op 13 september 2024 21:12]

[GertMenkel]

Ja, zeker. Het veroorzaakt wel de nodige logging waar je beveiligingssoftware over kan waarschuwen, of misschien zelfs ingrijpen met de nodige kernelhooks.

Op de meeste PC's kun je aannemen dat je vanaf administrator naar local system kan komen, maar die niveaus zijn nog steeds gescheiden want onder water zit er wel degelijk verschil tussen.

[Floris4970]

Ik neem aan dat het risico is dat je hiermee data kan achterhalen die normaal gesproken niet toegankelijk is voor de betreffende user?

Ik kan uit het artikel niet helemaal wijs worden wat de echte impact van deze bug is.

[The Zep Man]

Ik neem aan dat het risico is dat je hiermee data kan achterhalen die normaal gesproken niet toegankelijk is voor de betreffende user?

Als je rechten hebt om dit te misbruiken, dan heb je rechten om data van andere gebruikers in te zien. Dat hoeft niet via de SSD.

[Reactie gewijzigd door The Zep Man op 13 september 2024 10:21]

[Floris4970]

Ja dat idee had ik ook, maar ik lees dus in dit artikel niet echt terug wat het probleem dan is..

[MSalters]

Access checks gebeuren toch al niet op SATA nivo, dus dit verandert daar niks aan.

De moderne manier van beveiligen is dat data van een user encrypted is, en het wachtwoord van de user nodig voor de decryptie. Admin users kunnen dan wel bij de encrypted data, en daarvoor was deze bug toch al niet nodig.

[Olaf van der Spek]

De onderzoeker die het lek ontdekte, zegt dat het mogelijk is om specifieke ATA-packets uit te geven vanuit de host. Daarmee kan een bufferoverflow ontstaan waarmee data kan worden achterhaald.

Wat voor data? Het is niet abnormaal voor een host om data van een SSD te kunnen lezen..

[GertMenkel]

Het is wat vervelend als de firmware van je SSD wordt gekaapt, dat lijkt me hier het grootste risico. In het ergste geval komt er een rootkit in je SSD terecht, en dan kun je Windows zoveel herinstalleren als je wilt, het virus blijft zichzelf op de schijf droppen na de eerste installatie.

In theorie zou je ook een hele vage aanval kunnen uitvoeren door misbruik te maken van de DMA-toegang die zo'n SSD kan krijgen, maar dat lijkt me niet heel betrouwbaar.

[P-e-t-j-e]

Is diskencryptie zoals bitlocker hier geen oplossing voor? De data op disk wordt dan volgens mij encrypted weggeschreven(zodat het encrypt blijft wanneer je bijv ineens de stroom eraf zou halen) dus de sata controller kan geen 'normale' data wegschrijven naar het flashgeheugen omdat windows dit bij inlezen (gaat proberen te) decrypten wat natuurlijk niet lukt

Toch?

-edit- zie dat men in de verdere comments vooral over linux praat maar er zal ook een bitlocker iets voor windows zijn?

[Reactie gewijzigd door P-e-t-j-e op 13 september 2024 21:09]

[GertMenkel]

Bitlocker als extra laag bovenop zou het lekken van data van de disk in elk geval voorkomen, maar Bitlocker heeft een "half aan" modus (waar de schijf gedeeltelijk versleuteld is en nieuwe bestanden niet worden versleuteld) en met genoeg geklooi zou de schijf dat waarschijnlijk kunnen forceren na de volgende herstart. Met geforceerde versleuteling zou je daar geen last van hebben.

Windows kan echter niet booten vanaf een schijf die volledig versleuteld is. De EFI-partitie blijft onversleuteld. In theorie is dat geen probleem, maar secure boot heeft het de afgelopen jaren zwaar te verduren gehad dus wie weet of die bescherming nog werkt.

[wooha]

Of als je hiermee persistent malware in de SSD controller kan installeren, vervolgens een vulnerability in de ATA kernel driver gebruiken om na het booten weer in de kernel terecht te komen. Die ATA kernel vulnerability moet dan wel bestaan natuurlijk. Dan helpt ook encryptie van de SSD niet meer.

[blorf]

Dit moet ook dan virtueel kunnen, zonder schijf en zonder kernel-aanpassing. Althans, ik zou niet weten waarom niet.
Over welke buffer hebben we het?

[Reactie gewijzigd door blorf op 13 september 2024 10:43]

[TheDeeGee]

Niemand wist hiervan totdat die onderzoeker alles online gooide zonder dat er fix voor is...

Vind dat zeer trolly om het zo maar te zeggen, laat Crucial er dan eerst van weten voordat je het openbaar maakt.

[blorf]

Volgens mij ontbreken er significante details. Een stuk PC-hardware heeft nergens meer permissies dan de beheerder van het systeem. Als een schijf een buffer-overflow kan veroorzaken kan alleen maar een programma dat ook door dezelfde interface op dezelfde manier aan te spreken.

[Reactie gewijzigd door blorf op 13 september 2024 11:10]

[PsiTweaker]

Het is niet bekend of het bedrijf inmiddels een firmware-update voor de ssd's heeft uitgebracht.

Ach, wat zou het toch mooi zijn, als Tweakers dit had uitgezocht en een link naar de betreffende firmware pagina had geplaatst.

Dát zou een prima service zijn, maar nu moet iedere Tweakers zelf het maar uitzoeken 😠

[haelerien]

Letterlijk het eerste resultaat als je "Crucial MX500 firmware" in een zoekmachine gooit. M3CR046 is nog steeds de nieuwste versie.
Een beetje moeite doen is niet het einde van de wereld

[Reactie gewijzigd door haelerien op 13 september 2024 10:13]

[PsiTweaker]

Letterlijk het eerste resultaat als je "Crucial MX500 firmware" in een zoekmachine gooit. M3CR046 is nog steeds de nieuwste versie.
Een beetje moeite doen is niet het einde van de wereld

Inderdaad, maar ook u plaatst geen link en het bovenstaande geldt natuurlijk ook voor Tweakers.Net.

Ondanks dat ik geen tijd had om zelf een de link te zoeken, dan toch dan maar even tijd gemaakt ( als service voor iedereen )

Crucial MX500 SSD firmware and support

[Reactie gewijzigd door PsiTweaker op 13 september 2024 10:22]

[Jan121]

Tsja, inderdaad een hele vreemde en overbodige zin, zeker als er al eerder in het artikel geschreven is dat de meest recente firmware de kwetsbaarheid bevat.

De kwetsbaarheid zit in ieder geval in de recentste versie van de firmware,

[mangahuisman]

Wat een ophef...

Daarnaast is het zo dat bedrijven vaak nieuwere hardware gebruiken, en oude SATA SSD’s zoals de Crucial MX500 uit 2018 zijn minder gebruikelijk in professionele omgevingen. Bovendien, als een aanvaller fysieke toegang heeft tot een systeem, zijn er vaak veel eenvoudigere en effectievere manieren om toegang te krijgen tot gevoelige data of controle over het systeem (zoals het plaatsen van hardware backdoors of direct stelen van data).

Kortom, hoewel deze kwetsbaarheid in theorie een risico vormt, is het risico in de praktijk voor bedrijven en individuen zonder fysieke toegang tot hun systemen erg laag.

[as400]

Onverrmijdelijk. Elk onderdeel met een eigen embedded processor draait code die kan gesubverteerd worden. Stel je voor dat iemand op de bootsector SectorLISP zet : heel je SSD vol haakjes ;-)

[eymey]

Ach, dit is niet het enige probleem met de drive.

Ik heb er eentje van 4 TB in een Synology NAS zitten, naast een Samsung 870 QVO van 8 TB.

Vooropgesteld: Ik weet dat Synology in principe alleen goede werking garandeert en support levert icm. z'n eigen SSD's. Maar goed.

Met de Samsung is er geen centje pijn. Doet het voortreffelijk. Maar de MX500 gooit zichzelf constant van de SATA bus af (verdwijnt gewoon), wat vervolgens alle shares die op deze SSD staan ontoegankelijk maakt. Ik moet de SSD dan uit de NAS halen, er weer in stoppen en dan het storage volume zichzelf weer laten assemblen.

Hij draait al de laatste firmware,met volgens crucial een fix foor een 'corner case' waarbij precies mijn probleem optreedt. Dat updaten van de firmware was een gepruts op zichzelf. En het heeft helaas niet geholpen. Het gebeurt nog steeds.