Some models of Gigabyte motherboards download firmware updates insecurely(wired.com)
wired.com
Some models of Gigabyte motherboards download firmware updates insecurely
https://www.wired.com/story/gigabyte-motherboard-firmware-backdoor/
132 comments
Right - people who are upset that their motherboard can just drop arbitrary executables into their OS ZOMG would do well to consider the fact that their motherboard is literally handling executing their OS and managing all input and output.
The issue here is not motherboard can execute arbitrary code. Motherboards are trusted hardware. You pass all your keystrokes, network traffic and memory transfers over it.
The issue is motherboard uses its trusted status to run software that performs raw HTTP downloads for firmware. Which is probably bad but might alternatively just be futureproofing to avoid having to deal with expiring certs.
The issue here is not motherboard can execute arbitrary code. Motherboards are trusted hardware. You pass all your keystrokes, network traffic and memory transfers over it.
The issue is motherboard uses its trusted status to run software that performs raw HTTP downloads for firmware. Which is probably bad but might alternatively just be futureproofing to avoid having to deal with expiring certs.
Indeed they would be well to but they won't be considering shit beyond a room temp IQ they just wanna play their gaymz
Don’t attribute to malice that which can be adequately explained by stupidity.
When it comes to corporations, don't attribute to stupidity that which can be adequately explained by greed. This could easily be avoided by having proper security engineering, but that costs money! They're only about a decade late to the whole post-Snowden "maybe we shouldn't trust unverified code delivered over interceptable cleartext channels" explosion.
This motherboard security stuff should get Linus tech tips level attention and absolutely roast them to the point of a reform
That is a cute quote, but people still need to be held accountable for compromising the ability of millions of devices to update firmware securely. Stupidity or malice, the end result is the same. Having said that, hopefully someone will investigate whether or not there was ill intent.
Any sufficiently advanced malice is indistinguishable from incompetence.
Certificates do not have to expire. This is all firmware handling 101, you put a public key in the software update function, and the updater checks any alleged update against that key, no dates involved.
Actually, the OpenBSD people came up with "signify" which handles this more elegantly.
FTP is still advertised for download of this OS, but any tampering or otherwise corrupted files will not pass a signature test when signify is invoked.
The keys are rotated for every release, the next expected key is always included in the current OpenBSD release.
This system would be safe to fetch sensitive content over cleartext http.
EDIT: Here is a paper on signify:
https://www.openbsd.org/papers/bsdcan-signify.html
FTP is still advertised for download of this OS, but any tampering or otherwise corrupted files will not pass a signature test when signify is invoked.
The keys are rotated for every release, the next expected key is always included in the current OpenBSD release.
This system would be safe to fetch sensitive content over cleartext http.
EDIT: Here is a paper on signify:
https://www.openbsd.org/papers/bsdcan-signify.html
Debian does that since forever. Release file also contains
Of course, you still have to get current time somehow but I guess once RTC is set the device can assume the changes in time won't be huge and just use any kind of https source for that.
Date: Wed, 31 May 2023 14:13:10 UTC
Valid-Until: Wed, 07 Jun 2023 14:13:10 UTC
Of course, you still have to get current time somehow but I guess once RTC is set the device can assume the changes in time won't be huge and just use any kind of https source for that.
Neat, but only really relevant for rolling updates. This feature is a one-shot installer.
Right. But if you’re trying to establish an HTTPS connection to some server then that server’s cert is signed by some trusted root and THAT cert expires.
Which is why it might be more future proof to embed your own non expiring cert and use an out-of-band signature verification for firmware rather than relying on being able to establish an HTTPS connection forever.
Which is why it might be more future proof to embed your own non expiring cert and use an out-of-band signature verification for firmware rather than relying on being able to establish an HTTPS connection forever.
At that point just use http + sigs.
If you have working signature infrastructure you don't need encryption. There is some danger, attacker can see what you are getting, but that's far lower than "the update broke"
If you have working signature infrastructure you don't need encryption. There is some danger, attacker can see what you are getting, but that's far lower than "the update broke"
Yes, that is what you should do. The problem is that they don't do that.
No harm in also running HTTPS on top of that as you can renew the TLS certificate without issue.
No harm in also running HTTPS on top of that as you can renew the TLS certificate without issue.
[deleted]
Doesn’t it do that with the firmware itself, i.e. verify that the firmware was signed by the manufacturer before updating?
So the HTTP request leaks information about the update and could be MITM, but the result could at best be an older version? (Which could be a known exploitable one!)
So the HTTP request leaks information about the update and could be MITM, but the result could at best be an older version? (Which could be a known exploitable one!)
If the description is to be believed, then no, they don't do that.
But certificates expire for a reason, don't they? The idea is that with enough time, the key could be cracked.
That isn’t why certs expire. If a hacker could crack the key in some time that is longer than the expiry but short enough to be a threat, they could instead just spend that time cracking the signing key that verifies the cert signature… then, the hacker could generate as many trusted certs as they want for for any domain.
That's exactly why SHA1 was deprecated in TLS certs.
https://security.googleblog.com/2015/12/an-update-on-sha-1-c...
Even OCSP was affected: https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1...
https://security.googleblog.com/2015/12/an-update-on-sha-1-c...
Even OCSP was affected: https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1...
I wasn't trying to say that brute force wasn't a risk, just that it wasn't why certainly expire
Or, the private key could leak.
Or, the cert could have been issued by an authority which issued the cert despite compliance problems.
Web PKI is different than code signing, but if you look at the discussions within the CAB forum, there are very good reasons to limit certificate lifetime.
Or, the cert could have been issued by an authority which issued the cert despite compliance problems.
Web PKI is different than code signing, but if you look at the discussions within the CAB forum, there are very good reasons to limit certificate lifetime.
No.
The reason certificates expire is because historically the quality of the generators was known to be poor. NotAfter ensures that a new certificate is created with a better generator every now and then. Today that is not really a problem.
Public CAs are not very secure as NSA proved and I am not sure why there is no better alternative yet.
Public CAs are not very secure as NSA proved and I am not sure why there is no better alternative yet.
The reason is money. Sweet, delicious money
The more pressing reason they expire for web sites is that site ownership can change and you don't want someone else having an infinite lifetime cert for a domain you just bought.
It's also useful to issue short lived certs and use the expiry date to handle revocation rather than maintaining a CRL.
It's also useful to issue short lived certs and use the expiry date to handle revocation rather than maintaining a CRL.
HTTP, and no check of the executable signature. I'd say the latter is the worse offence, but the two flaws really come together to provide an excellent MitM vector.
Is that part verified? The linked article doesn't say, and the Eclypsium blog post isn't really clear either. What they say is that the motherboard firmware is causing the resulting windows boot process to run code provided by the firmware (which is weird, but not insecure per se), and that this code is delivered over HTTP.
They notably aren't saying that the firmware or loader is doing no validation on the executable. Most likely this has some sort of home grown signature on the blob, because if it didn't they instantly would have cooked up a MitM exploit to demonstrate. The fact that they didn't implies that it doesn't work.
That's not to say this is a good design (it's clearly not) or that it can't be abused in non-malware ways (junkware, etc...). But it does seem like it's being spun as a clear security hole when my guess is that it isn't (it certainly hasn't been shown to be).
They notably aren't saying that the firmware or loader is doing no validation on the executable. Most likely this has some sort of home grown signature on the blob, because if it didn't they instantly would have cooked up a MitM exploit to demonstrate. The fact that they didn't implies that it doesn't work.
That's not to say this is a good design (it's clearly not) or that it can't be abused in non-malware ways (junkware, etc...). But it does seem like it's being spun as a clear security hole when my guess is that it isn't (it certainly hasn't been shown to be).
The Eclypsium blog post does state the following:
"The firmware does not implement any cryptographic digital signature verification or any other validation over the executables."
Unless your Windows was configured to only run signed software or Gigabyte would apply the Mark of the Web to these files (which would make it harder for them to run their own update process), the executable file downloaded and run as a service doesn't seem to get checked.
As far as I can make out from the blog post, a MitM attack during the motherboard update process would allow for the motherboard to be flashed with malicious software which in turn would indeed allow for dropping Windows executables onto the system. Luckily, barely anyone uses the built-in online updater for their motherboards.
The https://software-nas/Swhttp/LiveUpdate4 URL is a pretty potential risk. You don't even need MitM to pretend to be that URL as it's not a FQDN. If there's any kind of HTTPS certificate validation that URL seems pretty useless in general. Maybe it's some kind of internal testing server that made it into production?
"The firmware does not implement any cryptographic digital signature verification or any other validation over the executables."
Unless your Windows was configured to only run signed software or Gigabyte would apply the Mark of the Web to these files (which would make it harder for them to run their own update process), the executable file downloaded and run as a service doesn't seem to get checked.
As far as I can make out from the blog post, a MitM attack during the motherboard update process would allow for the motherboard to be flashed with malicious software which in turn would indeed allow for dropping Windows executables onto the system. Luckily, barely anyone uses the built-in online updater for their motherboards.
The https://software-nas/Swhttp/LiveUpdate4 URL is a pretty potential risk. You don't even need MitM to pretend to be that URL as it's not a FQDN. If there's any kind of HTTPS certificate validation that URL seems pretty useless in general. Maybe it's some kind of internal testing server that made it into production?
>> What they say is that the motherboard firmware is causing the resulting windows boot process to run code provided by the firmware (which is weird, but not insecure per se), and that this code is delivered over HTTP.
No, the firmware copies a program from itself to Windows, that program then downloads and executes another program from the internet, without verifying it correctly.
Article says: "The firmware does not implement any cryptographic digital signature verification or any other validation over the executables." So unless that is downright wrong the MitM path is wide open. There is a signature check built into Windows, but way too much stuff has been signed to make that a meaningful barrier.
No, the firmware copies a program from itself to Windows, that program then downloads and executes another program from the internet, without verifying it correctly.
Article says: "The firmware does not implement any cryptographic digital signature verification or any other validation over the executables." So unless that is downright wrong the MitM path is wide open. There is a signature check built into Windows, but way too much stuff has been signed to make that a meaningful barrier.
...which actually is not a "Firmware backdoor" but the usual "crappy Windows companion app" malware...
In the past, I could just ignore the CD in the motherboard box with all the crapware. In the more recent past, I didn't have a CD drive to even put it into.
Now, that junk is preloaded onto the motherboard? Argh.
At least I can still opt not to install it, but jeez.
Now, that junk is preloaded onto the motherboard? Argh.
At least I can still opt not to install it, but jeez.
Isn't this enabled by default? I just recently set up a new computer with someone and ran into it.
Yes, it is. It also force-installs certain driver packages and will re-install them on every boot no matter how many times you remove them. When I built my newest system I ended up reinstalling Windows 3 times before I figured out I had to disable it to get rid of the horrible audio software that kept getting force installed for my chipset and screwing up my settings.
"Eclypsium says it found Gigabyte’s hidden firmware mechanism while scouring customers’ computers for firmware-based malicious code, an increasingly common tool employed by sophisticated hackers. In 2018, for instance, hackers working on behalf of Russia’s GRU military intelligence agency were discovered silently installing the firmware-based anti-theft software LoJack on victims’ machines as a spying tactic. Chinese state-sponsored hackers were spotted two years later repurposing a firmware-based spyware tool created by the hacker-for-hire firm Hacking Team to target the computers of diplomats and NGO staff in Africa, Asia, and Europe. Eclypsium’s researchers were surprised to see their automated detection scans flag Gigabyte’s updater mechanism for carrying out some of the same shady behavior as those state-sponsored hacking tools—hiding in firmware and silently installing a program that downloads code from the internet."
> The rest of the article is just ranting
I am puzzled by your conclusion.
Edit:
> enable the option in the BIOS to install Gigabyte's software it will end up being installed
Am i blind? Zero snark intended but where in the article is that mentioned?
> The rest of the article is just ranting
I am puzzled by your conclusion.
Edit:
> enable the option in the BIOS to install Gigabyte's software it will end up being installed
Am i blind? Zero snark intended but where in the article is that mentioned?
Yes, it is ranting. They don't actually present any exploit for it. They are just saying "someone once found a way to exploit the firmware, therefore all firmware is vulnerable!" which is very lousy. There is no hint for example that this can be converted into a "persistent hiding-in firmware" backdoor anymore than any other regular Windows install. The fact that the software is distributed via WPBT is almost orthogonal to the vulnerability itself.
> What they actually found is that Gigabyte's motherboard software auto-updates over HTTP, which makes it vulnerable to a MitM.
So the next question probably should be, are we sure there is no other signing mechanism at play here? If the blob downloaded needs to pass some sort of signature verification to be loaded, the use/lack of HTTPs wouldn't be a big factor in the security model.
So the next question probably should be, are we sure there is no other signing mechanism at play here? If the blob downloaded needs to pass some sort of signature verification to be loaded, the use/lack of HTTPs wouldn't be a big factor in the security model.
[deleted]
As far as I understand, this only affects Windows installations. The update process is executed from Windows and not from motherboard's code itself. The motherboard's code only installs a Windows executable on your hard drive.
I don't see what would stop it from downloading and running an update that would work with Linux, it's that Gigabyte has little financial incentive to create a Linux updater. A malicious actor may, though probably doesn't given Gigabyte's target market.
WPBT is explicitly not supported by Linux kernel. On windows side it is handled by (I may be mistaken, haven't verified that) `wpbbin.exe` binary.
https://docs.kernel.org/arm64/acpi_object_usage.html says:
> Microsoft only table, will not be supported.
(I know, it's for arm64, but there seems to be no other docs)
But, you can use your Linux kernel to see what's inside your motherboard. Check /sys/firmware/acpi/tables/WPBT, if you have one.
source: https://michlstechblog.info/blog/windows-identify-a-wpbt-bin...
https://docs.kernel.org/arm64/acpi_object_usage.html says:
> Microsoft only table, will not be supported.
(I know, it's for arm64, but there seems to be no other docs)
But, you can use your Linux kernel to see what's inside your motherboard. Check /sys/firmware/acpi/tables/WPBT, if you have one.
source: https://michlstechblog.info/blog/windows-identify-a-wpbt-bin...
Sure, but if it's arbitrarily throwing things into the ESP and having them be run on boot, they presumably could do the same thing with Linux. Maybe secure boot would stop it, otherwise I don't see why it couldn't add another initrd to your boot config.
It isn't touching your disk at all. It's just providing an executable in a specific ACPI table that Windows explicitly supports running code from for the purpose of installing OEM-provided software.
I was wrong on what exactly it was doing, but GRUB seems to have some level of support for doing the same thing. https://www.gnu.org/software/grub/manual/grub/html_node/acpi...
[deleted]
[deleted]
It's been a few years, but didn't Windows include a feature back in the BIOS area to execute stuff from a BIOS area, IIRC to install drivers?
Edit: Found it, it's called WPBT and was a thing at least in 2015 [1], with ASUS using it in 2018 to deploy an upgrade tool [2] and an APT group to deploy a rootkit named as "Lojax" [3].
[1] https://michlstechblog.info/blog/windows-identify-a-wpbt-bin...
[2] https://www.heise.de/hintergrund/Asus-verankert-Update-Tool-...
[3] https://www.heise.de/news/Lojax-Der-Spion-der-aus-dem-BIOS-k...
Edit: Found it, it's called WPBT and was a thing at least in 2015 [1], with ASUS using it in 2018 to deploy an upgrade tool [2] and an APT group to deploy a rootkit named as "Lojax" [3].
[1] https://michlstechblog.info/blog/windows-identify-a-wpbt-bin...
[2] https://www.heise.de/hintergrund/Asus-verankert-Update-Tool-...
[3] https://www.heise.de/news/Lojax-Der-Spion-der-aus-dem-BIOS-k...
In the Windows 9x era, it was common for the BIOS to hotpatch the windows kernel to install various bits of 'security' software.
Even today, I think this is how the Dell Computrace anti-theft mechanism works. If you format the disk and install windows afresh, the computrace agent will install itself on the first bootup and ping the internet to see if the system is marked stolen. If you run Linux on your stolen machine, it works fine.
Obviously there are (stolen) "Linux" machines on ebay which work fine, unless you install windows even once, and then they become computrace locked.
Even today, I think this is how the Dell Computrace anti-theft mechanism works. If you format the disk and install windows afresh, the computrace agent will install itself on the first bootup and ping the internet to see if the system is marked stolen. If you run Linux on your stolen machine, it works fine.
Obviously there are (stolen) "Linux" machines on ebay which work fine, unless you install windows even once, and then they become computrace locked.
Yeah, both for drivers and for anti-theft tools like Intel's.
From the blog post referenced [0]:
> Eclypsium automated heuristics detected firmware on Gigabyte systems that drops an executable Windows binary that is executed during the Windows startup process.
...Windows startup process allows for executing "dropped binaries"? Would this be via replacing legit startup binary, or another vector?
[0] https://eclypsium.com/blog/supply-chain-risk-from-gigabyte-a...
> Eclypsium automated heuristics detected firmware on Gigabyte systems that drops an executable Windows binary that is executed during the Windows startup process.
...Windows startup process allows for executing "dropped binaries"? Would this be via replacing legit startup binary, or another vector?
[0] https://eclypsium.com/blog/supply-chain-risk-from-gigabyte-a...
It's called WPBT. The answer is yes. This "backdoor" is Windows performing exactly as designed. It's a documented feature.
Even if a vendor doesn't use WPBT because the reputation of WPBT its a bit iffy these days, they'll just create a fake ACPI node that triggers WIndows Update to download a specific driver from the vendor, which is basically the same thing.
MSI uses this second option for the almost identically named option in the BIOS, and it will also download as much "potentially unwanted applications" as Gigabyte's (was that the Windows Defender euphemism for vendor malware again?) .
Like Gigabyte, it's an option which is disabled by default, but tends to "get enabled" a lot. They don't really have to sneak it in -- even power users enable it since they see the motherboard crapware as a benefit (e.g. temperature sensing, color LED strips and related crap)
Even if a vendor doesn't use WPBT because the reputation of WPBT its a bit iffy these days, they'll just create a fake ACPI node that triggers WIndows Update to download a specific driver from the vendor, which is basically the same thing.
MSI uses this second option for the almost identically named option in the BIOS, and it will also download as much "potentially unwanted applications" as Gigabyte's (was that the Windows Defender euphemism for vendor malware again?) .
Like Gigabyte, it's an option which is disabled by default, but tends to "get enabled" a lot. They don't really have to sneak it in -- even power users enable it since they see the motherboard crapware as a benefit (e.g. temperature sensing, color LED strips and related crap)
I've noticed that simply plugging a Logitech USB dongle into a Windows machine with no other interaction is enough to trigger it to download and install Logitech's crapware.
This is so aggravating! Especially on my locked down corporate laptop. Logitech startup process was able to install itself without my approval, but requires admin privileges to uninstall. So, now it’s just there, forever. Hardware industry has an impeccable security record, so I’m sure it is fine.
Yes, they would never install for instance a proxy which forwards all traffic to them. cough Lenovo
Sorry for cynism, but in my opinion, the main problem is still, that most people understand allmost nothing about computers, except following procedure x to get it roughly do, what they want. And this is usually problematic enough, so they have 0 bandwith for all the shit that is going on underneath. They cannot understand, what is necessary behavior and what is abusive.
That would be probably our job, to raise awareness. But it's exhausting and the result is bloat, crap and spyware as default.
Understanding users would never consent to this. But the majority simply doesn't and I get pragmatic and find solutions, that work for me. Like WindowsDebloat and Linux.
And avoiding touching normal peoples computers, unless with the permission to clean up a bit before using. Not much else one can do.
That would be probably our job, to raise awareness. But it's exhausting and the result is bloat, crap and spyware as default.
Understanding users would never consent to this. But the majority simply doesn't and I get pragmatic and find solutions, that work for me. Like WindowsDebloat and Linux.
And avoiding touching normal peoples computers, unless with the permission to clean up a bit before using. Not much else one can do.
You have given an approval to do anything with your laptop when you chose to install Windows.
Short regedit hack to disable this "feature":
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer\DisableCoInstallers = 1That's Windows Update, not the Windows API that motherboard manufacturers use to inject themselves into the boot process.
What I'm saying in my post is that this is also exploited by motherboard manufacturers. They just create a fake ACPI device node which tells Windows Update to download the crapware. MSI, for example, does this.
THAT is worse than I knew. Ouch, one really has to think what about what kind of stuff one plugs into even an otherwise rather hardened Windows installation.
> This "backdoor" is Windows performing exactly as designed. It's a documented feature.
You say "documented feature", I say "attractive nuisance".
Although firmware always can tamper with the operating system, it's not a good idea. By formalizing a way to do it, thus making it much easier and more reliable, Microsoft encourages motherboard vendors to do it... which is (1) pretty much guaranteed to lead to them at least sometimes doing things like injecting security holes, and (2) pretty much guaranteed to cause problems that even experienced sysadmins have trouble debugging when it goes wrong in whatever way.
It also further entrenches Windows, of course...
You say "documented feature", I say "attractive nuisance".
Although firmware always can tamper with the operating system, it's not a good idea. By formalizing a way to do it, thus making it much easier and more reliable, Microsoft encourages motherboard vendors to do it... which is (1) pretty much guaranteed to lead to them at least sometimes doing things like injecting security holes, and (2) pretty much guaranteed to cause problems that even experienced sysadmins have trouble debugging when it goes wrong in whatever way.
It also further entrenches Windows, of course...
To be frank, MSI's "crap" provides battery life optimized charging, while Windows doesn't (and probably can't).
Oh I don't disagree that it is useful. E.g., If you bought blikenlights, I'm sure you'd like to see them working. But it doesn't excuse the fact that most motherboard software is crap.
Don't get me wrong, it doesn't apply only to MSI. HP's update software ("Support Assistant") for example is spyware by any definition.
Don't get me wrong, it doesn't apply only to MSI. HP's update software ("Support Assistant") for example is spyware by any definition.
How does WPBT interact with SecureBoot? Given it's an official Windows feature, I guess it passes through with no warnings?
Secure boot doesn't apply to apps and that's what this is.
nm, didn't read far enough:
> During the Driver Execution Environment (DXE) phase of the UEFI firmware boot process, the “WpbtDxe.efi” firmware module uses the above GUID to load the embedded Windows executable file into memory...
> During the Driver Execution Environment (DXE) phase of the UEFI firmware boot process, the “WpbtDxe.efi” firmware module uses the above GUID to load the embedded Windows executable file into memory...
Consumer board updating processes are so sketchy anyway I'm not sure it matters.
Like here is a mystery zip file with a binary blob and no patch notes off some ftp server in asia. Frequently with a different binary for mainland china for unspecified reasons.
Like here is a mystery zip file with a binary blob and no patch notes off some ftp server in asia. Frequently with a different binary for mainland china for unspecified reasons.
I like how you have people waxing poetic about "consumer" equipment while probably having supermicro devices in a rack with a direct line to Beijing.
Also, the mainland binaries are usually the ones with the backdoor.
Also, the mainland binaries are usually the ones with the backdoor.
[deleted]
This is just total FUD: https://hackaday.com/2019/05/14/what-happened-with-supermicr...
If you're going to make these claims, back them up.
If you're going to make these claims, back them up.
Imagine thinking that actual people are emotionally invested in a brand.
You don't use devices that reputable sources have directly indicated as having backdoors in a secure environment. Period.
You don't use devices that reputable sources have directly indicated as having backdoors in a secure environment. Period.
There are a multitude of ways that the boards they received could have been tampered with or even switched out and replaced with exact replicas without Supermicros knowledge or assistance.
As it says in the audit that Supermicro themselves performed "A representative sample of our motherboards were tested..." which basically means nothing since they didn't examine the boards in question. Lest we forget[0]. I doubt the NSA are the only ones engaging in this type of behaviour.
So as the Bitcoin people like to say "don't trust verify".
[0] - https://www.schneier.com/blog/archives/2015/03/cisco_shippin...
As it says in the audit that Supermicro themselves performed "A representative sample of our motherboards were tested..." which basically means nothing since they didn't examine the boards in question. Lest we forget[0]. I doubt the NSA are the only ones engaging in this type of behaviour.
So as the Bitcoin people like to say "don't trust verify".
[0] - https://www.schneier.com/blog/archives/2015/03/cisco_shippin...
I'd like to see the reputable source. It surely can't be Bloomberg, which has provided no evidence.
I was just about to post links. I'm not sure why Wired couldn't be bothered to actually link to the report in question. They're certainly happy to link to their own content. I guess it's another example of the "can't let anyone leave our silo" mentality.
List of affected models:
https://eclypsium.com/wp-content/uploads/Gigabyte-Affected-M...
https://eclypsium.com/wp-content/uploads/Gigabyte-Affected-M...
Ah, the joys of using obsolete hardware, looks like I missed the issue by one hardware generation.
Yeah, I was freaking. Good ol' Z390, too old to be worth hacking.
cries in Z170
I think that these update systems aren't intentional backdoors but rather the product of a software team that was put under the gun so to speak. Many products nowadays just leak consumer data (like Toyota's teletronics for their cars) because PMs just demand more and more connected features.
Still grossly irresponsible on Gigabyte's part...
Still grossly irresponsible on Gigabyte's part...
Why don't _all_ models of Gigabyte motherboard have firmware upgradable with a simple 'fwupdmgr update'?
https://fwupd.org/
Let the people who actaully know how to implement secure software repositories and tools for fetching content from them do their jobs. Motherboard manufacturers should stick to what _they're_ good at and just produce timely firmware updates throughout the life of the product.
https://fwupd.org/
Let the people who actaully know how to implement secure software repositories and tools for fetching content from them do their jobs. Motherboard manufacturers should stick to what _they're_ good at and just produce timely firmware updates throughout the life of the product.
[deleted]
For many pieces of software you NEED Windows to run the firmware upgrade application. Example the WD SN 850x.
Yes and it's DISGUSTING
This wouldn't help 99% of Gigabyte customers.
While fwupd does have a windows client, the obvious mechanism to use would be windows update, but anything is better than custom software for each vendor.
fwupd and Windows Update both use the same underlying packaging mechanism for shipping firmware updates. All my comments apply equally to https://learn.microsoft.com/en-us/windows-hardware/drivers/b... :)
Related question: do they still sell motherboards with master admin passwords like they did in the 90s? I remember finding a list of them someplace online then trying one on my friend's Award BIOS and being astounded that it worked. Seems unthinkable in this day and age but it was definitely a thing.
Nowadays they make them dependant on the serial number of the device, the idea being if you get locked out of your own device you can contact the manufacturer with the serial number and recieve the override code.
Quite predictably however, some motivated individuals have reverse-engineered how these codes are generated and made online tools that can generate them as well(1).
[1] https://bios-pw.org/
Quite predictably however, some motivated individuals have reverse-engineered how these codes are generated and made online tools that can generate them as well(1).
[1] https://bios-pw.org/
I used this to make a Dell laptop sold without password usable again.
There was a setting to disable the override password, but that was left disabled. I do wonder what the point of this secure password is if you leave a backdoor password enabled anyway.
There was a setting to disable the override password, but that was left disabled. I do wonder what the point of this secure password is if you leave a backdoor password enabled anyway.
The Huawei modem my ISP uses has a hardcoded admin password that can't be changed. It's actually higher privileges than the login you're supposed to use.
So I ended up building a separate firewall to isolate myself from that thing.
So I ended up building a separate firewall to isolate myself from that thing.
The router from my ISP lives, with his own firewall, seperated by another, purely WiFi router with his own firewall from the home LAN. I guess he lives a happy life there. His separate WiFi comes in handy so sometimes.
You are possibly the kind of wifi channel hogging neighbor I just love, with your unnecessary extra wifi radiation.
We have almost a dozen WiFis in our living room, two of which are ours. The blessing of living in a city between two reasonably large apartment buildings and two other houses.
I live at a reasonably busy intersection but in a residential neighborhood in Durham NC. My unifi controller software has recorded 620 APs in the last 12 days.
It's quite remarkable really.
It's quite remarkable really.
With dual band routers being the norm, theres every chance you are really running 3 or 4.
Three, with one being, for all practical purposes, being contained by walls and reinforced concrete ceilings to the room the router is sitting in. 9 out 10 times you don't even see it in the next room.
Last time I checked my APs have recorded more than 200 wifi networks, in a complex of couple condo towers. But I still get great performance, haven't even needed to upgrade to Wifi 6.
In the past OEMs would put passwords on motherboard BIOS, they were usually default codes but kept customers people from pushing F1 on boot and getting in to do bad things easily.
'lkwpeter' was a popular one I still remember. Also this is still a thing. For Dell you can generate a BIOS password from the serial and this even allows you to circumvent hardware based SSD encryption.
The Windows documentation is actually hard to find. I can only find it through a search engine:
https://download.microsoft.com/download/8/A/2/8A2FB72D-9B96-...
But what is happening here is that Gigabyte actually downloads an application at startup and places _THAT_ one into the WPBT to be executed.
Are they signed?
Does Windows allow the execution of an exe from WPBT that is not signed, or self-signed?
In my opinion Microsoft should release a patch that blocks WPBT execution on Gigabyte until they've proven that they're secure. That is what I expect from the OS.
https://download.microsoft.com/download/8/A/2/8A2FB72D-9B96-...
But what is happening here is that Gigabyte actually downloads an application at startup and places _THAT_ one into the WPBT to be executed.
Are they signed?
Does Windows allow the execution of an exe from WPBT that is not signed, or self-signed?
In my opinion Microsoft should release a patch that blocks WPBT execution on Gigabyte until they've proven that they're secure. That is what I expect from the OS.
I have a Gigabyte B550 board, my particular board isn't listed but I know many of the boards on there share nearly identical components as well as the updater software. Probably safe to assume it's affected too?
Take a Linux device with 2 network ports.
Bridge the network ports.
Install WireShark.
Port 1 to router, port 2 to motherboard.
Boot computer and see what goes over the bridge?
Bridge the network ports.
Install WireShark.
Port 1 to router, port 2 to motherboard.
Boot computer and see what goes over the bridge?
Is there any way to protect yourself from this type of attack?
There's a literal option in the BIOS setup to disable it. You then uninstall/disable the Gigabyte auto-updater and that's it.
By not using Windows or somehow instructing your Windows not to run this file at startup.
> By not using Windows
I'm not sure that is a real solution. The motherboard manufacturer could target other OSes as well, so unless you use a Mac where the hardware is fully controlled by Apple, you'll end up at risk.
In any OS, you'd proba ly have to maintain an explicit "allow list" for any executables that you are OK running on your machine, and make sure that you don't accept any updates without explicitly checking the source yourself.
I'm not sure that is a real solution. The motherboard manufacturer could target other OSes as well, so unless you use a Mac where the hardware is fully controlled by Apple, you'll end up at risk.
In any OS, you'd proba ly have to maintain an explicit "allow list" for any executables that you are OK running on your machine, and make sure that you don't accept any updates without explicitly checking the source yourself.
This is an intended feature of EFI/Windows, used to implement device drivers and theft protection.
So short of "don't use EFI" or "don't use Windows", there's not much you can do. There shouldn't be an easy way to disable this, as it'll brick devices when it shouldn't (missing drivers), or doesn't brick devices when it should (bypassing theft protection).
So short of "don't use EFI" or "don't use Windows", there's not much you can do. There shouldn't be an easy way to disable this, as it'll brick devices when it shouldn't (missing drivers), or doesn't brick devices when it should (bypassing theft protection).
Not using the built-in networking hardware would probably help.
I add an Intel ethernet card to systems that I build as they will offload more work than the typical Realtek controller on a motherboard.
I add an Intel ethernet card to systems that I build as they will offload more work than the typical Realtek controller on a motherboard.
There should be laws in place prohibiting closed source code from being distributed with silicon.
inb4 intellectual property, UEFI software aren't special, they are trash
inb4 intellectual property, UEFI software aren't special, they are trash
Lovely how the article from Wired never mentions how the bios option to disable this is called. At least they linked the original article, but even that only mentions its name way down below near the end of the article, after telling you in 15 ways how the sky is falling.
That was the subject of a 1993 comic book: The Hacker Files #5 (published by DC Comics)
https://www.comics.org/issue/216963/
This is not quite as bad as Lenovo Superfish, but maybe Microsoft should have learned a lesson from that and locked down WPBT. Maybe WHQL should extend beyond drivers to other pre-installed crapware.
motherboards sold by the Taiwanese manufacturer Gigabyte, whose components are commonly used in gaming PCs and other high-performance computers.
I'm curious whether this is the same thing as the Gigabit Utilities Downloader enable/disable option i see in bios
Disabling that option makes the `%SystemRoot%\system32\GigabyteUpdateService.exe` binary mentioned by the original article stop appearing, so it seems so.
Thank you for letting me know!
I wonder if printers do the same thing, since they all automatically update now to stop people from using generic toner.
How is this done with an encrypted drive?
via WPBT/DXE
Thanks
(Medium I know) https://grzegorztworek.medium.com/using-uefi-to-inject-execu...
(Medium I know) https://grzegorztworek.medium.com/using-uefi-to-inject-execu...
It's the other way around: Which computer has no backdoors or "convenient bugs"?
Andy Greenberg is a great journalist! Read him, read everything he does.
Not even a *competent* junior developer would make this mistake.
Does this happen for data center motherboards, too?
https://archive.is/ybixP non-paywall link
The rest of the article is just ranting that if you enable the option in the BIOS to install Gigabyte's software it will end up being installed.