Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking for answer on such question.

Imagine that CPU bugged on the factory simply like Blue Pill, but for the network's interconnections.

How exactly firewall of OS could protect station against Hardware Trojan Horse intercommunication?

E.g. iptables blocks any new incoming packet. iptables -A INPUT -p tcp -m state --state NEW -s -j DROP

Ethernet packet with message A switch CPU into the remote controllable mode. Such way that any next message X with secret prefix would be accepted like a control command on the low level language(Assembler).

Are low level incoming packet goes through the whole of circuit to the CPU for the decision DROP/ACCEPT?

E.g. Internet -> Ethernet(PCI) -> North Bridge(Chip) -> CPU

Will CPU read the whole packet, before mark it as NEW and DROP it?

I mean message A would fill the registers of the CPU and switch it into the malicious mode.

HTH in my scenario injected into the CPU like this one.

Edit. I'm trying to clarify. Is there anything that OS can make with malicious control packet(Ethernet) on Bugged CPU?

share|improve this question

closed as unclear what you're asking by TildalWave, Lucas Kauffman, Adi, Xander, Rory Alsop Oct 23 '13 at 13:26

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

Your question is not very clear.

If you mean that the main CPU includes some backdoor for eavesdropping, then in principle, all bets are lost. No matter what protections the operating system might include, the CPU could simply not execute them (but pretend to). In practice, if such a backdoor was identified, there might be a way to work around it, because the CPU is set in stone and cannot evolve whereas software can be designed with the CPU backdoor in mind.

If you mean that the processor of the Ethernet controller contains a spy, then the spy sees all incoming packets. It's no use dropping the packets in the OS since the Ethernet controller sees the packets before the main CPU — its job is to send them to the main CPU. The spy would not be able to decode encrypted communications since these are decrypted by the CPU.

However, malware in an Ethernet controller could do more interesting things than just listen to network traffic. The Ethernet controller generally has access to internal buses such as PCI which allows it to transfer data to and from memory, so on most architectures it could read the RAM of the computer.

There have been buggy Ethernet controllers in the wild. For example, there have been incorrect implementations of Wake-on-LAN. In this particular instance, a machine was vulnerable only when it was plugged into the network but turned off. An attacker would typically have needed to be on the local network since most firewalls filter these packets.

share|improve this answer

Yes, it most certainly does.

The operating principles of a practical Blue Pill installation would typically assume control of the network interface so packets could be used to provide a back-door and/or phone home. Magic packets can be sent to the back-door with a payload for shell execution. The packets are designed to be seen by a modified debug exception handler whenever a packet is received by the hypervisor.

Because it operates at a very low level in the network stack of the hypervisor, the virtualised OS never sees the back-door.

It would be possible to determine the presence of such a back-door by analysing the timing of receiving network packets, however you would have to check for this with an external 'known-good' system.

This PDF goes into detail about the possible back-doors that might be implemented with a virtualised OS, with the intention of preventing the OS knowing it is being virtualised.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.