|Main Archive Page > Month Archives > full-disclosure-uk archives|
On Thu, 21 Jan 2010, Dan Kaminsky wrote:
> But imagine an oldschool application drenched in strcpy, where you've
> lost context of the length of that buffer five functions ago.
When you discover you are riding a dead horse, the best strategy is to dismount. When you discover the program is designed too badly to be maintained, the best strategy is to rewrite it.
> Or imagine the modern browser bug, where you're going up against an
> attacker who *by design* has a Turing complete capability to manipulate
> your object tree, complete with control over time.
Such an attacker must be assumed to possess hyperturing computing power because an exploit can communicate with an oracle.
But I do not think this case is much different from the previous one: most, if not all, of those bugs are elementary integrity violations (not prevented because the boundary between trusted and untrusted data is not clear enough) and race conditions (multithreading with locks is an idea on the same level as strcpy).
> Or, worst of all, take a design flaw like Marsh Ray's TLS
> renegotiation bug.
One needs to pay utmost attention to the design and its correctness. This has been known for decades, hasn't it?
(An interesting finding regarding the renegotiation issue: People analyzing the protocol in the past had spent a lot of energy on its individual parts, esp. the handshake, and very little work had been done on the protocol as a whole.)
> c) The system needs to work entirely the same after.
Not entirely. You want to get rid of the vulnerability. -- Pavel Kankovsky aka Peak / Jeremiah 9:21 \ "For death is come up into our MS Windows(tm)..." \ 21st century edition / _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/