Charlie: The iPhone bug has to do with telling the phone there is a certain amount of data, and then not sending it as much as you said you would. The function that reads the data starts returning -1 to indicate an error, but the other parts of the program don't check for this error and actually think the -1 is data from the message. This shows how complex it can be to write secure code, as separately, each part of the program looks correct, but the way they interact is dangerous!
OUCH.
If there's an industry contest I'd like to referee now, it's fuzzers vs. static analysis. Industry spends a cubic shit-ton on static analysis (for instance, find an F-500 that doesn't have a couple copies of Fortify gathering dust). But fuzzers appear to be kicking ass in terms of actual findings, and vendors don't invest nearly as much into them.
(Static analyzers parse and symbolically analyze source code or binaries against rules, like taint propagation and API blacklists; fuzzers mimic actual inputs to real running systems and vary those inputs maliciously over minutes, hours, or days).
Especially if you're the actual developer. 80% of the time it takes to write a third-party fuzzer goes into reconstructing the target's protocol or API from scratch.
OUCH.
If there's an industry contest I'd like to referee now, it's fuzzers vs. static analysis. Industry spends a cubic shit-ton on static analysis (for instance, find an F-500 that doesn't have a couple copies of Fortify gathering dust). But fuzzers appear to be kicking ass in terms of actual findings, and vendors don't invest nearly as much into them.
(Static analyzers parse and symbolically analyze source code or binaries against rules, like taint propagation and API blacklists; fuzzers mimic actual inputs to real running systems and vary those inputs maliciously over minutes, hours, or days).