> After this minor hiccup, the experience with MSI was actually quite pleasant. They prepared a patch for the vulnerability within two days of me reporting it and told me which MSI Center release it was to be bundled with, and when they planned to release the new version.
Was NOT expecting a happy ending.
I don't know if the part of MSI Center with the pipe vulnerability is automatically installed on desktops but this is the terribly written software that you need to turn off all the obnoxious lights on your MB and DRAM.
Still one of my most satisfying projects and I use it to this day. These manufacturer apps are so bad. Clevo control center would take over a minute to display a window on screen, it was so aggravating. My replacement program works instantly and is scriptable.
The LED control was implemented over USB. Reversed it by capturing packets with wireshark and replaying them using libusb. MSI probably used ACPI/WMI for this which is much more annoying to work with. I gave up on reversing my laptop's ACPI/WMI features years ago but now that I've got AI I'm trying again, it's been a huge help.
I did some ACPI reverse engineering on an old Toshiba laptop some years ago, with the goal of improving the Linux ACPI drivers. Learnt a lot from it, and wrote a blog post that you might find interesting: https://vorpal.se/posts/2022/aug/21/reverse-engineering-acpi... (100% human written, and I hate that I have to specify that these days).
Nice! If it doesn't exist yet, I'd also recommend taking it a step further and writing an OpenRGB controller for it, so even more people can benefit from the reverse engineering effort.
> So far, for the vulnerabilities I have reported to Google, ASUS, AMD, TP-Link, Netgear, MSI (and more), they have paid out a total of $0 in bug bounties.
Not sure this is that happy of an ending. I wish there was more information why - is the payout process too cumbersome and why is this person continuing to provide uncompensated value to these companies?
And this is the only way to set the charging limit on your laptop, which is awful practice.
Oh, and of course it's so bad, that if you once uninstalled it, you need a special cleanup software which may or may not work, but most likely you're done and can't install instgain.
All to set the charging level which, say, Framework exposes in BIOS.
I know there are some Linux-based ways that are supposed to safely write the threshold to EC, but none worked in my case (reasonably new model, supported by every piece of Linux-based software I checked), and one of them flipped the VMD Controller support on, which makes my nvmes invisible to the installed OS.
MSI Center is one of the worst pieces of software that I can't get rid of. Some features I can't find easy ways to replicate such as controlling the fan/GPU/CPU profiles and battery charging. Updating the software takes FOREVER for what should be fairly simple, and it is extremely slow again for what should be simple software.
A lot of that is natively well supported on Linux now, especially for slightly older MSI laptops. I’d recommend trying out Fedora Kinoite if you’re used to Windows.
I run linux distros and I have to configure my MSI motherboard from the BIOS, or I would have to get my hands on some MSI specific UEFI variable specifications (which you can download as a utf8 text file with a noscript/basic HTML browser, or a whatwg cartel browser but with javascript blocked, thanks).
Video by GN has a little bit of info (but not a lot). Basically they made it so that the pipes only accept input from MSI signed software + the pipes can only invoke MSI signed executables.
> pipes only accept input from MSI signed software
This does not inspire confidence. I'm assuming the pipe exists so that some GUI process running as the current user can perform privileged actions since the other end of the pipe runs as SYSTEM. At this point, just inject a thread into that GUI process and send the command - the service will think it is coming from MSI software, because it is.
The "only invoke MSI signed executables" mitigation is a good one, but if these two things are all they have done, while leaving the "arbitrary registry write" primitive in, then this is still 100% vulnerable to local privilege escalation.
I don’t think “only invoke MSI signed executables” inspires confidence either. There’s ought to be an MSI signed executable that launches arbitrary executables by design and defeats the mitigation.
The author got around a similar mitigation in their exploit for ASUS DriverHub (linked in the original article).
Sure. On Windows, you can allocate memory into an arbitrary process’s address space with VirtualAllocEx, write arbitrary code into those allocated pages using WriteProcessMemory, and start a thread there with CreateRemoteThread.
Now, of course you can’t do this for every process, or it would be trivial to escalate privileges. But I’m pretty sure you can do this for child processes running as the same user.
Yep. There's a system of ACLs and integrity levels which determine whether you're allowed to do this or not (doesn't have to be a child process), but for the most common case:
* a process running at medium integrity level with the current user's token
* another medium integrity process with the same token can open it with PROCESS_CREATE_THREAD and PROCESS_VM_WRITE rights
> So far, for the vulnerabilities I have reported to Google, ASUS, AMD, TP-Link, Netgear, MSI (and more), they have paid out a total of $0 in bug bounties.
Why bother reporting to them ?
You could just as well sell it to third parties if it doesn't interest them.
He makes a point, though: bug bounties exist to incentivize people to find and report bugs to a company. We talk about white, gray, and black hats, roughly based on their level of ethics. For black hats – and some gray hats – money is one of the big reasons they look for vulnerabilities.
Yes I do, but we are speaking of companies with billions. If they can't take this seriously enough that they pay for the vulnerabilities, they deserve to get the bad press.
When all MSI computers get exploited in the wild, I bet that these execs will find money.
If it's my data/money getting stolen, I'd give no fucks about MSI getting a fine or whatever the usual reaction to these fuckups is. On the other hand, if I found an exploit and there wasn't a bounty available, I'd still report it. Betterment of the world and all that.
ok, so you agree that if Linus merges code due to gross negligence, for example he was warned in an email that it contains a RCE and he laughs it off, and still merges it, he should go to jail
No directly related to danger of MSI Center after years of suffering I've removed it.
As my work develop is focused on macOS and Windows apps, I need a Windows laptop and got a light Prestige 13 inch with 32GB and 125H.
It did the trick, but I had years of not understanding how the throttling works. Sometimes if I was using AC and battery was lower than 90% I had CPU throttled at 800Mhz or even 400Mhz never going over 1Ghz. it drove me nuts and my fiddling with MSI Center was always unexpected. I had some strange steps to like connect/disconnect charger, change MSI Center performance settings. none was reliable. (even with Windows Power Settings all the way to max)
Leaving the throttling and fan to Microsoft + Intel seems to do much better work. I no longer look at the task manager for CPU frequency. it just works.
So I have no clue what are the advantages of MSI Center in the first place (maybe bios updating?)
It was an architectural problem, not an encryption problem. Even with AES instead of 3DES, the same issue would exist, which is spoofing the commands of any of the legitimate MSI services.
Is there a valid reason to use any encryption at all if you generally can't sniff the traffic unless you can also sniff the key, and if the key is arbitrary and not verified against anything?
AES is so cheap with hardware acceleration that I could see an argument that it prevents casual sniffing of the traffic. Personally I think the false sense of security would outweigh those benefits, but I'm not in their shoes.
But DES is so broken that it's more of a giant flashing beacon saying "look here there are terrible decisions being made!"
Unfortunately, WiX is still a pain in the ass to use and there's a lot of simple tooling that makes NSIS/InnoSetup/etc shockingly easy to use while the same MSI experience is garbage.
Didn't they discontinue those around VS 2015 or so? Its been a while since I tried. Iirc that's what got replaced with WiX and ClickOnce, both of which are 100X more complicated to use.
Nope, it is the other way around, MSI became the official replacement for exe installers, and MSIX is the evolution of APPX from UWP/Windows Store and the "best practices" format going forward.
By VS packaging tools I mean tbe application project type that generates a MSIX as build outcome.
For some reason, that holds an appxbundle per the article. I'd suspect they needed to run some pre- or post-install code (maybe to check for their hardware?).
As you might have guessed, these are incredibly dangerous tools to be exposing to any authorised user
If your only goal is to stop users from doing what they want on the hardware they own, you are everything that is wrong with the "security" industry today.
> However, because the named pipe only responds to authenticated users, successful exploitation requires valid login credentials for the target machine.
> After this minor hiccup, the experience with MSI was actually quite pleasant. They prepared a patch for the vulnerability within two days of me reporting it and told me which MSI Center release it was to be bundled with, and when they planned to release the new version.
Was NOT expecting a happy ending.
I don't know if the part of MSI Center with the pipe vulnerability is automatically installed on desktops but this is the terribly written software that you need to turn off all the obnoxious lights on your MB and DRAM.
> this is the terribly written software that you need to turn off all the obnoxious lights on your MB and DRAM
You should reverse engineer it and write a free software replacement!
I did this for my Clevo laptop's keyboard LEDs:
https://github.com/matheusmoreira/ite-829x
Still one of my most satisfying projects and I use it to this day. These manufacturer apps are so bad. Clevo control center would take over a minute to display a window on screen, it was so aggravating. My replacement program works instantly and is scriptable.
The LED control was implemented over USB. Reversed it by capturing packets with wireshark and replaying them using libusb. MSI probably used ACPI/WMI for this which is much more annoying to work with. I gave up on reversing my laptop's ACPI/WMI features years ago but now that I've got AI I'm trying again, it's been a huge help.
I did some ACPI reverse engineering on an old Toshiba laptop some years ago, with the goal of improving the Linux ACPI drivers. Learnt a lot from it, and wrote a blog post that you might find interesting: https://vorpal.se/posts/2022/aug/21/reverse-engineering-acpi... (100% human written, and I hate that I have to specify that these days).
This is great, thank you!! Wish I could have read this article back then!!
#handmade_comment
Very good article, thank you!
Nice! If it doesn't exist yet, I'd also recommend taking it a step further and writing an OpenRGB controller for it, so even more people can benefit from the reverse engineering effort.
> So far, for the vulnerabilities I have reported to Google, ASUS, AMD, TP-Link, Netgear, MSI (and more), they have paid out a total of $0 in bug bounties.
Not sure this is that happy of an ending. I wish there was more information why - is the payout process too cumbersome and why is this person continuing to provide uncompensated value to these companies?
And this is the only way to set the charging limit on your laptop, which is awful practice.
Oh, and of course it's so bad, that if you once uninstalled it, you need a special cleanup software which may or may not work, but most likely you're done and can't install instgain.
All to set the charging level which, say, Framework exposes in BIOS.
I know there are some Linux-based ways that are supposed to safely write the threshold to EC, but none worked in my case (reasonably new model, supported by every piece of Linux-based software I checked), and one of them flipped the VMD Controller support on, which makes my nvmes invisible to the installed OS.
Awful, terrible piece of software.
I love those lights. Got a case with clear sides so it's blasting rainbows at my wall all the time.
MSI Center is one of the worst pieces of software that I can't get rid of. Some features I can't find easy ways to replicate such as controlling the fan/GPU/CPU profiles and battery charging. Updating the software takes FOREVER for what should be fairly simple, and it is extremely slow again for what should be simple software.
Last year I built a new computer and made sure that I'd not use a single piece of hardware that will require some shit software from the manufacturer.
I'm really happy with my absolutely no RGB, AIO controlled with a pump header boring PC.
This is the way...
A lot of that is natively well supported on Linux now, especially for slightly older MSI laptops. I’d recommend trying out Fedora Kinoite if you’re used to Windows.
If it's natively supported on linux, an LLM should be able to write a simple Windows program to control it based on the code.
I run linux distros and I have to configure my MSI motherboard from the BIOS, or I would have to get my hands on some MSI specific UEFI variable specifications (which you can download as a utf8 text file with a noscript/basic HTML browser, or a whatwg cartel browser but with javascript blocked, thanks).
Nowadays, you can let AI Agent analyze the binary file and figure out how to control hardware, then, let AI Agent wrote a code for it.
I wish the author went into a bit more detail about how MSI fixed it, as is usual in write ups like this.
It left me thinking maybe the patch introduced a different vulnerability that’s still under an embargo :)
Video by GN has a little bit of info (but not a lot). Basically they made it so that the pipes only accept input from MSI signed software + the pipes can only invoke MSI signed executables.
https://youtu.be/Eck8NnoaD4M
> pipes only accept input from MSI signed software
This does not inspire confidence. I'm assuming the pipe exists so that some GUI process running as the current user can perform privileged actions since the other end of the pipe runs as SYSTEM. At this point, just inject a thread into that GUI process and send the command - the service will think it is coming from MSI software, because it is.
The "only invoke MSI signed executables" mitigation is a good one, but if these two things are all they have done, while leaving the "arbitrary registry write" primitive in, then this is still 100% vulnerable to local privilege escalation.
I don’t think “only invoke MSI signed executables” inspires confidence either. There’s ought to be an MSI signed executable that launches arbitrary executables by design and defeats the mitigation.
The author got around a similar mitigation in their exploit for ASUS DriverHub (linked in the original article).
Oh right, yes, either that, or one of them is bound to have a DLL hijack issue that can be taken advantage of.
Or just a TOCTOU race :)
> At this point, just inject a thread into that GUI process and send the command
Can you or someone else expand on that?
Sure. On Windows, you can allocate memory into an arbitrary process’s address space with VirtualAllocEx, write arbitrary code into those allocated pages using WriteProcessMemory, and start a thread there with CreateRemoteThread.
Now, of course you can’t do this for every process, or it would be trivial to escalate privileges. But I’m pretty sure you can do this for child processes running as the same user.
Yep. There's a system of ACLs and integrity levels which determine whether you're allowed to do this or not (doesn't have to be a child process), but for the most common case:
* a process running at medium integrity level with the current user's token
* another medium integrity process with the same token can open it with PROCESS_CREATE_THREAD and PROCESS_VM_WRITE rights
More likely MSI just being MSI. They're infamous for being far more concerned about image than most vendors so don't expect much info.
> So far, for the vulnerabilities I have reported to Google, ASUS, AMD, TP-Link, Netgear, MSI (and more), they have paid out a total of $0 in bug bounties.
Why bother reporting to them ?
You could just as well sell it to third parties if it doesn't interest them.
You understand the concept of doing something that doesn't bring direct monetary benefit?
He makes a point, though: bug bounties exist to incentivize people to find and report bugs to a company. We talk about white, gray, and black hats, roughly based on their level of ethics. For black hats – and some gray hats – money is one of the big reasons they look for vulnerabilities.
Yes I do, but we are speaking of companies with billions. If they can't take this seriously enough that they pay for the vulnerabilities, they deserve to get the bad press.
When all MSI computers get exploited in the wild, I bet that these execs will find money.
But it's not "MSI computers" it's actual people getting pwned.
I know but I don't think there is any other solution. These companies speak money, if you don't speak money they ignore you.
Getting your users computers infected and having to deal with bad buzz, prosecutions, loss of sales, would most likely wake them up.
Sending them a mail ? They don't care.
If it's my data/money getting stolen, I'd give no fucks about MSI getting a fine or whatever the usual reaction to these fuckups is. On the other hand, if I found an exploit and there wasn't a bounty available, I'd still report it. Betterment of the world and all that.
you understand the concept of zero days ?
companies should be better and if not, criminally liable for their bad code.
Ok? I agree with everything. What does that have to do with reporting exploits that don't have bounties?
I don't think you thought this through.
does this also apply to individual developers?
should Linux Torvalds or the ffmpeg developers go to jail if they merge a RCE zero-day into the Linux kernel or into ffmpeg?
gross negligence / honest mistake
if you cannot differentiate the 2, :insert rude thing here:
ok, so you agree that if Linus merges code due to gross negligence, for example he was warned in an email that it contains a RCE and he laughs it off, and still merges it, he should go to jail
glad you are consistent in your beliefs
In other words, bootlicking the corpo-authoritarians?
You're actually helping the people that use the software from getting pwned, companies are secondary beneficiaries.
Keep toeing the line and help them put the nooses around your necks.
No directly related to danger of MSI Center after years of suffering I've removed it.
As my work develop is focused on macOS and Windows apps, I need a Windows laptop and got a light Prestige 13 inch with 32GB and 125H.
It did the trick, but I had years of not understanding how the throttling works. Sometimes if I was using AC and battery was lower than 90% I had CPU throttled at 800Mhz or even 400Mhz never going over 1Ghz. it drove me nuts and my fiddling with MSI Center was always unexpected. I had some strange steps to like connect/disconnect charger, change MSI Center performance settings. none was reliable. (even with Windows Power Settings all the way to max)
Eventually I've found on a reddit thread this (strangely hidden) uninstaller: https://www.msi.com/faq/9934 https://download.msi.com/uti_exe/nb/CleanCenterMaster.zip
Leaving the throttling and fan to Microsoft + Intel seems to do much better work. I no longer look at the task manager for CPU frequency. it just works.
So I have no clue what are the advantages of MSI Center in the first place (maybe bios updating?)
Is there any valid reason to still be using 3DES in 2026?
It was formally deprecated in 2018 and has been surpassed in just about every single way by AES long before that.
At this point I feel like it's use is such a huge red flag
It was an architectural problem, not an encryption problem. Even with AES instead of 3DES, the same issue would exist, which is spoofing the commands of any of the legitimate MSI services.
Yeah it wouldn't have changed this specific case but still why use it? It's slower even without AES NI!
Is there a valid reason to use any encryption at all if you generally can't sniff the traffic unless you can also sniff the key, and if the key is arbitrary and not verified against anything?
AES is so cheap with hardware acceleration that I could see an argument that it prevents casual sniffing of the traffic. Personally I think the false sense of security would outweigh those benefits, but I'm not in their shoes.
But DES is so broken that it's more of a giant flashing beacon saying "look here there are terrible decisions being made!"
What casual sniffing? It's a pipe. If you can sniff that, you can sniff all the traffic because the very first message is the key in plaintext.
I mean they're still using Inno Setup which was pretty cool in 2004.
Unfortunately plenty of folks still didn't got the memo MSI and MSIX exist.
Unfortunately, WiX is still a pain in the ass to use and there's a lot of simple tooling that makes NSIS/InnoSetup/etc shockingly easy to use while the same MSI experience is garbage.
msix is just a different beast entirely too.
What about using the Visual Studio packaging tools?
I live on .NET/C++ universe in regards to Windows development, so it might be it isn't as nice for not blessed stacks.
Didn't they discontinue those around VS 2015 or so? Its been a while since I tried. Iirc that's what got replaced with WiX and ClickOnce, both of which are 100X more complicated to use.
Nope, it is the other way around, MSI became the official replacement for exe installers, and MSIX is the evolution of APPX from UWP/Windows Store and the "best practices" format going forward.
By VS packaging tools I mean tbe application project type that generates a MSIX as build outcome.
For some reason, that holds an appxbundle per the article. I'd suspect they needed to run some pre- or post-install code (maybe to check for their hardware?).
I mean I still build windows installers with NSIS which has somehow just-worked for decades.
These software from hardware vendors are awful quality just glancing at the GUI window.
As you might have guessed, these are incredibly dangerous tools to be exposing to any authorised user
If your only goal is to stop users from doing what they want on the hardware they own, you are everything that is wrong with the "security" industry today.
You cut the rest of the sentence
> including ones without local admin
I don’t know anything about windows, but it looks like a local privilege escalation.
I don't want any random program on my computer to be able to change all of my system settings and terminate security processes.
> However, because the named pipe only responds to authenticated users, successful exploitation requires valid login credentials for the target machine.
Eh
Authenticated for shared files and printers. The pipe itself doesn't authenticate much, but the built-in network server does.
You have physical access to the machine. Dump its bios and inject this https://download.microsoft.com/download/8/a/2/8a2fb72d-9b96-...
Shrug.emoji
Random .docx file that looks like an upload to MS?
[dead]