c.
Binary Patching Considerations
In situations where it is impossible to access the original source code for a program, we
may be forced to consider patching the actual program binary. Patching binaries
requires detailed knowledge of executable file formats and demands a great amount of
care to ensure that no new problems are introduced.
Why Patch?
The simplest argument for using binary patching is when a vulnerability is found in software
that is no longer vendor supported. Such cases arise when vendors go out of business
or when a product remains in use long after a vendor has ceased to support it.
Before electing to patch binaries, migration or upgrade should be strongly considered in
such cases; both are likely to be easier in the long run.
For supported software, it remains a simple fact that some software vendors are unresponsive
when presented with evidence of a vulnerability in one of their products. Standard
reasons for slow vendor response include ???we can??™t replicate the problem??? and ???we
need to ensure that the patch is stable.??? In poorly architected systems, problems can run
so deep that massive reengineering, requiring a significant amount of time, is required
before a fix can be produced.
Pages:
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852