Author mentioned a custom package generator tool "Ostinato". I met the author of this tool 2-3 months back. A lone guy working on this tool as a side project. Amazing work. :)
Packets of Death
111–119 of 119 posts
Re: Packets of Death
#112Earlier quoted context omitted.
In this light, the surprising thing is that we don't hear about firmware bugs more often. Have manufacturers have been doing a great job of keeping things simple and exhaustively testing, driven by the fear of the losses an incident and recall would cause?
Rare bugs on released hardware are almost by nature ignored in favor of new products. Its also why fuzzing is such as great method in finding security bugs.
This is probably common in routers. It is easier for most people to buy a new one than upgrade the firmware that was 3 years old when the device was bought.
Re: Packets of Death
#113Before actually testing this with the real payload, is there a better way of determining if you have a potentially vulnerable driver than something like this? # awk '/eth/ { print $1 }'
This is not about the particular linux driver, but about a particular chipset, and even then, only sometimes...
The linux e1000e may support many chipsets, so the fact that it's in service on your box doesn't necessarily mean you're running the suspect chipset, or that it's vulnerable.
Check with lspci -v, and check with the concrete test using the cold boot+magic packet others and the OP have posted.
Re: Packets of Death
#114Earlier 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…
Isn't formal verification the unicorn of software development? I know it's rumored to exist, and you will find it in academia, but I've never come across it 'in the wild'.
It is out there:
http://en.wikipedia.org/wiki/Formal_verification#Industry_us...
In the wild what is more common in my experience is to use a formal specification language like Z or Object-Z and then recreate the the program in a "normal" language using pair programmers and/or extensive code review to attempt to ensure it conforms to the specification. While not perfect, for critical things this approach is far more time consuming and less bug prone than typical development.
I have also seen limited attempts at writing code generators that take Object-Z specifications as input. My understanding is that this is an area of ongoing research, but even a program that generates code for a subset of a Object-Z specification can save a lot of time.
Example research: http://www.jot.fm/issues/issue_2008_11/article6.pdf
Re: Packets of Death
#115I'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…
The EEPROM does not contain the actual firmware, but it's configuration (or configuration of hardware itself in case of simple designs). Essentially any Fast Ethernet and newer NIC has some configuration EEPROM that is accessible by ethtool (which is what the tool is for after all). Common use cases for ethtool are persistently changing MAC address and fixing broken hardware (either to work around pre-existing HW bugs or to fix it after this EEPROM got somehow erased).
Generally the EEPROM does not contain anything like executable code, although it probably can contain patches for microcode on many NICs.
Re: Packets of Death
#116Intruiging. Intel 82574L ethernet controller looks to be popular too. Intel, Supermicro, Tyan and Asus use it on multiple current motherboards and Asus notably on their WS (Workstation) variants of consumer motherboards, e.g. the Asus P8Z77 WS (socket LGA 1155) and Asus Z9PE-D8 WS (dual CPU, socket LGA 2011).
It's quite popular because while it has large amount of weird quirks (usually specific to silicon revision / configuration) it still works and in many cases better than other comparable chipsets.
Re: Packets of Death
#117As someone who works with FPGAs/ASICs, this isn't that weird. Everything gets serialized/deserialized these days, so there's all kinds of boundary conditions where you can flip just the right bit and get the data to be deserialized the wrong way. What's more interesting is that it bypasses all of the checks to prevent this from happening. Here is the wiki page on the INVITE OF DEATH which sounds like the problem you…
> Everything gets serialized/deserialized these days, ... and get the data to be deserialized the wrong way. Can you elaborate? I recognize the words, but not the meaning.
Often there's just a pair of wires/pins into a chip that you use to control the chip, for a NIC, modem, radio, what have you - accompanying this is a protocol you use to comminicate with the chip.
For e.g. a NIC, it's not that many things that need to go wrong when you encapsulate a packet it should forward out on the wire so it rather looks like a control packet triggering some undesired results on the chip. Or vice versa.
Re: Packets of Death
#118Congrats Sir, you've just discovered the Internet Kill-Switch!
The “red telephone,” used to shut down the entire Internet comes to mind.
You discovered howto immunize friends and kill enemies in CyberWars.
Do governments have an Internet kill switch?
Yes, see Egypt & Syria they're good examples. We know China is doing Cyberwars, they are beyond Kill-Switches.
Techcrunch: http://techcrunch.com/2011/03/06/in-search-of-the-internet-k...
Wiki: http://en.wikipedia.org/wiki/Internet_kill_switch
We know Goverments deploy hardware that they can control when needed. Smartphones are the best examples for Goverment issued backdoors, next to some Intel Hardware (including NICs).
Re: Packets of Death
#119Earlier quoted context omitted.
Well, it's very weird if you understand anything about Network protocols. It's a layer of complexity that shouldn't be being touched by your NIC, so there shouldn't be a bug there because there shouldn't be code there.
I wonder what _other_ data coming down the wire that nic is monitoring and executing code in response to?
It's a subset of the misinformation hats, Mr. "HTML coder"