Severe Firmware Vulnerabilities Found In Popular Supermicro Server Products (bleepingcomputer.com)
An anonymous reader quotes a report from Bleeping Computer: Security researchers have uncovered vulnerabilities affecting the firmware of the very popular Supermicro enterprise-line server products. These vulnerabilities affect both older and newer models of Supermicro products, but the vendor is working on addressing the issues. These vulnerabilities do not put the safety of Supermicro products at direct risk, as they can only be exploited via malicious software/code (aka malware) already running on a system. Nevertheless, exploiting these vulnerabilities allows the malware to obtain an almost permanent foothold on infected systems by gaining the ability to survive server OS reinstalls by hiding in the hardware's firmware. Technical details are available in an Eclypsium blog post, while a list of affected servers is available here.
To summarize the article, in some instances the administrator can update firmware. The hardware doesn't require that the firmware be signed, so you can use your own firmware. That means if a bad guy has full control of your system, he could install malicious firmware.
Action to take:
If a system gets rooted, consider updating firmware for disk controllers and such before you re-install the OS.
By the way, quite separate from this story, you DO need to re-install the OS if you get a root kit. It's impossible to reliably "clean up" a rooted system without reinstalling, and that has always been true. This story reminds us to do the firmware as well if you get rooted.
Why is the solution to everything these days to incorporate firmware signing when a simple write jumper on a PCB would protect the system far better than any sort of encryption ever could?
You can't write to a chip if that functionality is electrically disabled. This should be fucking standard on server hardware. Make the write enable a physical switch on the back of the machine. In order to flash system, you have to turn it off, press that button, and turn it on again. Once the system is rebooted, the write enable unlatches and returns to a protected state.
Instead, everyone is freaking out about firmware signing this, firmware signing that. What if I want to install my own custom firmware? It's not totally inconceivable that someone might want to do that. I remember flashing a custom BIOS to a 586 system once to unlock support for the AMD K6-2 CPUs. More recently I had to splice in some updated firmware for an Intel CPU onto a board that was no longer receiving updates. It's impossible to do this if the firmware is signed, which, again, there is no real reason for because the write pins for the chip holding your firmware should be protected by some sort of physical setup.
Unfortunately, expect this to be more normal. If there's any whiff of a security issue with an older firmware, companies are afraid of being downright liable for problems with users voluntarily running older firmware.
The security issue can be absolutely zero risk (either unused path, implausible attack vector in the context, or even not having the code at all but updating because people assume it would), but it's just too scary to take a chance.
XML is like violence. If it doesn't solve the problem, use more.
My afflicted X9SAE under FreeBSD routinely had uptimes over a year. Until we moved.
Now we reside in a charming garden community, almost exactly between the sea and a middling—but very busy—all-purpose international airport (flight school, helicopter base, many small planes, in addition to all the commercial jets and turboprops). This whole show is close enough to the sea that there's actually a gate in the security fence at the far end of the long runway (and a brightly painted tow path over a semi-major local artery) for schizophrenic seaplanes to toggle between wet feathers and dry feathers (though I've never seen it used; plus it routes around customs, so the paperwork and oversight would be decidedly non-trivial).
Here the Hydro powers-that-be, a few years back, replaced all the old wooden power poles with new concrete poles, only to later discover that the concrete poles were defectively engineered, so they would come out every three to six months to replace another one (cue a youthful, as-yet-unknown Weird Al bleating out "another day off the grid").
All the swanky new new poles are wood again.
Setting aside the Homer Simpson Hydro problem (doh!), I basically haven't experienced a single outage or fault on this build, either due to hardware or software, since I removed a bad 4-port network card in the fall of 2012, in its first month of life.
So I guess this is definitely a case of "deserve what you get" half full, because this particular board is the most rock-solid board I've ever deployed ("full" disclosure: sample size N=1).
This modulo a power company that can't successfully deploy concrete poles that don't randomly snap in half (I presume this is the terrifying failure mode that necessitates full road-closure, tandem cherry picker and flatbed crane, crewed by a reflective-vest six-pack of union labour, to show up and perform a six–eight hour field replacement); this additionally modulo a hardware company with none of the same hardware quality problems as my local Hydro company, but with shit for BIOS.
Between Intel and Supermicro, I must confess this whole thing is indeed a bit of a bummer.
Intel's face palm—Spectre—makes my isolation jails worthless. Supermicro's face palm turns any jail escape into a secret-volcanic-island undersea laser lair, there to reside until hell freezes over, which might very well arrive before my next core dump, on this amazing piece of kit—at least as viewed by the brilliantly marshalled electrons (if they can manage to get here, in the first place, which was Weird Al territory in this garden-by-the-noisy-sea community for a bad stretch, of late).
Welcome to paradise, half full.
Bitter segfault at #JADEDDEADBEEFCAFE
(Some security-addled Supermicro segfaults are worse that others. That particular one would worry me sick.)