81–90 of 119 posts
/edit Ah, I spoke to soon; the author has updated his page here with diffs between affected and unaffected EEPROMs:
Earlier quoted context omitted.
It's worse than that. It's not BIOS-- it's a freestanding computer. You'll enjoy this (or be horrified by it): http://fish2.com/ipmi/itrain.html
But it's a freestanding computer that means that I don't need to go to the data center at two in the morning to bring up a box that's kernel panicked. Yeah, be careful with it. Firewall it silly. But recognize that it's a tool that can be very useful.
Being grafted onto the same NICs on the server computer that you might potentially expose to the Internet makes firewalling them a more difficult proposition. I get a lot of piece of mind from having management interfaces on an an out-of-band control network whenever possible.
I've always had mixed emotions about NICs that have hardware assisted offload features. I welcome the decrease in CPU utilization and increased throughput, but the NIC ends up being a complex system that very subtle bugs can lurk inside versus being a simple I/O device that a kernel driver controls. If there's denial of service hiding in there I wonder about what other security bugs might be lurking. It's scary stuff…
# awk '/eth/ { print $1 }' That is great HN content! Debugging deep down the rabbit hole, until you find a bug in the NIC EEPROM - and the disbelief many show when hearing a software message can bring down a NIC. I for one would enjoy reading more content like this on HN that what qualifies as best as a friday-night hack
Earlier quoted context omitted.
It would be interesting to see what the actual error in the NIC firmware source was. This invalidates my assumption that a shop like Intel probably uses formal verification in firmware development. Its also scary to consider how many very important (nuclear/damn control, etc) systems while themselves might be formally verified are dependent on services of lower level software (OS, drivers) and hardware (firmware) tha…
Dam control, or damn control? I teach a control systems course, so I know about both kinds. PS You should be very frightened. The industrial control systems industry are slow to adopt new tech/new best practices/anything else new; and even more reticent to touch anything that "works." Tons of vulnerable equipment controlling dangerous things with default passwords (if any at all). I could go on for days.
Earlier quoted context omitted.
But it's a freestanding computer that means that I don't need to go to the data center at two in the morning to bring up a box that's kernel panicked. Yeah, be careful with it. Firewall it silly. But recognize that it's a tool that can be very useful.
They're definitely useful tools-- don't get me wrong about that. The fear is that they're controlled, essentially, by an in-band signaling mechanism. Being grafted onto the same NICs on the server computer that you might potentially expose to the Internet makes firewalling them a more difficult proposition. I get a lot of piece of mind from having management interfaces on an an out-of-band control network whenever po…
So is it only the byte at 0x47f that matters? Could you just send a packet filled with 0x32 0x32 0x32 0x32 0x32 to trigger this? (Like, download a file full of 0x32s?) Or does it have to look like a SIP packet? You'd think the odds of getting a packet with 0x32 in position 0x47f is almost 1/256 per packet? So why aren't these network cards falling over everywhere every few seconds?
So is it only the byte at 0x47f that matters? Could you just send a packet filled with 0x32 0x32 0x32 0x32 0x32 to trigger this? (Like, download a file full of 0x32s?) Or does it have to look like a SIP packet? You'd think the odds of getting a packet with 0x32 in position 0x47f is almost 1/256 per packet? So why aren't these network cards falling over everywhere every few seconds?
That is great HN content! Debugging deep down the rabbit hole, until you find a bug in the NIC EEPROM - and the disbelief many show when hearing a software message can bring down a NIC. I for one would enjoy reading more content like this on HN that what qualifies as best as a friday-night hack
You may then enjoy these: * http://www.youtube.com/watch?v=euMHlV6MNqs * http://www.youtube.com/watch?v=8Q8EFwKVKdA
HIGHLY recommended to anyone who enjoyed the article.
It's a remote PHY injection at the hardware level - basically hacking the chip directly thanks to "special" content, i.e. putting a packet header within the packet.