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

No what I'm saying is: My security is fine, my hardware provider (IBM for example) has some security issue. So now I can blame (and sue) him for my problems.

This is very bad reasoning, and unfortunately it is typical for IT managers. You are assuming that security is a product. So you buy a security (e.g antivirus software, UTM network appliance, or something), "put" it into your computer or network and you are fine.

That is what "security" companies are telling us. "Just buy our product, and all your problems will be gone".

But security is not a product, it is a process. Which means you need to be proactive. And of course - if your car hase some error and you die in a car accident, you (or your wife) can sue the company. Of course you can. But you are already dead. The same is with your data. Maybe you will get the damages. But your data are already out.

If nothing else this problem will make people realize to trust only the best providers.

That is exactly a problem. Trust.

You trust a company because it is big, it looks legitimate, and it seems they are following some security guidelines. But this is only assumption.

It is true, I haven't read all of it. But from what I can see, you still need all the access a regular virus needs. If my environment is secure for viruses it is also secure from this attack.

The only problem this discussion brings is, do NOT plug untrusted device in you environment and your equipment must be physically secure. Nothing new to a good IT security.

Still, the cable UDP packet hack is a neat one.

No, you haven't understood anything. Sorry.

A UDP packet can be sent to you from the other side of the planet, it can be generated by userland tools within your network, it can be fired off and forgotten about because UDP is stateless and with that packet I can remotely take over your NIC.

I have no need to plug anything untrusted into your network (I assume that you blindly trust every NIC that you have already plugged into your network, including every switch and router port (those are NICs too) and nothing which you do currently to protect yourself from viruses is going to help nor is physical security.

Pyr0Beast:

.. there are always free ports on the router/switch :)

And you forget that those routers and switches run the same NIC chipsets which are found in other systems and nobody ever said that the attack only works against a PC... this is an attack against a NIC

Let us just mention in passing that at least one router manufacturer uses a vulnerable NIC in one of its product lines and if I had not signed an NDA I'd give you the name here and now.

The Jedi Packet Trick is far more amusing if played against a branded IPS

ABX:

So what am I supposed to do, every time I buy something from IBM I should send it to a special forensic team to test it?

Of course I trust certain companies, and I will do it until proven otherwise. This is why I never, ever put a Sony software in my PC. :)

No, you are supposed to understand what your attack cross-section is and not assume that Sony is bad because they stuck a rootkit in their CD (speaking of which your brilliant anti-virus software and your secure network detected it?).

You are simply limiting your thinking to what is an immediate current threat to your network and are obviously uninterested in seeing what will be a threat in a few years time.

It's all about trust... but deeper you dig the more complicated it gets. And it's a well known fact: CLICK

So what am I supposed to do, every time I buy something from IBM I should send it to a special forensic team to test it?

Of course I trust certain companies, and I will do it until proven otherwise. This is why I never, ever put a Sony software in my PC. :)

Well, you are doing it wrong. You say you trust someone, until it is proven wrong. But that means that you will step on a mine someday - because you will be first with negative experience.

But trust is something as respect - you have to gain it.

How is you magic UDP packet going to work over the Internet? It will just a router and nothing will happen.

I'm sorry, you didn't really ask how a UDP packet reaches your systems, yes?

The very fact that I try to understand this possible threat is a proof that I keep myself informed about potential risk.

No, you are not trying to understand. Every one of your posts has been trying to denigrate the topic, minimise its impact and describing it in terms which show that you have not understood the problem.

This is probably far more worrying than the arrogance with which you describe your security posture.

Security professionals never brag that their security is perfect or near-perfect because they can list at least ten ways to get in off the top of their heads.

You might also want to consider repeating the L0pht mantra a few times a day: "Making the theoretical practical since 1986" (updated to 1992 since their foray into @stake and Symantec but it used to be 1986 for those who knew them back then).

Not how it reaches, but what harm it can do when there is a router on the other side.

Goodness me, you really don't read a single post which isn't in reply to yours do you? Just a few posts above I replied to Pyr0Beast describing how NIC chips are also used in routers.

Not only, why can't a UDP packet traverse your routers? Do you magically detect that my UDP is bad? You have an IPS/IDS which is capable of detecting something which has never left my (admittedly large) test network infrastructure?

That's life, it's not like Columbus knew where he was going. :)

Columbus didn't pretend he ran a secure production network, he always said he was an explorer so he was pretty much entitled to look for A and find B (where in this case A is Catai and B is America).

You can revise your statements if you desire and become an explorer, then everything you say can be re-examined under this new light.

Otherwise my most sincere wishes of best of luck to your users/clients.

Even phone racks can be and are r00ted. And companies don't know that simply because this equipment does not display any non-ordinary behavior.

ABX:

Why you have to take everything as a personal attack?

What? You hijack an interesting conversation without reading previous posts, you don't understand the subject at all, you continue talking rubbish and we take it as a personal attack? If anything we are taking you as a nuisance and/or troll...

I am truly interested to understand how this exploit work, but apart from a "magical" UDP packet who is able to somehow hack machines behind the router there is nothing special about it. It still needs the same privileges a common virus needs in order to do some harm.

"somehow"? "magical"? Don't you use DNS? How do your DNS requests travel? By sending only VC requests using RFC 1149? There is nothing "magical" about the UDP packet, it is a UDP packet that when it is seen by the NIC, and the NIC alone, it is interpreted and acted upon as a firmware flash request. It needs no privileges they do not exist as a concept on a NIC, the operating system is irrelevant this is why, if you read back, we are talking about the TC chip which, in its current incarnation, does not cover peripherals.

P.S: IF you have any more technical data on the UDP packet (port, protocol, .... ) I'll gladly take a look.

Protocol? Pray explain, what is UDP then? The port is irrelevant in this context as it can be changed to suit. How do I know? I wrote the exploit didn't I? And what exactly are you going to look at?

OK, we've fed this troll enough: Denial, Pyr0Beast, Brane2, Matthai can we get back to our regular programming for smart brains? We've got our first victim set out when we want to go commercial with Project Maux in Slovenia...

Pyr0Beast:

Even phone racks can be and are r00ted. And companies don't know that simply because this equipment does not display any non-ordinary behavior.

Did you ever try looking at remote maintenance using a modem of large multi-function systems which offer inbound fax services? There is one which answers with "login: " and runs FreeBSD 4.0, obviously unpatched...

Totally off-topic but worth mentioning in the line of "Cool Sploits R' Us"

Did you ever try looking at remote maintenance using a modem of large multi-function systems which offer inbound fax services? There is one which answers with "login: " and runs FreeBSD 4.0, obviously unpatched...
Sadly never had the opportunity to do so :/
It's literally a sitting duck

ABX isn't a troll, he's just being ... himself :)

Yes, CoreBoot would help with its transparency.

Not sure what to say about money savings. It's highly unlikely and it will 'cost' time to read all that from a simple flash chip. (One at a time)

arrigo:
I wonder if the modification of the RAM in the S3 state can be done by "hit and run" (c) Pyr0Beast, 2009 (wonderful choice of name) on the disk just before the contents are restored. What is in charge of the restoring from disk? Do the operating systems ask ACPI to restore or do they do it themselves? This is an area I know very little about. In which case the "hit and run" has to happen in the time between the NIC waking up, the disks spinning up to speed but before ACPI has a chance to restore or (super nasty) as the restore is taking place... I bet the restore is sequential, if you want to modify a sector which is a Gb or more into the image to be restored you have the time to speak to it.

Now now, don't tempt me
And thank you for your kind words :)

I think it could be done in the mean time between wakeup event and actual wakeup. System does wait for cards-hardware and for applications to halt/resume when entering and when leaving STR. It is a very small opportunity window however. Perhaps, it will wait for 10s before it will hang up due to timeout.
HDD does not need to be active and ready so STR resumes, however sometimes it will wait for it to spin up and then wait even a bit longer for VGA bios to re-POST. If TC isn't active, it is our time then. :)

ACPI does have few simple things to do on STR, however, on hibernate, it isn't involved I think and it goes just for simple store-restore memory with a bit different boot loader that reads everything from a hdd file. So computer is shutdown and powered on as usual.

It is interesting however, that nearly every board has a simple watch-dog on it, with which you can specify, how long the computer will stay in S3 mode. Say for 60 seconds, hour or two, whatever you want. And after that time it will trigger a power-on event. I'm not sure if that could be exploitable and if it will be open for communication from the NIC. It does however, remain active in (nearly) all modes.

When restore is taking place and we somehow figured out to trick TC into not detecting our FW, you are basically free to do whatever you want. Restore speed is limited merely by disk speed so you have plenty of cpu and memory cycles to your disposal. You could simply trick the system not to delete hibernate file after system was restored and then read out/write everything you were interested in and when you are finished, reset the hibernate flag so system will go into restore mode again.

Not only, how is the TC going to verify the integrity of the RAM being restored if it has to calculate a checksum over the whole image? It has to read it all before it can calculate it - we can calculate it on the fly too and then write a "correct" checksum at the end of the image? My guess is that a checksum, if taken, is going to be a separate read from disk so if we are faster than the TC chip, perhaps leveraging the GPU to do the crc32/md5/sha1/whatever, we might have a winner.
I doubt it would do that before making itself a serious resource hog :)
Preferably it will store it's checksum in it's own memory. By which time you could just wait for it to do a complete and successful checksum, perhaps copy what interests you onto graphic card's memory and then do whatever you must or want. I'm wondering how will they implement when graphic card 'borrows' its memory from main system memory. That contents certainly are non static.

Yes, except that I suspect that most proper TC implementations are "enable only". I don't know if they go as far as blowing a suitable diode somewhere but I would guess that it would be rather stupid to be able to disable a production-quality TC.
If that would be true, for blowing the write/read fuse, you'd have a completely dead system if you had something faulty to replace. Perhaps even upgrade CPU, at which point you can be _certain_ people won't do that. A jumper would be a better option, however that costs money and then you have complaining customers saying TC isn't working properly etc., which isn't long before you have an option in the bios to put the 'watch-dog' to sleep :)
.. at which point you disassemble bios to check where does it write that setting and implement that into your firmware.

I need to investigate that more - I've never really looked into waking up from S3 with or without WoL and it is a fascinating avenue of research. Thank you ever so much for bringing it up!
Please do that and inform us if you find something interesting :)

My guess is that the TC would indeed wake up but the RSET goes to the bus too so does the TC have the power to delay the RSET? I would strongly doubt that as it is deep down in the electronics.
Yes, good point. TC could not scan memory or anything else for that matter, if chipsets weren't active. I'm not sure if it would be implemented via Reset signal, but it seems the simplest way to do so however, with a side-way bus.

OK but can a card be truly dormant? Can it just draw power off the PCI bus and nothing else? Does it not run the risk of finding its memory maps overwritten because it does not announce itself? If I was to extend TC to peripherals I'd make double sure that only the TC can validate memory ranges and once it has done this any request for a memory range by a PCI device has to be denied. This requires cooperation from VT-x/IOMMU but is probably doable.
It can just draw power off the PCI bus, there's no problem in doing that. It could even receive Reset# and Clock# signal without giving the mainboard even a hint of presence.
Overwritten memory maps seem to be a bit of a problem however, not sure how to solve that. Perhaps overwriting actual bios's 'shadow', it's usually at the bottom of memory range, but that's a blind trust.

Right now it is the Wild Wild West so we don't even have to worry about that [:-)]
I completely agree :)
And until things get sorted out properly it will stay this way.

My guess? Disable the card's PCI slot in a future version of TC which actually knows about cards [;-)]
Hmm, yes, you could disable clock signal from the clock-gen. They supported that a long long time ago (power settings, EMI etc.), so no problem with that. Well, cutting the power would be a bit harder to do. However, you could also gain control over SMBus and disable clock signal to TC chip as well :)

But, purely theoretically, what if you 'attack' TC chip ? Will you posses the complete control over the computer ? Perhaps merely cause the loss of TC's protection function ? If it will be done like with PC-freeze upgrade cards which have their own bios, that could be even more dangerous. As with discrete chip it will be harder and probably safer.

Yes, that would work. A bit of a problem would be, where should HW look for their data and how could you support another card without reflashing the main bios ?

Yes, you're right. Once it is done, it works /should work, if nothing is else changed.

why is all this talk necessary? Why not just take over one of the designated computers or NIC devices for testing purposes. Perhaps those who claim to have excellent protection wouldn`t mind being subjected to such an attack. Then we could see whether it really works in practice over the net without physical connection or whatever.

why magic? we have a guy who development a hardware rootkit and the software to go with it, Surely he can then ,as is he claiming, exploit a targeted nic device or the net. or have i been reading them post wrongly?

A UDP packet can be sent to you from the other side of the planet, it can be generated by userland tools within your network, it can be fired off and forgotten about because UDP is stateless and with that packet I can remotely take over your NIC.

I have no need to plug anything untrusted into your network (I assume that you blindly trust every NIC that you have already plugged into your network, including every switch and router port (those are NICs too) and nothing which you do currently to protect yourself from viruses is going to help nor is physical security.

1. On je tam shekal "Broadcomove Communication processorje", ne pa NIC-e. gre za čipe BCM9xxx, ne pa BCM-8xxx, ki so na karticah.
Za to je uporabil SDK, ki je na voljo za DL pri Broadcomu. Za NICe ni videti ničesar ( BCM-8xxx, BCM-81xx itd).

So its not possible to hack a NIC, just certain Broadcom`s.....

I`ll stop arguing, because it is of no use to anyone.