When BIOS/UEFI has 2-way Internet communictation, what protection there?

Some new motherboards can directly connect to Internet from the BIOS (or UEFI). This makes flashing the BIOS extremely convenient. But it creates a new security problem. Is there any security software that can monitor and stop BIOS access to the Internet?

 

Conceptually, firmware would have control over the machine before any OS level software runs. After OS level software stops running too, probably. Given the right design, firmware can also operate in parallel with and independently of higher level software. In some contexts that could include interleaving its own communications with that of the OS level components in such a manner that the OS level software wouldn't even known it was going on. I don't think higher level [security] software can be relied upon to protect against lower level firmware/microcode/hardware threats. Unless you have the means to independently verify the later, and relatively few parties do, I think the best you can do is use another dissimilar device to watch over the first one. A simple example being the use of a network router/gateway to detect and block the unwanted traffic that compromised end systems might generate.

Having said that, it might also be worthwhile to [momentarily] approach the subject from a less strict POV. By delving into hardware, BIOS, OS details one might conclude that there are *supposed to be* some protections against some threats in this area. Perhaps someone who has implementation experience in the area of PC hardware, firmware, and OS boot will see this thread and share some info.

 

I think so, too.

"I don't think higher level [security] software can be relied upon to protect against lower level firmware/microcode/hardware threats."

I am afraid so, although I hope some clever design will make that happen one day.

This may become possible only if the LAN circuits are redesigned. Imagine that one chip would act as a gate that allows current to flow just to POWER the LAN port. Another chip would only allow electricity in the form of DATA signals to flow from and to the motherboard itself. This is where the new direct Internet BIOS flashng data would go through. Gate 3 would allow data signals controled by the OS itself.

The OS already can instruct the LAN jack to go to sleep by disabling the LAN from Control Panel (Windows). The OS could similarly instruct the motherboard to turn off gate 2 (stop all motherboard data traffic). Gate 3 would do what the OS has traditionally done: channel upper level data to and from the LAN port. This hard-wired separation of electrical channels would begin to give the OS and security software a good a good grip on this emerging threat by turning off gate 2.

 

During the design review I think some questions would come up...

1. How does anyone know whether the LAN chip does exactly what is promised and contains no flaws or backdoors?
2. How does the LAN chip know that it is being manipulated by OS level software, as opposed to say firmware?
   
3. How does the OS level software know that it is actually manipulating the LAN chip, as opposed to say an abstraction/virtualization layer?

I think you could leverage some of the "Trusted Computing", "Secure Boot", etc techniques to try to address some of the issues. I don't think that would eliminate all instances of "must rely on promises/trust" though, particularly if we're talking about closed source and multiple vendors.

Even if you could eliminate all those issues, there remains the question of what things would be like from the user's POV. Would you want OS vendor X, or antimalware vendor Y, to have the ability to lock you out of using your LAN chip with software provided by other vendors? Would OS vendor X, or antimalware vendor Y, enforce policies that meet your requirements? I'm inclined to think that auto-updating firmware provided by a recognized board manufacturer would be allowed by default. Possibly even allowed period. Yet that would be a security issue that more strict admins would want to eliminate, at least in those cases where the updates are retrieved from manufacturer's servers rather than their own.