[jaclaz]

>If you accept that running random binaries is a security risk, than running counterfeit hardware that runs arbitrary software is a greater risk!

Undoubtedly, what is IMHO missing is any proof that the counterfeit hardware (besides being likely of inferior quality) is actually running arbitrary software.

[kube-system]

A good risk assessment starts by evaluating possible attack vectors before they’re exploited. If you wait until they’re actively exploited, you might find yourself dealing with an incident response instead.

Another big component of risk is trustworthiness. You might evaluate a vendor’s reputation, test/qa processes, support channels, and the legal environment they operate in. If you don’t even know who the vendor is, that’s a big barrier to establishing much trust.

[jaclaz]

In other words, don't buy on Amazon, particularly by third-party marketplace.

[kube-system]

Not necessarily. Validating the authentication labels on a device might give someone enough confidence they can trust it for their particular threat model. While resellers add a definite uncertainty to the security of the supply chain, I think most people would find them to be more trustworthy than a counterfeiting manufacturer.

[w3rhn2j34oh5o]

And thats the challenge, you can't ever really know that the firmware, or even the logic implemented in silicon is identical. You don't need evidence that it is different, it is impossible to know, one must assume it could be, thus a security risk.

[blackflame7000]

Yes, you can, that's what driver signing is for on the OS side. An authentic driver can then tell if it's talking to a counterfeit firmware. In the early days of the Xbox 360, the first hack was to modify the DVD drive firmware so that it would disable the security check that validates authentic Xbox discs and you could play burned games. After a while, Microsoft figured this out and started banning consoles. How did they do this? They simply compared the firmware images and detected a different checksum. There's no real good way to hide this because different code produces different binaries which is what firmware is. If you can flash the drive then you can read its memory and see it's not original.

To give an analogy, if we are both running a calculator app that should be identical, but your call stack looks vastly different after we do identical operations, something is fishy.

[kube-system]

I doubt intel is doing that in this case, as we’re talking about a NIC and not a DRM enforcement mechanism.

...but even if they are, checking a firmware checksum only mitigates risk if you otherwise trust the hardware.

Counterfeit silicon could report back whatever your driver wants to hear. And even the presence of a a genuine intel chipset with genuine firmware doesn’t mean there isn’t a malicious component elsewhere on the board.

There’s tons of counterfeit silicon out there.

Most of them are just cheap approximations or copies of premium components with the motive to make a profit on their sale, but there’s not much preventing any of them from intentionally or unintentionally compromising their hardware.

The popularity of programmable silicon and the standardization of silicon package sizes make this super cheap and easy to do as well.