Software > Firmware
network card to reduce attack surface?
Hasturtium:
--- Quote from: power9mm on August 14, 2022, 05:12:09 pm ---so to clarify, the BMC on the blackbird is isolated and not accessible if one has network access on the other two ethernet ports. correct?
--- End quote ---
By all accounts that’s correct- the official documentation says that much, and it’s repeated on several pages on the official wiki.
AdamJoseph:
--- Quote from: power9mm on August 14, 2022, 05:12:09 pm ---so to clarify, the BMC on the blackbird is isolated and not accessible if one has network access on the other two ethernet ports. correct?
--- End quote ---
I'm not sure about the Blackbird, but please note that this is most definitely not true for Talos2.
The Talos2 BMC is connected directly to the management interface of the two-port ethernet chip, and there is nothing you can do to prevent an attacker with control of the BMC from having total control over both network adapters.
All of my Talos2 machines use separate PCIe cards for networking as a result of this unfortunate situation. Hopefully Arctic Tern will eventually allow me to re-pinstrap the BMC and hold its reset pin in the asserted state so I can go back to using the on-motherboard ethernet ports.
meklort:
The original post is a bit old, but since there now activity, I figured I should add a few clarifications.
--- Quote from: Hasturtium on August 14, 2022, 07:08:43 pm ---
--- Quote from: power9mm on August 14, 2022, 05:12:09 pm ---so to clarify, the BMC on the blackbird is isolated and not accessible if one has network access on the other two ethernet ports. correct?
--- End quote ---
By all accounts that’s correct- the official documentation says that much, and it’s repeated on several pages on the official wiki.
--- End quote ---
To clarify this a bit more, as it's partially correct:
- The proprietary firmware, if you are still on it, technically allows all ports to be used for network traffic on the BMC. The latest BMC firmware is configured to select only the correct port for the Blackbird of Talos II, however in some cases, this could malfunction. It is also relatively easy to reconfigure this one connected to the BMC.
- If you are using the open source firmware, this is configured to only connect to the specified port at build time, as such, the BMC cannot communicate on a separate port mistakenly. There are of course ways for the BMC to turn on the host, and then instruct the POWER9 CPU to flash the NIC firmware, but that's not something that the BMC can do as easily as the option with the proprietary code.
--- Quote from: AdamJoseph on August 16, 2022, 03:57:45 pm ---I'm not sure about the Blackbird, but please note that this is most definitely not true for Talos2.
The Talos2 BMC is connected directly to the management interface of the two-port ethernet chip, and there is nothing you can do to prevent an attacker with control of the BMC from having total control over both network adapters.
All of my Talos2 machines use separate PCIe cards for networking as a result of this unfortunate situation. Hopefully Arctic Tern will eventually allow me to re-pinstrap the BMC and hold its reset pin in the asserted state so I can go back to using the on-motherboard Ethernet ports.
--- End quote ---
Technically speaking, the only way that the BMC can take control of the network controller is by loading a custom host OS image, that then talks to the device. The BMC does not have a way to re-flash the network card firmware directly, nor does it have a way to load new firmware on the device directly. This can only be done from the host, which the BMC does have full control of. Your model of adding a second Ethernet card does make things harder, but the BMC can still take control of this by replacing the host image.
The general threat model for the Talos II and blackbird is that the BMC is in control of the host, and not the other way around, ado so this is how things are designed. The BMC can always compromise the host.
--- Quote from: n2vi on April 13, 2022, 11:43:07 am ---Is there a simpler way to achieve this? Perhaps a BMC configuration trick that disables NC-SI?
--- End quote ---
You can disable network access to the BMC a couple of ways:
- Remove the firmware on the NIC, specifically the APE. This will disable the BMC from being able to access the network (without first re flashing the firmware)
- Build a custom version of the firmware that disables NC-SI. At this point, there's not much benefit of running any firmware, but it's still an option.
- Use the open source firmware and *don't* use port 0 (Talos II), or port 2 (blackbird), as those are the ports configured for NC-SI access to the network.
AdamJoseph:
--- Quote from: Hasturtium on August 14, 2022, 07:08:43 pm ---The general threat model for the Talos II and blackbird is that the BMC is in control of the host, and not the other way around, ado so this is how things are designed. The BMC can always compromise the host.
--- End quote ---
This is a weak threat model that some people choose to adopt for convenience's sake. If this were the most general threat model, the SEEPROM and many other features would be pointless.
--- Quote from: Hasturtium on August 14, 2022, 07:08:43 pm ---the BMC can still take control of this by replacing the host image.
--- End quote ---
In a properly secured system this is at worst a denial-of-service attack. See https://wiki.raptorcs.com/wiki/Secure_Boot_with_your_own_keys
--- Quote from: Hasturtium on August 14, 2022, 07:08:43 pm ---Technically speaking, the only way that the BMC can take control of the network controller is by loading a custom host OS image,
--- End quote ---
Take a look at the Talos2 schematics: T2P9D01, v3.8, page 96. The NCSI management interface for the ethernet chip goes to the BMC. This is essentially the management interface for the tiny switch inside the BCM5719. It can select the filtering criteria (vlan, mac address, etc) for which packets get passed to the BMC. Or it can set no filtering at all in order to let the BMC sniff all traffic.
Think about it: both "tcpdump" and "ip link set dev address $MAC_ADDRESS" work on the BMC. You can sniff traffic and inject packets on either ethernet port from the BMC, without "loading a custom host OS image".
meklort:
--- Quote from: AdamJoseph on August 19, 2022, 03:57:11 am ---Take a look at the Talos2 schematics: T2P9D01, v3.8, page 96. The NCSI management interface for the ethernet chip goes to the BMC. This is essentially the management interface for the tiny switch inside the BCM5719. It can select the filtering criteria (vlan, mac address, etc) for which packets get passed to the BMC. Or it can set no filtering at all in order to let the BMC sniff all traffic.
Think about it: both "tcpdump" and "ip link set dev address $MAC_ADDRESS" work on the BMC. You can sniff traffic and inject packets on either ethernet port from the BMC, without "loading a custom host OS image".
--- End quote ---
Yes, I understand how NC-SI works and how it is used to connect the BMC and the NIC.
That said, there is *no* switch in the NIC, and it doesn't operate the way you discribed. The NC-SI traffic is handheld by firmware and not by hardware.
You are correct that NC-SI allows setting the VLAN, MAC, etc, however this is done by sending a command to the APE on the BCM5719, which then sets the appropriate registers to enable it.
Please se here for how packets from the BMC are handled: https://github.com/meklort/bcm5719-fw/blob/main/ape/main.c#L193
and here for how the NC-SI packets are handled, such as the set MAC command: https://github.com/meklort/bcm5719-fw/blob/main/libs/NCSI/ncsi.c#L530
You may also note that the open source firmware does not support setting a different VLAN as well, butin any case, as the firmware is open source, you can always explicitly lock it down to a specific MAC and VLAN.
In this case, there is no checking that the requested MAC is different from the host MAC, and so I will add that in a future release, as it's a very good point.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version