Nov članek: "All your firmware are belong to us"

Well, obviously solution demands harware of some quality.

One thing would be to be able to read internal Flash regardless of the FW in the card. Other would be to demand offsite update to be explicitly activated for users that want it.

So ? Then don't use PKI on the card, if you can't get it right. It aleviates many headaches.

Answer seem simple enough - design NIC hardware so that inbuilt core is limited and that for ecample it can't prevent me from reading internal Flash.
Flash programming is simple enough that it can be done either by some simple state-machine or a small piece of code in ROM.

One thing that comes to mind is that packed could be signed and with crypto HW in NIC one could program keys in NIC registers, maybe even my TC. Shouldn't that solve the problem ?

O.K. But all that could be done by CPU at POST, assuming the BIOS is clean ( so it had to probably be checked by TC)

Wouldn't a simple, yet effective intermediate solution be to lock such remote update capability with a jumper, for example ?

But at least on AMD systems you have IOMMU ( and Intel has its own flavour) , so your reach through PCI could be severely limited...

I assume this is sarcastic, yes? PKI is currently the only way NIC manufacturers can guarantee firmware origin and integrity and also offer customisable firmware to their OEMs.

Sure, but that costs money. The driver behind pretty much any manufacturing in PCs is cost-limitation. In a high-end NIC you put PKI, in a low-end NIC you don't even allow the firmware to be modified... So, I guess that for server-class 10GE cards you could consider this.

You still have to seriously analyse the sequence of events from the sending of the WoL packet to the system being completely active. You could sign the WoL packet and indeed there are SSL/TLS implementations of WoL but, once again, think about the cost of having SSL/TLS in your NIC.

O.K. But all that could be done by CPU at POST, assuming the BIOS is clean ( so it had to probably be checked by TC)

You should read the "Intel Secure Computing Initiative" book to see how disgusting the TC-based booting process is, it is basically the perfect example of a kludge in my opinion. At a certain point you have to take a leap of faith and believe that you can trust something in your system .

Wouldn't a simple, yet effective intermediate solution be to lock such remote update capability with a jumper, for example ?

Not in a Dell factory manufacturing thousands of computers every day not to mention the risk of static shock when the guy on the assembly line moves the jumper to update the firmware (anecdote: back in the 1990s DEC used to ship the first DEC Alpha boxes with the firmware update jumper set to "block" but the number of burnt mobos meant that they then started shipping with the firmware update jumper set to enabled). So yes, a possible fix but commercially viable? no.

You need to read up on what exactly IOMMU and Intel VT-x block

firmware rootkit ni toliko nevaren ker zahteva fizični dostop do računalnika, oz do proizvodnje / distribucije.

But if you can't do it within NIC in satisfactory way, wouldn't it be prudent to leave it to the user ?

And BTW I dont see why a little bit of common sense should cost much $$$.

I'm not crypt expert, but I think you don't really need full standard implementation just for simple WoL...
Also, it could be HW settable, so if you don't really need it, you can hard switch it off. Or better yet, hw switch it on if you need it.

BIOS is nowadays in serial Flash, not unlike the ones for FPGA configuration. It has a simple few pins SPI-like interface. It shouldn't be hard to put TC in CPU's path to the BIOS. When PC POSTs, TC scans BIOS and if everything is kosher, CPU gets acess to it...

That's why God invented DIP switch ;o) You could set it to off for and force mere mortals to manually switch it on.

Also, it shouldn't be too hard to implement electronic eqiuvalent if one _really_ can't work with mechanics solution.

I did. IIRC it behaves quite like CPU's MMU, but it doesn't generate exceptions on misses.
With it one could tailor how peripheral sees memory map and put certain regions "off-the-map" for some peripheral...

Common sense is rarely a factor in manufacturing unless it comes with associated cost savings. So even EUR0.50 added to manufacturing makes a difference when the OEM purchasing your solution wants to buy 100,000 of them.

Ah no, you can't have a DIP switch because it means opening the case of the assembled PC... It is all about the $$...

That is true but what programs the IOMMU settings? This is what I meant by reading up on it. You can definitely taylor the memory map of peripherals making it hard (I refuse to say impossible, it is a word which always comes back to bite you) for a NIC to speak to the GPU but someone has to consciously activate IOMMU/VT-x and program it correctly. Even with VT-x or IOMMU when you activate it the NIC can speak to pretty much any other device on the system.

Not quite: at POST there is power and the devices are up waiting to be initialised during the POST procedure. The NIC is fully powered and active, has asserted its presence on the PCI bus, notified the PCI bus controller of its existence and is waiting on the POST to "touch" it so that it can initialise and report its "soft" settings (memory ranges, etc.).

I think that for the benefit of this discussion we should agree that we are not talking about el-cheapo cards which don't even have upgradable firmware... As Matej quoted me earlier we are talking about a sophisticated directed attack, not something about getting a bigger botnet overnight.

I will vote for your initiative if you support my initiative to enforce minimum quality in software products and a ban on "we take no responsibility" on EULAs. If Microsoft wants to sell something then it has to come with a 2 yr warranty and if (when installed as Windows CE in my fridge) causes my house to catch fire because it drives the compressor off-spec then they can be sued for negligence.

They might not be in a physical slot but they are still on the physical bus as a separate chip from the North/Southbridge stuff at least for the high performance cards. I can assure you that modern HP DL3xx systems have a separate Broadcom CPE which controls the NICs and is definitely not integrated in the Intel standard chipset.

Mi znaš kaj več povedat?

Vse kar vidim iz članka je to da je potrebno na novo naložit firmware. Kako bi to naredil remote mi ni jasno.

Can I point you in the direction of comments and links which speak about this:

1. WoL packets,


2. updating flash using software updates,


3. Broadcom's Communications Processor Firmware Update.

Take the last example: you simply run a program as Administrator / root on a system with BCP, not exactly rocket science and most definitely something which does not require physical access.

As far as remote update is concerned then you should read the previous comments regarding how certain manufacturers offer a remote update capability for OEMs who include their products on systems and need to flash them on assembly lines.

Sej ne da ni možno, vendar kakšne so možnosti da ruski hacker z tem načinom pride do NASA-e?

Well - check this out:

1982 -- Soviet gas pipeline. Operatives working for the Central Intelligence Agency allegedly (.pdf) plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program and decided to make it backfire with equipment that would pass Soviet inspection and then fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in the planet's history. (original from Wired)

And as Arrigo said in the interview:

At the moment the return on investment for hardware rootkits do not make them viable so they are simply not going to be used except where they are really needed which, in my opinion, is at the level of serious industrial espionage.

But once it is done, pretty much every customer is scre*ed. Condom non-optional.

OK, given the tone of the debate I should have been more precise: you are of course correct, the PCIe "bus" has a star topology with the PCIe controller in the centre (which may be part of a "Northbridge" but not necessarily so) and indeed it can behave "old style" if configured to do so.

I got your point, but in this case is the manufacturer who has a security issue not the client. My point is still valid, a hacker needs to break a manufacturer security protocol, not the client and not just a PC infection it must enter the assembling line. Of course it's doable, but the amount of work involved is much higher then breaking the client security or at least it should be.

Not quite: a well-placed packet can do your machine at home too, not to mention your DSL router and your printer. Pretty much any security issue with computers is a "manufacturing security protocol" issue because the fact that clicking on an image in Windows would execute malicious code is hardly the owner's fault...

My point is: there is a simpler way to infect home users, that's all, no more no less.

1. You could use firmware attacks against home users without requiring them to click on a link but by doing so remotely - we have discussed how in previous posts,


2. You are not seeing this attack because your anti-virus software would never be able to detect it in any case,


3. You probably should not worry unless you are part of: Government, Secret Service, Utility company (think SCADA), other very paranoid group.

ABX:

My point is: there is a simpler way to infect home users, that's all, no more no less.

I'm sorry but I have to reiterate: we are not talking about home users, we do not wish to convince you that this is the way to hack home users, we are not talking about "easy" or "simple", we are talking about "cool", "far out", "pretty nifty", "way ahead of its time".

All we are trying to do in answering you is set the record straight that, yes, it could affect home users but it is not worth doing because the ROI for the attack is not good enough.

So, to summarise:

1. You could use firmware attacks against home users without requiring them to click on a link but by doing so remotely - we have discussed how in previous posts,


2. You are not seeing this attack because your anti-virus software would never be able to detect it in any case,


3. You probably should not worry unless you are part of: Government, Secret Service, Utility company (think SCADA), other very paranoid group.

Thank you in any case for contributing your point of view.

What you are advocating is "I do not need to worry because my NIC is not vulnerable". You don't know this.

Arrigo

If I download and install a firmware(or any other exe) that hasn't come from a trusted source I should not be in IT.

Or am I missing how the remote exploit works.

ABX: You are.

From what I understand all this requires you to run an exe as an Admin. The remote update comes from a trusted company.

You didn't read any of the comments in the forum then - please read back where we discuss WoL.

WoL, as in Wake on Lan?

Nothing special about it, they can work only inside the LAN. If you have a good virus inside your LAN you are already fucked up.

You really cannot be bothered to read back in the discussions? Try searching for "UDP" and see where you get...