[HN Gopher] Some models of Gigabyte motherboards download firmwa...
___________________________________________________________________
Some models of Gigabyte motherboards download firmware updates
insecurely
Author : mdhb
Score : 205 points
Date : 2023-05-31 13:35 UTC (9 hours ago)
(HTM) web link (www.wired.com)
(TXT) w3m dump (www.wired.com)
| slowhand09 wrote:
| https://archive.is/ybixP non-paywall link
| wmf wrote:
| 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.
| jesprenj wrote:
| 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.
| boomboomsubban wrote:
| 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.
| hiciu wrote:
| 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...
| boomboomsubban wrote:
| 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.
| Nextgrid wrote:
| 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.
| boomboomsubban wrote:
| I was wrong on what exactly it was doing, but GRUB seems
| to have some level of support for doing the same thing. h
| ttps://www.gnu.org/software/grub/manual/grub/html_node/ac
| pi...
| [deleted]
| [deleted]
| fallat wrote:
| Let's just go back to Amigas
| jalk wrote:
| Yes because those disk we copied from friends, never contained
| any viruses...oh wait.
| Animats wrote:
| Does this happen for data center motherboards, too?
| primeradical wrote:
| 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?
| boringuser2 wrote:
| Not even a *competent* junior developer would make this mistake.
| KingOfCoders wrote:
| How is this done with an encrypted drive?
| richij wrote:
| via WPBT/DXE
| KingOfCoders wrote:
| Thanks
|
| (Medium I know) https://grzegorztworek.medium.com/using-uefi-
| to-inject-execu...
| Havoc wrote:
| 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.
| boringuser2 wrote:
| 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.
| [deleted]
| vore wrote:
| 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.
| boringuser2 wrote:
| 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.
| solarkraft wrote:
| I'd like to see the reputable source. It surely can't be
| Bloomberg, which has provided no evidence.
| froglets wrote:
| I wonder if printers do the same thing, since they all
| automatically update now to stop people from using generic toner.
| LegitShady wrote:
| https://eclypsium.com/blog/supply-chain-risk-from-gigabyte-a...
| programmarchy wrote:
| List of affected models:
|
| https://eclypsium.com/wp-content/uploads/Gigabyte-Affected-M...
| creshal wrote:
| Ah, the joys of using obsolete hardware, looks like I missed
| the issue by one hardware generation.
| SketchySeaBeast wrote:
| Yeah, I was freaking. Good ol' Z390, too old to be worth
| hacking.
| pnemonic wrote:
| _cries in Z170_
| flyinghamster wrote:
| 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.
| eb0la wrote:
| That was the subject of a 1993 comic book: The Hacker Files #5
| (published by DC Comics) https://www.comics.org/issue/216963/
| Simulacra wrote:
| _motherboards sold by the Taiwanese manufacturer Gigabyte, whose
| components are commonly used in gaming PCs and other high-
| performance computers._
| taylorbuley wrote:
| Andy Greenberg is a great journalist! Read him, read everything
| he does.
| yrro wrote:
| 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.
| [deleted]
| wmf wrote:
| This wouldn't help 99% of Gigabyte customers.
| wtfishackernews wrote:
| 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.
| mschuster91 wrote:
| 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...
| creshal wrote:
| Yeah, both for drivers and for anti-theft tools like Intel's.
| londons_explore wrote:
| 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.
| AshamedCaptain wrote:
| What they actually found is that Gigabyte's motherboard software
| auto-updates over HTTP, which makes it vulnerable to a MitM.
| [EDIT: since it's not checking for any signature]
|
| 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.
| kevin_nisbet wrote:
| > 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.
| [deleted]
| Arrath wrote:
| 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.
| jameshart wrote:
| 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.
| tinus_hn wrote:
| Don't attribute to malice that which can be adequately
| explained by stupidity.
| Forbo wrote:
| 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.
| ikekkdcjkfke wrote:
| This motherboard security stuff should get Linus tech
| tips level attention and absolutely roast them to the
| point of a reform
| naruhodo wrote:
| Any sufficiently advanced malice is indistinguishable from
| incompetence.
| dustfinger wrote:
| 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.
| NohatCoder wrote:
| 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.
| asveikau wrote:
| But certificates expire for a reason, don't they? The idea
| is that with enough time, the key could be cracked.
| AtNightWeCode wrote:
| No.
| cortesoft wrote:
| 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.
| oasisbob wrote:
| 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...
| cerved wrote:
| The reason is money. Sweet, delicious money
| oasisbob wrote:
| 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.
| allset_ wrote:
| 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.
| chasil wrote:
| 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
| ilyt wrote:
| Debian does that since forever. Release file also
| contains Date: Wed, 31 May 2023
| 14:13:10 UTC Valid-Until: Wed, 07 Jun 2023
| 14:13:10 UTC
|
| which allows spotting any tries of "downgrading"
| repository to previous version with potentially insecure
| packages
|
| 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.
| NohatCoder wrote:
| Neat, but only really relevant for rolling updates. This
| feature is a one-shot installer.
| jameshart wrote:
| 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.
| [deleted]
| ilyt wrote:
| 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"
| NohatCoder wrote:
| 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.
| koolba wrote:
| 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!)
| NohatCoder wrote:
| If the description is to be believed, then no, they don't
| do that.
| NohatCoder wrote:
| 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.
| ajross wrote:
| 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).
| NohatCoder wrote:
| >> 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.
| jeroenhd wrote:
| 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?
| jchw wrote:
| Isn't this enabled by default? I just recently set up a new
| computer with someone and ran into it.
| devmor wrote:
| 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.
| rickdeckard wrote:
| ...which actually is not a "Firmware backdoor" but the usual
| "crappy Windows companion app" malware...
| scns wrote:
| "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?
| AshamedCaptain wrote:
| 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.
| alexjplant wrote:
| 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.
| DaSHacka wrote:
| 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/
| jeroenhd wrote:
| 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.
| kevin_nisbet wrote:
| 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.
| hef19898 wrote:
| 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.
| giobox wrote:
| You are possibly the kind of wifi channel hogging neighbor
| _I just love_ , with your unnecessary extra wifi radiation.
| hef19898 wrote:
| 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.
| giobox wrote:
| With dual band routers being the norm, theres every
| chance you are really running 3 or 4.
| hef19898 wrote:
| 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.
| kevin_nisbet wrote:
| 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.
| natebc wrote:
| 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.
| nekoashide wrote:
| 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.
| weinzierl wrote:
| '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.
| ndneighbor wrote:
| 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...
| miffe wrote:
| https://archive.is/LHMFT
| jonnycomputer wrote:
| I'm curious whether this is the same thing as the Gigabit
| Utilities Downloader enable/disable option i see in bios
| jxi wrote:
| Is there any way to protect yourself from this type of attack?
| jesprenj wrote:
| By not using Windows or somehow instructing your Windows not to
| run this file at startup.
| PretzelPirate wrote:
| > 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.
| creshal wrote:
| 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).
| AshamedCaptain wrote:
| There's a literal option in the BIOS setup to disable it. You
| then uninstall/disable the Gigabyte auto-updater and that's it.
| rjsw wrote:
| 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.
| uticus wrote:
| 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...
| uticus wrote:
| 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...
| AshamedCaptain wrote:
| 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)
| dist-epoch wrote:
| How does WPBT interact with SecureBoot? Given it's an
| official Windows feature, I guess it passes through with no
| warnings?
| wmf wrote:
| Secure boot doesn't apply to apps and that's what this is.
| xmodem wrote:
| 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.
| actionfromafar wrote:
| 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.
| jeroenhd wrote:
| That's Windows Update, not the Windows API that motherboard
| manufacturers use to inject themselves into the boot
| process.
| AshamedCaptain wrote:
| 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.
| quantaunkindly wrote:
| Short regedit hack to disable this "feature":
| HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device
| Installer\DisableCoInstallers = 1
| 0cf8612b2e1e wrote:
| 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.
| actionfromafar wrote:
| Yes, they would never install for instance a proxy which
| forwards all traffic to them. _cough Lenovo_
| hutzlibu wrote:
| 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.
| codedokode wrote:
| You have given an approval to do anything with your
| laptop when you chose to install Windows.
| ComodoHacker wrote:
| To be frank, MSI's "crap" provides battery life optimized
| charging, while Windows doesn't (and probably can't).
| AshamedCaptain wrote:
| 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.
| Hizonner wrote:
| > 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...
| sylware wrote:
| It's the other way around: Which computer has no backdoors or
| "convenient bugs"?
| Double_a_92 wrote:
| Intel Management Engine ?
| agloe_dreams wrote:
| I'm guessing Gigabyte Control Center.
___________________________________________________________________
(page generated 2023-05-31 23:01 UTC)