Summary

OPUS is a tool for dynamic software patching capable of applying fixes
to a C program at runtime requiring little programmer effort. The
authors observer that users delay or ignore installing patches for three
main reasons:

- Unreliable due to shortened testing cycles and tendency to bundle
security fixes
- Irreversible: there is no reliable method of undoing the damage
- Disruptive: application or system must reboot. It is unacceptable in
some critical applications or platforms

This paper aims at the third reason. The dynamic patching proposed has
three steps. First, the system assesses safety of dynamic patch using
static analysis to point out unsafe side-effects; then generates dynamic
patch from real patch by integrating with GNU build environment. At last
step, When applying security patch at runtime, it redirects function
call to new function code in dynamic libraries. Application or system
reboot is not required.

Because the problem of checking the complete safety of patches is
undecidable, the paper narrows the scope to conservative safety. The
patches should not make additional writes to non-local program state,
i.e. stack frame out of the patched function, for example, global and
heap data. The patches also should not alter the semantic meaning of the
function’s return value. The paper designs a type system style
derivation tool to assess the the conservative safety.

During the process of run-time application, the system will inspect the
stack first to make sure that all functions that need to be changed are
not on the stack at the time when the patch is applied. After that, the
system will load the new version of the code into the target thread’s
address space and overwrite the first instruction within the old code by
an indirect jump to the new code.

The paper did experiments with real patches. It studied 883 CERT
notification and finds 50.4% were amenable. Source code of 115 were
examined and 111 were amenable. It ran 26 real patches, and applied 22
patches successfully. 4 of them failed due to implementation bugs.

The reason I select this paper is that I think the run-time security
update is the key point of the paper. It is very useful for those
systems whose services are critical and the security is also concerned,
such as real-time control system, interactive applications, etc.
Although the approach used in the paper can not cover all scenarios, it
is simple and practical. We can discuss how to improve the methods and
learn how to apply other techniques in
your projects. Another interesting thing is that all authors are
students. It is said that it is only a course project, but accepted by
USENIX. Maybe we can get some illumination from their work.

Pros:
This paper provides run-time patches fix for a particular range of
vulnerability patches. It indicates the limitations explicitly and
clearly, which have readers easy to catch its point and focus on the
scope of the paper. The paper provides sufficient details about idea and
implementation. It does quite good evaluation on real patches. It shows
that the system has very low overhead. They did huge amount of work on
patches source code analysis

Cons:
The approach only works for particular kind of patches. The patched
function could not be top-level functions，can not change initial values
of global and function signature. It also does not support patching
in-lined functions. Although static safety analysis tools is provided,
the burden of safety still is on the programmer. When they had the
survey of vulnerabilities announced by CERT, no exact criteria for
selecting patches are described. We also discussed the applicability.
Since only part of security vulnerabilities can be fixed during
run-time, the user may prefer to reboot the system with the full patches
installation to avoid any security risks as long as it has backup. We
think there may be alternative solutions for run-time patches fix.  For
some transaction servers running at big service providers, such as
Amazon, there are one or more servers cluster to backup each other. So
it is convenient to reboot one or more machines for installing patches,
while other servers still can work without interruption from the point
of view from external users. Virtual machine switchover may be a
potential solution too.


Q: The paper designs type system style derivation tool for static
analysis, what about its time overhead? can it guarantee to terminate？
A: The time overhead should be low since it only works on short patches.
It should be able to terminate since it is just operational semantics.



Vote result:
Accept:12
Weak Accept: 0
Weak Reject: 0
Reject:0