"reverse-engineered the format of the EEPROM"?
There is and has been for a while code available /en plain public/, including source, to put custom boot things in your network EEPROM. He could equally well have done it using a custom BIOS, there's also code available /en plain public/ for that. So the wording here is maybe a bit too much credit.
Actually doing it, and in network card firmware, just highlights again how we trust our hardware, firmware, and software. It's also a great show of "ph34r m`/ m4d 5k1llz" that people are so fond of in the security industry. Because it gets lots of free publicity.
What's happened here is that someone built an impressively large stack of things leveraging each other to "load" an exploit. Loading a bit of "crack" code right before an application isn't new by any means. The point is, of course, apart from the show, that if you have the physical box you can subvert it seven ways from sunday.
But this isn't as big and certainly not as new as you might think. Compare and contrast the paper _Reflections on trusting trust_* where a system's compiler had a bit of code added to add a backdoor to a system's login program, and code to add this subversion back in if it was removed from the compiler. Compile, remove the evidence from the compiler source, recompile, and done. Don't forget to look up the date on that paper.
Yes, it's very real. Yes, it has been done, and not just once. Yes, we're all in grave danger. And what do we do about it? Well, what *have* we been doing about it the last score-or-so years? And why? Answer me that and then tell me if you'd rather run this risk or live in a straitjacket where everything is locked up, down, and seven ways from sunday sideways.
I for me rather live in a world where specifications, hardware, firmware, and software are open. It leaves more options to choose how and who to trust.
* http://cm.bell-labs.com/who/ken/trust.html