Crucial MX500 SSD Firmware M3CR046 Vulnerable to Buffer Overflow Attacks

[btarunr]

One of the most popular SATA SSD brands, the Crucial MX500, has a vulnerability in its firmware version M3CR046. Apparently, specific ATA packets issued from the host can trigger a buffer overflow in the drive, cause data leaks. The vulnerability has been chronicled as CVE-2024-42642. At this point we're not sure if older versions of firmware for the MX500 are affected. M3CR046 happens to be the latest firmware version we could see in the Crucial Storage Executive app, which means the company is still working on a firmware update.



View at TechPowerUp Main Site | Source

 

[A Computer Guy]

I have a 2TB MX500 in my Linux box. I guess Linux users will need to use the bootable ISO method.

 

[Chaitanya]

Are crucial mx500 the only ones affected or are other brands also affected?

 

[Pepamami]

I have a 2TB MX500 in my Linux box. I guess Linux users will need to use the bootable ISO method.

Ye, fwupd prob would not have anything.
But I think u can attach that iso to ur bootloader (like grub) with no problems.

 

[Bwaze]

Are crucial mx500 the only ones affected or are other brands also affected?

I don't know if Silicon Motion SM2259H is even used in any other brand or model of SSD.

 

[TheLostSwede]

I don't know if Silicon Motion SM2259H is even used in any other brand or model of SSD.

Did you try using the TPU SSD database?

TechPowerUp

Solid-state-drive database with specifications for products launched in recent years. Includes specs, photos, and technical details.

www.techpowerup.com

 

[Assimilator]

What a nothingburger... the only way you can send the specially crafted ATA commands that can trigger this firmware bug, is if you already control the system containing that drive. At which point you can just send a FORMAT command instead.

God I hate these so-called "security" researchers that spend their time coming up with the most contrived nonsensical scenarios just so they can get their 15 seconds of fame.

 

[Konomi]

What a nothingburger... the only way you can send the specially crafted ATA commands that can trigger this firmware bug, is if you already control the system containing that drive. At which point you can just send a FORMAT command instead.

God I hate these so-called "security" researchers that spend their time coming up with the most contrived nonsensical scenarios just so they can get their 15 seconds of fame.

While not beneficial to most people (and certainly not newsworthy), you can at least say someone cared enough to fix it, which in turn means someone actually bothered to go over potentially old code instead of leaving it to break other things.

 

[_roman_]

proof of concept Source code and instructions how to compile for ubuntu. Should apply to any linux kernel based distro.

GitHub - VL4DR/CVE-2024-42642

Contribute to VL4DR/CVE-2024-42642 development by creating an account on GitHub.

github.com

source https://www.cve.org/CVERecord?id=CVE-2024-42642
Those guys used a wrong webpage -> correct one: https://www.crucial.com

Homepages for MY Curcial P5 Plus or Curcial BX300 claim no firmware updates. Maybe this could be a way around for updates. https://www.crucial.com/support/storage-executive

Benefits of Storage Executive​

• Enable the Momentum Cache feature and make many SSD operations up to 10x faster
• Download the latest firmware
• See how much storage you’ve used
• Monitor your SSD’s operating temperature and overall health
• Reset your SSD’s encryption password
• Verify your SSD’s model number for warranty claims
• Clear all data stored on the drive

Compatibility and language support
OS COMPATIBILITY	Microsoft® Windows® 7, Windows 8, Windows 10, Windows 11
DRIVE COMPATIBILITY	Crucial X10 Pro, X9 Pro, X9, X8, X6, P-series, T-series, T500, MX-series, BX-series, M550, and M500 SSDs
LANGUAGE AVAILABILITY	English, French, German, Spanish, Italian, Russian, Japanese, Korean, Simplified Chinese, Traditional Chinese

 

[lol1kVR]

Greetings folks, I'm the researcher that reported this CVE, so let's clarify a few things for those who don't quite understand what's going on or those who are somewhat worried about this.

-As someone in the comments mentioned, to trigger any of the bugs reported under this CVE, one must have root access to the PC communicating with the controller. It is by itself certainly not a trivial thing, but all sorts of methods exist to achieve that. Since the attack vector is local and elevated privileges are required for this, it's no surprise that this CVE is rated 6.7 (medium) at NVD, which means it's certainly not that critical.
-The first two bugs are in essence DoS attacks, which are not particularly a big deal, however the effect is different than simply formatting the drive or corrupting it; This kind of DoS does not (as far as I can tell) corrupt anything on the drive, but does cause the drive to crash, effectively making it absolutely unresponsive (to any ATA command) until the next power cycle. Is this sort of effect interesting to attackers? Maybe. Maybe not, but I believe it's still worth reporting.
-The last bug is a controlled buffer overflow. What this means, is that, with possibly some more research, code execution could be achieved on the SSD controller. Now this is much more interesting, because attackers residing within the controller are not subject to all sorts of mitigations applied on modern host operating systems.
-SM2259 is shared among multiple SSD vendors, and thus it's absolutely possible that any of these bugs might apply to them, too. Although, keep in mind that vendors might make code modifications to the firmware, which means that these specific bugs might not be applicable to them, but similar ones might be found within the same vulnerable mechanism.

If you have any further questions, you are welcome to ask. Sometimes media outlets misinterpret things, which can cause confusion, so I'm more than willing to clarify whatever is needed.

 

[phanbuey]

Greetings folks, I'm the researcher that reported this CVE, so let's clarify a few things for those who don't quite understand what's going on or those who are somewhat worried about this.

-As someone in the comments mentioned, to trigger any of the bugs reported under this CVE, one must have root access to the PC communicating with the controller. It is by itself certainly not a trivial thing, but all sorts of methods exist to achieve that. Since the attack vector is local and elevated privileges are required for this, it's no surprise that this CVE is rated 6.7 (medium) at NVD, which means it's certainly not that critical.
-The first two bugs are in essence DoS attacks, which are not particularly a big deal, however the effect is different than simply formatting the drive or corrupting it; This kind of DoS does not (as far as I can tell) corrupt anything on the drive, but does cause the drive to crash, effectively making it absolutely unresponsive (to any ATA command) until the next power cycle. Is this sort of effect interesting to attackers? Maybe. Maybe not, but I believe it's still worth reporting.
-The last bug is a controlled buffer overflow. What this means, is that, with possibly some more research, code execution could be achieved on the SSD controller. Now this is much more interesting, because attackers residing within the controller are not subject to all sorts of mitigations applied on modern host operating systems.
-SM2259 is shared among multiple SSD vendors, and thus it's absolutely possible that any of these bugs might apply to them, too. Although, keep in mind that vendors might make code modifications to the firmware, which means that these specific bugs might not be applicable to them, but similar ones might be found within the same vulnerable mechanism.

If you have any further questions, you are welcome to ask. Sometimes media outlets misinterpret things, which can cause confusion, so I'm more than willing to clarify whatever is needed.

If you were running a VM on this SSD, could this attack be carried out through a hypervisor? - or does the attacker need direct access to the controller?

 

[Assimilator]

Greetings folks, I'm the researcher that reported this CVE, so let's clarify a few things for those who don't quite understand what's going on or those who are somewhat worried about this.

-As someone in the comments mentioned, to trigger any of the bugs reported under this CVE, one must have root access to the PC communicating with the controller. It is by itself certainly not a trivial thing, but all sorts of methods exist to achieve that. Since the attack vector is local and elevated privileges are required for this, it's no surprise that this CVE is rated 6.7 (medium) at NVD, which means it's certainly not that critical.
-The first two bugs are in essence DoS attacks, which are not particularly a big deal, however the effect is different than simply formatting the drive or corrupting it; This kind of DoS does not (as far as I can tell) corrupt anything on the drive, but does cause the drive to crash, effectively making it absolutely unresponsive (to any ATA command) until the next power cycle. Is this sort of effect interesting to attackers? Maybe. Maybe not, but I believe it's still worth reporting.
-The last bug is a controlled buffer overflow. What this means, is that, with possibly some more research, code execution could be achieved on the SSD controller. Now this is much more interesting, because attackers residing within the controller are not subject to all sorts of mitigations applied on modern host operating systems.
-SM2259 is shared among multiple SSD vendors, and thus it's absolutely possible that any of these bugs might apply to them, too. Although, keep in mind that vendors might make code modifications to the firmware, which means that these specific bugs might not be applicable to them, but similar ones might be found within the same vulnerable mechanism.

If you have any further questions, you are welcome to ask. Sometimes media outlets misinterpret things, which can cause confusion, so I'm more than willing to clarify whatever is needed.

Now see, this is much more useful than sensationalist press articles that obscure the pertinent details behind fearmongering. Thanks for being transparent, and sorry for any harsh words from myself- I just get very annoyed at seeing CVEs reported as if they're the next Y2K, and upon investigation they're absolutely not.

 

[Mazer]

Are older firmwares affected by this too?

 

[lol1kVR]

If you were running a VM on this SSD, could this attack be carried out through a hypervisor? - or does the attacker need direct access to the controller?

That's an interesting question. I don't know for sure, but I guess that it would depend on the actual implementation of the hypervisor (whether it emulates FW update requests to the controller or not). I did a quick test on VirtualBox, and seems like it doesn't support the ATA commands needed to trigger the vulnerability at all (there's probably a bunch of ATA commands that aren't supported when running from a VM). So I'd conclude that an attacker would most likely have to send the specially-crafted commands from the host OS.

Now, about older versions - seems like older versions of M3CR04X FW are no longer available for download, so I can't check them. I did take a quick look at M3CR033 FW, and similar issues *seem* to be present there (however, I currently don't have a drive to test it on).

 

[Dr. Dro]

Now see, this is much more useful than sensationalist press articles that obscure the pertinent details behind fearmongering. Thanks for being transparent, and sorry for any harsh words from myself- I just get very annoyed at seeing CVEs reported as if they're the next Y2K, and upon investigation they're absolutely not.

Sensible and technical data do not attract clicks, after all.

 

[chrcoluk]

That's an interesting question. I don't know for sure, but I guess that it would depend on the actual implementation of the hypervisor (whether it emulates FW update requests to the controller or not). I did a quick test on VirtualBox, and seems like it doesn't support the ATA commands needed to trigger the vulnerability at all (there's probably a bunch of ATA commands that aren't supported when running from a VM). So I'd conclude that an attacker would most likely have to send the specially-crafted commands from the host OS.

Now, about older versions - seems like older versions of M3CR04X FW are no longer available for download, so I can't check them. I did take a quick look at M3CR033 FW, and similar issues *seem* to be present there (however, I currently don't have a drive to test it on).

If I remember right there is multiple hardware revisions of the drive each with their own firmware, so the problem here is that if all the models are affected, only the latest model gets the newest firmware, as I think you tested the one for the latest model, hopefully crucial will check and also provide updates for the other revisions as well (if needed).

 

[trparky]

I did a quick test on VirtualBox, and seems like it doesn't support the ATA commands needed to trigger the vulnerability at all (there's probably a bunch of ATA commands that aren't supported when running from a VM).

Well yeah, that's because VirtualBox is a Type 2 hypervisor. I imagine using a Type 1 hypervisor aka a bare-metal hypervisor would probably work.

 

[dirtyferret]

God I hate these so-called "security" researchers that spend their time coming up with the most contrived nonsensical scenarios just so they can get their 15 seconds of fame.

I found a security bug that impacts all Nvidia GPUs, if your Nvidia GPU is left unattended on a subway for several hours it can become vulnerable to "subway tech pirates". Nvidia is yet to acknowledge this security flaw.

 

[lol1kVR]

If I remember right there is multiple hardware revisions of the drive each with their own firmware, so the problem here is that if all the models are affected, only the latest model gets the newest firmware, as I think you tested the one for the latest model, hopefully crucial will check and also provide updates for the other revisions as well (if needed).

I hope so too. I had tried contacting them multiple times over the course of 3 months before reporting this to MITRE, and I've heard nothing from them to this day. Hopefully now that it's published, they'll consider fixing it.

Well yeah, that's because VirtualBox is a Type 2 hypervisor. I imagine using a Type 1 hypervisor aka a bare-metal hypervisor would probably work.

Ah right, type 2 hypervisors are usually the first thing that pops in my head when I read "VM".
I agree with you about type 1 though, I'd be pretty surprised if people couldn't, for example, update their drive's FW with HyperV enabled. Thanks for the clarification.

 

[R-T-B]

What a nothingburger... the only way you can send the specially crafted ATA commands that can trigger this firmware bug, is if you already control the system containing that drive. At which point you can just send a FORMAT command instead.

God I hate these so-called "security" researchers that spend their time coming up with the most contrived nonsensical scenarios just so they can get their 15 seconds of fame.

I hate the media outlets that sensationalize them for no reason.

The actual research is helpful.

 

[Minus Infinity]

Never updated the fw on my MX500, and never even checked. Always weary of doing fw on ssd.

 

[trparky]

Never updated the fw on my MX500, and never even checked. Always weary of doing fw on ssd.

Easy, I've done it several times. Though I did make sure that I had a full disk image before I did the update. Just in case.

 

[Boombastik]

I don't see anything new. Did company respond to this?