» »

strani: 1 2 3

Brane2 ::

This EEPROM is peanuts, it's used AFAIK just to hold MAC...
On the journey of life, I chose the psycho path.

arrigo ::

Pyr0Beast, I think I probably phrased the question wrong: of course the TC chip will have some power while the system is on standby ready to be woken up by WoL but my point is that the WoL packet is seen by the NIC and processed by the NIC first. Even though it carries no data it has to be interpreted by the NIC (see WoL on Wikipedia) which means that the firmware must be invoked. So you still have a chicken & egg problem: if I manage to wake up the NIC via a WoL packet and inject new firmware before TC startup and verification I still win. So the question becomes: how does one process a WoL packet securely and still be sure that the hardware has not been modified in any way since the system was put to sleep?

I hope it is clear to everyone by now that NIC verification, amongst others, by a TC is not trivial: when the system is powered up after a WoL packet you need the TC to check the integrity of the various components. Let us consider the NIC: what would this integrity check require? Obviously firmware integrity, chip integrity (self test with on-board test vectors?), DMA and PCI-to-PCI channels set up? The list is long and, at least for firmware integrity, we must have the cooperation of the NIC. This is why I speak of a chicken & egg problem: how do you verify firmware on a NIC without the NIC cooperating (and therefore triggering the firmware)? How do you do it securely (the obvious answer, "make the firmware memory location on the NIC accessible via, say, DMA", does not really cover the "securely" bit...).

arrigo ::

Ah, I forgot to comment about AMT: I am sure that it can be found on cheaper systems now although the "remote management" functionality is very much a requirement in data centre and enterprise-wide PC deployment (hence it is making an appearance in "cheaper" desktops and not just rack-mounted systems).

Still, AMT (like all remote-management systems) is an interesting backdoor, especially if it can be escaped.

An interesting functionality which is available with AMT is "NIC sharing" where AMT access takes place through the same NIC as the operating system (iLO and other remote management systems use a separate NIC for this, I am not sure about IPMI to be honest). This NIC sharing implies complex firmware on the NIC (complex means "big" which means more possible holes) and at the same time it also gives you a fascinating hook.

If you read my presentation on the first part of Project Maux (not publicly available but you can find strong hints to the content of it in my Escaping VMware presentation) you will discover that I hook the checksum hardware acceleration. Now, what if I hook the AMT magic packets? This is stealthier and harder to detect (think about timing issues on the hardware checksum if you need your NIC to verify for nicssh magic packets for each packet)...

Just thinking out loud for the benefit of discussion...

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.


Ha, talk about posting without reading previous posts: yes, this is exactly what the TC would need to be able to verify firmware independently of the NIC.

Regarding the remote update the problem is really very much an OEM one: can they flash and then set the remote update off as part of their remote update?

Zgodovina sprememb…

  • spremenil: arrigo ()

Brane2 ::


1) Firmware checking: it is not as simple as saying "oh look, I have a known-good card, let me compare firmware"...
SNIP...
Consider a card which uses digital signatures: this implies a complete PKI infrastructure and within the card there needs to be a CA certificate to verify the signature. Now consider OEMs: they want to slightly modify the NICs so they need to have either a 2nd-level CA certificate so that they can sign firmware on their own or have a single signing key. What happens if they "lose" this key? Can it be lost? If this were to happen how do you push a CRL into an installed NIC?


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



What about knowing if the firmware is good? It is the firmware itself which has to support loading new firmware: when you get an OK how do you know that it is a real OK and what happened was not simply >/dev/null?


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.


When does the TC chip wake up? Should it always be up? But then the WoL packet needs to be "authorised" somehow (not in the protocol right now) for the NIC to react, and then the NIC has to ask the TC chip to verify the NIC? I don't have an answer for this, I am just trying to show how the story as a whole is complicated.


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 ?


I am also assuming that you are aware that right now TC implementations do no verification whatsoever of PCI devices or indeed of the PCI bridge.


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)


2) remote flashing: it exists on several cards for the convenience of OEMs. Once the card is installed flashing requires booting into an operating system which is "expensive", far more than instructing someone on the assembly line to plug a UTP cable in and press a key on a machine.

...SNIP...

Big deal? Yes because users notice but what about a firewall? Also, for how long is the NIC offline? answer: under a minute. How do you detect it? You don't unless you have a way to extract the firmware without asking the NIC otherwise I can serve you what I want.


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


5) Jedi packet trick: combine the remote NIC flash with an internal "over-the-PCI-bus" NIC flash and then it becomes clear that you have a direct conduit between the inner & outer NICs bypassing all OS controls. Note also that there is no way to count PCI-to-PCI transfers in the current PC architecture ("current" = "shipping").


But at least on AMD systems you have IOMMU ( and Intel has its own flavour) , so your reach through PCI could be severely limited...
On the journey of life, I chose the psycho path.

Pyr0Beast ::

This EEPROM is peanuts, it's used AFAIK just to hold MAC...
As well as 100/10, half/full duplex select and many other parameters. However, there is no firmware there, that's certain.

I think it could be possible to flash the card without even waking or powering up the computer. I doubt TC would supervise waking up from S3, merely because of problems which would be if the PC didn't wake up properly.
I'm not sure if you would have time to flash NIC during system boot.

And TC wouldn't provide any protection from flash when only NIC is active. Mainboard clockgen at that power state is not active which means there is no data communication between components, perhaps SMBus is active, but that's not really useful.

And what if you insert a dummy HW which would initialize just after TC has finished checking and approved boot, and since that should be before bios executes, there would be no problem with detection.
Some nanoparticles are more equal than others

Good work: Any notion of sanity and critical thought is off-topic in this place

Brane2 ::

And TC wouldn't provide any protection from flash when only NIC is active. Mainboard clockgen at that power state is not active which means there is no data communication between components, perhaps SMBus is active, but that's not really useful.


Whichever means you use, it seems that if all brains are on TC and NIC just transfer the frame for checking it has to do it fast enough for DDos to be impossible. Which means that with 1GBIt NICs solution wouldn't be exactly low-power or cheap, especially on system with several NICs...
On the journey of life, I chose the psycho path.

arrigo ::


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


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.


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.


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.


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 ?


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.


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


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

arrigo ::

Ah, you raise several fascinating points:


I think it could be possible to flash the card without even waking or powering up the computer. I doubt TC would supervise waking up from S3, merely because of problems which would be if the PC didn't wake up properly.
I'm not sure if you would have time to flash NIC during system boot.


Yes, waking up from S3 is a non-trivial matter if we speak in terms of TC. What can be modified in S3 state? Well, in theory I could have modified the RAM contents written in a suspend-to-disk so the TC should "checksum" (allow me to use this term to mean "verify integrity" otherwise my posts get too long) it before loading it, right? How could you do that? Well, say we wake up via WoL... when is power returned to the disks? When does the PCI bus have power? Does the TC need the PCI bus to operate? What if we control the PCI bus before the TC wakes up enough (the NIC has to be fully powered up before the TC simply because it processed the WoL packet)?

I don't have answers and I haven't tried TC subversion (yet) but I think the questions are interesting. TC has been seriously designed against subversion from above in a classic Bell-LaPadula model in which hardware is "trusted" but we are working on subverting this trust model: who cares if the operating systems is malicious or not when we control the underlying hardware?


And what if you insert a dummy HW which would initialize just after TC has finished checking and approved boot, and since that should be before bios executes, there would be no problem with detection.


Not sure I understand this point entirely: can you elaborate please?

Brane2 ::


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.


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


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.


Well, galvanic insulation in your PSU unit costs money, but it is done not only to work in particular case, but to satisfy standardized safety margins...

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


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.


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.




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 ;).


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...




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.


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.


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


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...
On the journey of life, I chose the psycho path.

ABX ::

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

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


Poleg tega resni sistem nima anti-virusa. Nehajte primerjat Windows pristope z resnim okoljem.
Vaša inštalacija je uspešno spodletela!

arrigo ::

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


Unless Google is seriously mistaken you have totally missed the point of the majority of the comments so far... It has been a long long time since we have been able to flash anything just by running privileged software and viruses have been installing drivers and other Admin/root -level software for ages...

So no, physical access is no longer a requirement for firmware rootkits.

ABX ::

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


Unless Google is seriously mistaken you have totally missed the point of the majority of the comments so far... It has been a long long time since we have been able to flash anything just by running privileged software and viruses have been installing drivers and other Admin/root -level software for ages...

So no, physical access is no longer a requirement for firmware rootkits.


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.
Vaša inštalacija je uspešno spodletela!

arrigo ::


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


Spoken like a true hacker ;) It would be a good idea if it wasn't that 99.999% of users wouldn't have a clue about this point or the entire contents of this forum!


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


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.

For something as esoteric as firmware attacks the question which manufacturers ask is: "do we need to care?". The answer is a resounding "no"...

Think about it: if it wasn't for Denial & Matej how many of you would have ever heard of my work? Joanna's "Ring -3" is well-advertised because she went to speak at BlackHat and does excellent PR and it speaks about booting operating systems, etc. which is something which people understand. I do no PR, chose a relatively sophisticated and obscure conference in Japan and never mention the operating system except to say that it is irrelevant!


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.


The Wikipedia page describes it quite well and, once again, adding crypto layers to the NIC costs money so you might do it for a 10GE adapter but you most definitely won't do it for a EUR300 Netbook NIC.


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...


It already does - TC is initialised very early in the process. I have to refer you to the book because the boot procedure is not trivial and easy to describe in a forum post but, believe me, it is not elegant and lack of elegance in computing often translates into "buggy".


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


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


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


A saying I always use in the security classes I teach: "If it is done in software (firmware if you will) then it can be broken in software." - I'm not sure I'm the first to have said it but I definitely repeat it very often...


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...


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.

Matthai ::

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.
Zloraba oblasti, avtokracija in tema nikoli ne pridejo hipoma, vedno je vmesno
obdobje mračenja, ko se dan preveša v noč; biti moramo pozorni opazovalci
okolja in varuhi luči, da ne postanemo nemočni ujetniki teme. --W. Douglas

Pyr0Beast ::

Yes, waking up from S3 is a non-trivial matter if we speak in terms of TC. What can be modified in S3 state? Well, in theory I could have modified the RAM contents written in a suspend-to-disk so the TC should "checksum" (allow me to use this term to mean "verify integrity" otherwise my posts get too long) it before loading it, right? How could you do that? Well, say we wake up via WoL... when is power returned to the disks? When does the PCI bus have power? Does the TC need the PCI bus to operate? What if we control the PCI bus before the TC wakes up enough (the NIC has to be fully powered up before the TC simply because it processed the WoL packet)?

Yes, I would agree with that. It would be really interesting if you could modify NIC's firmware and change data in RAM (no clock to do that however, so no write or even read, which means it is impossible when in standby), then flash back to normal firmware. Hit and run attack.
It would be even meaner to edit BIOS's CMOS to disable TC chip or just update it's hashes to suit the new firmware. :)
Once that is done .. you may do pretty much anything you want.

Disks, mainboard and mainboard's chips get power the moment PSU turns on (pretty obvious), however the system will wait for power to stabilize (checks PWR-OK from PSU and PWR-OK from CPU VRM's as well!) and only then, after everything is a-ok send reset signal. Before it does that, nothing is in actual active state and you can't access it. Probably TC starts to work first to check everything and when it is fine send the allow-reset signal. I'm not sure how they did/will do the block POST part.

Not sure I understand this point entirely: can you elaborate please?
You are probably familiar with the way VGA's bios acts as it initializes itself way before the mainboard's BIOS POST. The other thing is with, for example IDE/SATA-RAID controler, which initializes after the mainboard post has completed.
TC chip has only two options to block POST. One is before the system starts and the other one is after the system starts. If it is before. Dummy card could just sit there, dormant until TC did his job of scanning BUS's (which will have to do on it's own). Mainboard's bios will initiate _another_ scan, but it is then when the dormant card will go into active mode.
If it is after, it would make things a bit harder since it could read the list from BIOS, however it may also do it's own scan. However, how would TC act if it detected the card, but it is of unknown type or does not support reading its firmware ? My guess is, or it will frezze, or it will pass.
Some nanoparticles are more equal than others

Good work: Any notion of sanity and critical thought is off-topic in this place

arrigo ::


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.

Brane2 ::


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.


Which IMHO means that it is time for enforcing regulatory limits on these things, just as with quality of insulation in your PSU.
There is no purely technical solution for a problem where it is not even sought after.


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


You are missing the point- this is sole reason why DIP-switch exists today- enable the switch through some arsepain.

OEMs get cards with switch on, mere mortals get it with switch off.

And, as said earlier, it need not be mechanical switch. It can be done with a EEPROM cell and a "few" transistors...


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.


But at POST everything is more or less dead until initialised. So, If you do PCI scan in main BIOS, check other BIOS areas and set IOMMU etc, you should be ready to go...
On the journey of life, I chose the psycho path.

arrigo ::

Which IMHO means that it is time for enforcing regulatory limits on these things, just as with quality of insulation in your PSU.
There is no purely technical solution for a problem where it is not even sought after.


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.


You are missing the point- this is sole reason why DIP-switch exists today- enable the switch through some arsepain.

OEMs get cards with switch on, mere mortals get it with switch off.


Yes, I had missed your point, sorry :) Assuming you accept my apology then yes, I can see your point and yes it would be wonderful but how do you make sure that OEMs flip the dip switch before shipping the system?

But at POST everything is more or less dead until initialised. So, If you do PCI scan in main BIOS, check other BIOS areas and set IOMMU etc, you should be ready to go...


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.).

Translated: there is a window of opportunity right there, TC or not TC...

At which point comes the obligatory smart a** remark: did they deliberately decide that current TC implementations only concern themselves with secure booting and ignore peripherals because it is too hard?

Brane2 ::


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 don't have the time ATM to parse through PCI specs, but even so- what could such NIC really acesss ? Devices on the same _physical_ PCI bus, that would be another NIC per chance if even that ?

MOst NIC's on elchepo stuff are today made for PCIe x1, which means they have no physical bus as they are connected to NorthBridge/whatever_AMD_calls_it_these_days...
On the journey of life, I chose the psycho path.

arrigo ::

Yes, I would agree with that. It would be really interesting if you could modify NIC's firmware and change data in RAM (no clock to do that however, so no write or even read, which means it is impossible when in standby), then flash back to normal firmware. Hit and run attack.


I like where this is going :D, what an amazingly talented bunch of people on this site... now will someone tickle Denial too please?

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.

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.


It would be even meaner to edit BIOS's CMOS to disable TC chip or just update it's hashes to suit the new firmware. :)
Once that is done .. you may do pretty much anything you want.


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.

Disks, mainboard and mainboard's chips get power the moment PSU turns on (pretty obvious), however the system will wait for power to stabilize (checks PWR-OK from PSU and PWR-OK from CPU VRM's as well!) and only then, after everything is a-ok send reset signal. Before it does that, nothing is in actual active state and you can't access it. Probably TC starts to work first to check everything and when it is fine send the allow-reset signal. I'm not sure how they did/will do the block POST part.


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!

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.

You are probably familiar with the way VGA's bios acts as it initializes itself way before the mainboard's BIOS POST. The other thing is with, for example IDE/SATA-RAID controler, which initializes after the mainboard post has completed.


Agreed so far.

TC chip has only two options to block POST. One is before the system starts and the other one is after the system starts. If it is before. Dummy card could just sit there, dormant until TC did his job of scanning BUS's (which will have to do on it's own). Mainboard's bios will initiate _another_ scan, but it is then when the dormant card will go into active mode.


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.

Right now it is the Wild Wild West so we don't even have to worry about that [:-)]

If it is after, it would make things a bit harder since it could read the list from BIOS, however it may also do it's own scan. However, how would TC act if it detected the card, but it is of unknown type or does not support reading its firmware ? My guess is, or it will frezze, or it will pass.


My guess? Disable the card's PCI slot in a future version of TC which actually knows about cards [;-)]

I don't have the time ATM to parse through PCI specs, but even so- what could such NIC really acesss ? Devices on the same _physical_ PCI bus, that would be another NIC per chance if even that ?


According to my BSD boxes there are rarely more than two PCI buses on a given PC-based architecture (which, sadly, includes Macs now) so chances are something interesting is there. A quick check on my MacPro tells me that my nVidia GPU, eSATA and NIC all sit on the same PCI bus.

MOst NIC's on elchepo stuff are today made for PCIe x1, which means they have no physical bus as they are connected to NorthBridge/whatever_AMD_calls_it_these_days...


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.

Zgodovina sprememb…

  • spremenil: arrigo ()

Brane2 ::

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.


So, which sophisticated high-end card is still on real physical PCI bus ?
Even those that do exist are IMHO well past their zenith, and seeking a solution for them seems futile...
On the journey of life, I chose the psycho path.

arrigo ::

So, which sophisticated high-end card is still on real physical PCI bus ?
Even those that do exist are IMHO well past their zenith, and seeking a solution for them seems futile...


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.

Brane2 ::


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.


Sure. Where do I sign ? This seems like a good idea even for HW and not just security wise.
If you sell crappy gear that does nothing but rapidly fills garbage deponies, you should pay some sort of tax or levy.

For example, my previous RAID card from TupperWare was crap, but it has dual use. It is long, full of spikes from on-board connectors and it has very cool handle, so one can use it e.g for clashes with police on "hot-topic" public protests ;o)

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.


Practically whatever I looked for had its newer PCIe counterpart. PCI is bad for many reasons. One is that it eats a lot of pins, other is that bandwidth is shared between devices, also more than one device kills impedance continuity and thus max bus speed. Also, slow devices can totally bog down fast ones.

For all this reasons physical PCI will be dead before you find reasonable solution anyway. IMHO ofcourse...
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

arrigo ::


Practically whatever I looked for had its newer PCIe counterpart. PCI is bad for many reasons. One is that it eats a lot of pins, other is that byndwidth is shared between devices, also more than one device kills impedance continuity and thus max bus speed. Also, slow devices can totally bog down fast ones.


Still on a bus, just called PCIe, it doesn't really change the discussion. The cards I mentioned in my Mac Pro are in effect PCIe, not PCI, I am just not used to calling it with the "formal name".

Brane2 ::

PCIe is not physically really a bus. It's point-to-point interface.
On the journey of life, I chose the psycho path.

arrigo ::

PCIe is not physically really a bus. It's point-to-point interface.


Fair point. It does behave like a PCI bus for what we care about, i.e. PCI-to-PCI transfers.

denial ::

@arrigo:
My knowledge on the topic is pretty limited and this debate has gone much further. So I just read and learn. The stage is for hard-core players only :)
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

Brane2 ::

Fair point. It does behave like a PCI bus for what we care about, i.e. PCI-to-PCI transfers.



Not quite AFAIK. It behaves that way if so configured.

On real PCI all cards can be in principle peers. PCI has ben designed with that in mind, so that you could have multiple CPU cards on the bus, for example and so that cards would actively participate on all bus protocols ( except probably some bits about bus arbitration, which was duty of the logic on the backplane IIRC).

PCIe is different. It's point to point and concrete configuration on PC looks like star, with Norhrbirdge in center and cards, each on its own lattice. Also, sigbnaling is not done through simple bus phases but through messages, flowing through one or more fast serial links.

This means that NorthBridge has its say whether PCIe message from card A will make it to the card B etc. With ordinary PCI this was matter just of the cards that were involved in transaction...
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

ABX ::


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.


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.
Vaša inštalacija je uspešno spodletela!

Brane2 ::

But once it is done, pretty much every customer is scre*ed. Condom non-optional.
On the journey of life, I chose the psycho path.

ABX ::

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.


Ok, but this is national security we are talking here. The very highest level of hacking. Not something a windows user with Norton anti-virus will ever detect.

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


Of course, but what has this to do with Joe using Windows? This is material for proper security experts.
Vaša inštalacija je uspešno spodletela!

Zgodovina sprememb…

  • spremenilo: ABX ()

arrigo ::


Not quite AFAIK. It behaves that way if so configured.

[snip]


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.

So, bottom line, is that eventually through a combination of PCIe, IOMMU/VT-x and TC getting two network cards to talk to each other directly is going to be impossible.


This means that NorthBridge has its say whether PCIe message from card A will make it to the card B etc. With ordinary PCI this was matter just of the cards, involved in transaction...


The Northbridge has a say if it configured to do so and, I believe, it is not currently configured in this way mainly because applications rely on the old PCI behaviour (e.g. in Linux there is at least one driver which allows direct NIC-to-NIC communications).

I am curious to see how far I can take my Jedi Packet Trick in PCIe with IOMMU/VT-x enabled... I need to get myself good documentation on the PCIe controller.

The other interesting question is regarding the channel negotiation at boot: while it appears to be strictly about bandwidth from what I read I am wondering if there is more to this negotiation phase which can be exploited for dubious ends.


Ok, but this is national security we are talking here. The very highest level of hacking. Not something a windows user with Norton anti-virus will ever detect.


I do not believe anyone in this forum has claimed that the discussion was for a Windows user with Norton anti-virus (and you are welcome to read my opinion on anti-virus software).

Of course, but what has this to do with Joe using Windows? This is material for proper security experts.


Indeed it is - that is why we are talking about trusted computing, messing around with ACPI states, PCIe vs. PCI buses, IOMMU/VT-x rather than Javascript, IE and clicking on attachments. All very interesting topics I am sure but not to the current crop of people in this forum.

Did you actually read the interview which Matej put together because I do not believe that it even remotely suggests that it is something for Joe Windows.

Zgodovina sprememb…

  • spremenil: arrigo ()

Brane2 ::

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 didn't mean to be an asshole, but just to point that problem that had some possibly nasty race conditions on classic PCI, might be less difficult on PCIe, albeight probably for wrong reasons. PCIe has been done this way primarily for signalling speed, not security...
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

arrigo ::


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...

I didn't mean to be an asshole, but just to point that problem that had some possibly nasty race conditions on classic PCI, might be more less difficult on PCIe, albeight probably for wrong reasons. PCIe has been done this way primarily for signalling speed, not security...


Hey Brane2, not even taken remotely as "asshole" stuff: you quite rightly pointed out that I was not being precise and security is about being precise when we talk otherwise we are just another Symantec.

As a matter of fact I thank you (and everyone else) for making me think instead of just sitting there accepting what I say without question.

Zgodovina sprememb…

  • spremenil: arrigo ()

ABX ::


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...


If you click on a compromise file with Admin privileges, what is the difference is you get owned by a compromised firmware or classic custom written virus/script?

My point is: there is a simpler way to infect home users, that's all, no more no less.
Vaša inštalacija je uspešno spodletela!

Brane2 ::

As a matter of fact I thank you (and everyone else) for making me think instead of just sitting there accepting what I say without question.


"Just serving the people" - as old local saying goes ;o)
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

arrigo ::

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.

denial ::

@arrigo:
Wow, you've raised some interesting points in previous post which are worth to underline.

First...
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..."

Right. The PEBKAC issue is just a myth. Users surfing with admin privs? Well, they shouldn't and it's on the vendor/developer to prevent that.

Second...
I was not being precise and security is about being precise when we talk otherwise we are just another Symantec.

That's the main difference between professionals and amateurs. The former will always admit in case they are wrong, the later will always deny.

Third...
about AVs. I agree, they are useless. Not only, they are adding one more attack layer to compromise the system.

But this is just off-topic. Sorry for that.
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

ABX ::

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.


I agree on this, but I'd like to point out that the remote exploit can be triggered only by a compromised manufacturer.
As for the anti-virus, I know is security myth.
Vaša inštalacija je uspešno spodletela!

arrigo ::

Denial:

Right. The PEBKAC issue is just a myth. Users surfing with admin privs? Well, they shouldn't and it's on the vendor/developer to prevent that.


Well, there's more to it than just prevention on the part of the vendor/developer: the whole stack should be secured. The biggest problem with TC is that it was hijacked by the DMCA gang before a useful discussion on how to integrate TC with GPL/BSD software could be had. They managed to pretty much convince everyone that TC=DRM and killed it all off.

The point is that I think we all realise that there is little hope of truly securing Windows/Linux/BSD and even if we push securing to the limit (ASLR, DEP, W^X, you name it) all that is going to happen is that eventually someone is going to look up from the bottom rather than down from the top and then we are in real trouble.

We will not be able to issue patches for a bottom-up attack, we will not be able to ship chips to users to solder on their motherboard so we need a plan now and, like it or not, the best plan on the table could be TC.

The question is only when the ROI for a firmware attack becomes lower than the ROI for an application-level attack.

That's the main difference between professionals and amateurs. The former will always admit in case they are wrong, the later will always deny.


That is very kind and the sad truth about the security industry is that most often than not all you hear is denial.

about AVs. I agree, they are useless. Not only, they are adding one more attack layer to compromise the system.


"Software can always be broken by software" ;)

ABX:
I agree on this, but I'd like to point out that the remote exploit can be triggered only by a compromised manufacturer.


No, you are mistaken: there is no such thing as a "compromised manufacturer" just like Microsoft does not ship knowingly compromised software. What you have are "vulnerable manufacturers" and yes, the remote exploit can be triggered only on vulnerable NICs but, very very very important point, I have not tested all the NICs on the planet...

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

Arrigo

Zgodovina sprememb…

  • spremenil: arrigo ()

ABX ::


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

Arrigo


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.
If nothing else this problem will make people realize to trust only the best providers.
Windows gets infected by 3rd party. In this case, the malicious firmware comes from a trusted company.
Vaša inštalacija je uspešno spodletela!

Zgodovina sprememb…

  • spremenilo: ABX ()

arrigo ::


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.
If nothing else this problem will make people realize to trust only the best providers.
Windows gets infected by 3rd party. In this case, the malicious firmware comes from a trusted company.


ABX: no, your security is not fine and no, the malicious firmware come from me, not from IBM or any other trusted company. The situation is identical to the situation with Windows: an insecure system is being shipped and taken advantage of. The only difference is in the sophistication of the attack and the novelty.

ABX ::

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.
Vaša inštalacija je uspešno spodletela!

Zgodovina sprememb…

  • spremenilo: ABX ()

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.

ABX ::

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.


This is your post:


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.

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

I still haven't found how the exploit can be triggered remotely by an untrusted source.
Vaša inštalacija je uspešno spodletela!

Zgodovina sprememb…

  • spremenilo: ABX ()

arrigo ::

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.

ABX ::

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.
Vaša inštalacija je uspešno spodletela!

arrigo ::

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...

ABX ::

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...


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.
Vaša inštalacija je uspešno spodletela!

Zgodovina sprememb…

  • spremenilo: ABX ()

Pyr0Beast ::

.. there are always free ports on the router/switch :)
Some nanoparticles are more equal than others

Good work: Any notion of sanity and critical thought is off-topic in this place
strani: 1 2 3


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Ameriška šola preko kamere na šolskih prenosnikih vohunila za svojimi dijaki (strani: 1 2 )

Oddelek: Novice / Zasebnost
536224 (4264) Tear_DR0P
»

Strojni protivirusnik

Oddelek: Novice / Varnost
263297 (1699) Matthai
»

APT (Advanced Persistent Threats) napadi iz Kitajske

Oddelek: Novice / Varnost
122852 (1696) Matthai
»

Predstavitev Ring -3 rootkitov na BlackHat konferenci

Oddelek: Novice / Varnost
82015 (1479) jype
»

Intervju z Joanno Rutkowsko (strani: 1 2 )

Oddelek: Novice / Varnost
544737 (2918) Sago

Več podobnih tem