A look at the MS-SQL worm
Posted Jan 30, 2003 2:09 UTC (Thu) by JoeBuck
Parent article: A look at the MS-SQL worm
I think an argument over whether Karsten's numbers are right might be missing an important point: while he may not be right in his suggestion that in this case 99% of the people applied the patch and we still had major
damage from the worm (I, for one, doubt this), I could easily conceive of future cases where this might be true.
Consider this scenario: a remote exploit is discovered in Apache. Patches are quickly produced, but only 99% of people running Apache apply the patch by the time that a worm is deployed.
The worm is designed to generate so much traffic as to completely saturate a number of crucial backbone links, and it's smartly written (that is, it closes the security hole behind itself, so that the same hole can't be used
to clear the infection; it stores itself on disk, so that a reboot doesn't cure it). Blocking the SQL port is one thing; blocking port 80 all over the net basically turns off the web, generating massive economic disruption.
I think that the only way out of this mess is to start to think about techniques that can yield formal proofs that certain flaws are not present.
This is probably only feasible if applied to very small pieces of code,
but perhaps software can be architected so that the volume of code
that is ever exposed to untrusted data is kept very small, so that it
can be proved to be free of buffer overflows, vulnerability to cross-site scripting and similar attacks, and race conditions. OpenBSD-style code
auditing won't do the trick: to have hope of proving safety properties you
pretty much have to design the code and the proof together.
Such techniques don't have to be incompatible with C (though C does
make things harder). Some form of
assume-guarantee approach can be used to determine preconditions and
postconditions for each function, and given a meticulous effort it
might be provable that a given daemon contains no buffer overflows,
or that cross-site scripting is impossible, or that it's not possible
to get to a shell. I would expect that it will take 100 times as long
to write such code, but it could be argued that this most be done to
ensure the continued operation of the net (so maybe government funding
could be obtained).
to post comments)