In the June 2004 Security column (“A Patch in Nine Saves Time?”pp. 82-83), Bill Arbaugh makes two interesting observations: first, whoever has the tightest observe-orient-decide-act (OODA) loop will prevail in a confrontation; second, the infection rates of recent worms suggest that the good guys are losing the battle

Keromytis, Angelos D.

Columbia University Academic Commons

94 ComputerS E C U R I T YI n the June 2004 Security column(“A Patch in Nine SavesTime?”pp. 82-83), Bill Arbaughmakes two interesting observa-tions: ﬁrst, whoever has the tight-est observe-orient-decide-act (OODA)loop will prevail in a confrontation;second, the infection rates of recentworms suggest that the good guys arelosing the battle. Arbaugh offers some sensible sug-gestions to vendors and security pro-fessionals on improving patch man-agement. However, the best indicationthat we are losing the battle is not theinfection rates of worms such asSlammer and Blaster, but the shrink-ing interval between discovering andannouncing a new vulnerability andthe appearance of a worm or attackthat exploits it. The most recent example is theWitty worm, which effectively ex-ploited a vulnerability present in asmall population of hosts—approxi-mately 12,000 computers. Although itwas ﬁrst discovered on 8 March 2004,the vendor didn’t announce the vul-nerability until 18 March, after it hadmade a patch available. A little over a day after the announcement, Wittymade its ﬁrst appearance.ZERO-DAY ATTACKSGiven such a short turnaround time,we can reasonably expect to soonexperience a zero-day worm. Zero-dayattacks are those for which usersreceive no prior warning and thus haveno preventive measures in place. To date, a combination of aggressivepacket ﬁltering and proactive applica-tion patching could—at least in prin-ciple—defeat all the worms we haveencountered. Although we could, intheory, deploy patches and network ﬁl-ters automatically, the practicality ofemploying such measures and theireffect on regular system operation arean entirely different story.Witty came close to being a zero-dayworm; for most organizations, it was.Few system administrators had evenseen the announcement before theattack, much less downloaded andinstalled the necessary software patch. Furthermore, as Arbaugh (“Win-dows of Vulnerability: A Case Study ofAnalysis,” Computer, Dec. 2000, pp.52-59) and others such as Eric Rescorla(“Security Holes … Who Cares?” Proc.12th Usenix Security Symp., Usenix,2003, pp. 75-90) have noted, manyadministrators ﬁnd it impractical, if nototherwise unacceptable, to patch orupgrade their systems when a vulnera-bility is announced. Instead, they waitfor news of an actual exploitation. Inmany cases, this is simply too late. PATCH ON DEMANDWhat to do then? One new idea is tointegrate the vulnerability discovery,patch generation, and patch applica-tion cycles into a system that wouldautomatically detect a new attack, ana-lyze its modus operandi, determine thebest software patch, and apply it at thedesired level of granularity—LAN,enterprise, or Internet-wide. Although the system would stillfunction by reacting to attacks, itsresponse time would be significantlyshorter. Perhaps most importantly, itcould operate autonomously. Furthermore, by retaining a focus onsoftware patching, this approach couldavoid at least some pitfalls of network-based defense techniques. These tech-niques, which include packet andcontent ﬁltering, can fall prey to wormsthat exploit opportunistic encryption,polymorphism, or metamorphism.Traditionial viruses use polymorphismto make detection more difﬁcult: Asmall decoder, which changes periodi-cally, decrypts the virus’s main bodyprior to execution.Metamorphic viruses, on the otherhand, completely translate the viruscode to use different but equivalentinstructions every time it infects a newtarget. Classic signature-matching tech-niques are, for the most part, incapableof detecting such viruses.Metamorphism, in particular, makesdetecting new viruses extremely difﬁ-“Patch on Demand”Saves Even MoreTime?Angelos D. Keromytis, Columbia UniversityA vaccination system couldautomatically generatepatches to protect anapplication’s source code.cult and time-consuming. Worse, sev-eral advanced metamorphic virusengines, such as Zmist, have been pub-licly available for a few years. I suspectthat their use in a future worm is onlya matter of time. One reason we havenot seen them yet may be that currentpractices are so effective in creatinghighly infectious worms.Vaccination systemCan we develop a patch-on-demandsystem that is both practical and safe? This is the question we are investi-gating at Columbia University’s Network Security Lab (http://nsl.cs.columbia.edu/). We believe that someof the necessary technology, at least forthe initial steps, is already available.To begin with, we think it is mucheasier to identify a previously unknownvulnerability by observing the actionsof an attacker, such as a worm, thatmust “demonstrate” its use (and sideeffects) while attacking a new system. Figure 1 shows an automated wormvaccination system that includes a hon-eypot—a security resource that pre-tends to be an easy target for purposesof attracting and exposing attackers.Using honeypots for early-warning sys-tems has increased over the past fewyears. A properly instrumented vacci-nation system could monitor the attackactivity at the software level and detectpreviously unknown attacks againstwhat the adversary considers a validtarget for infection. As the worm attempts to infect thesystem, it reveals not only the vulnera-bility’s existence but also its precisecharacteristics. For example, in the caseof buffer overﬂows, a trace of the stackshows up at the time of the attack,along with identiﬁcation of the routinewhere the overﬂow occurred, the vul-nerable buffer, and the attack vector.Developers could use this system toget the information needed to developa patch manually. We propose going astep further. By applying a series oftransformations to the vulnerableapplication’s source code, we want toautomatically create a narrowly deﬁnedpatch that protects against the speciﬁcvulnerability. At its simplest, such apatch would recompile the vulnerablepart of the application with a mecha-nism like StackGuard. More advanced ﬁxes are also possi-ble. For example, we have been exper-imenting with patches that maintainthe application’s availability (http://nsl.cs.columbia.edu/projects/wormv/).ResultsOur preliminary experiments withseveral vulnerable open source appli-cations show a better than 80 percentsuccess rate in protecting against anattack and maintaining continuousoperation. In the remaining cases, thepatch successfully thwarts the attack,but the application terminates its exe-cution. An analysis of an Apache server thatour system patched in response to aSlapper-like attack showed no impacton performance. Furthermore, thepatching process took less than 10 sec-onds. Naturally, additional research isneeded to determine the mechanism’slimits with a richer corpus of vulnera-ble software.August 2004 95Hypothesistesting andanalysisApplicationserverHost-basedsensor(4) Vulnerabilitytesting andidentificationInstrumentedapplicationPatchgeneration(5) Possible fixgenerationSandboxedenvironment(6) Application update(3) ForwardedfeaturesAnomalydetectionengineFirewallsensorPassivesensorHoneypot(2) NotificationsEnterprisenetworkRemote sensorInternet(1) Worm scans/infection attemptsFigure 1. Worm vaccination architecture. (1) Sensors deployed at various locations in thenetwork detect a potential worm and (2) notify an analysis engine. (3) The engine forwardsthe potential infection vector and other relevant information to an isolated environment,where (4) the potential infection vector is tested against an appropriately instrumentedversion of the targeted application and the vulnerability is identified. (5) Several softwarepatches are generated and tested using different heuristics. If one of the patches is foundto be immune to the infection, (6) the application server is updated.TrustAt a different abstraction level, theseideas could serve as existential proof forreactive decentralized mechanisms thatdo not require collaboration but canrespond through purely local action toglobal phenomena such as worms.Several researchers have proposedthe need for large-scale collaborativemechanisms to detect and ﬁlter futureworm attacks. For example, VernPaxson proposed a Cyber Center forDisease Control for identifying out-breaks, rapidly analyzing pathogens,and fighting the infection (“How toOwn the Internet in Your Spare Time,”Proc. Usenix Security Symp., Usenix,2002, pp. 149-167). The CCDC coulduse our mechanism to quickly createneeded patches. The trust issues inherent in such anapproach present unique challenges. Itseems unlikely that many organiza-tions would trust such a third entity todynamically alter their own defensiveposture—for example, by pushing net-work filters to network firewalls orsending software patches. CHALLENGESIn our exploratory work we havealready identified issues that requirefurther research, such as reasoningabout the system’s reliability and secu-rity, extending it to cover other typesof software failures and attacks, andhandling binary-only systems—toname but a few. RiskAs with any fully automated task,the risks of relying on automatedpatching and testing as the only real-time defense techniques are not fullyunderstood. Furthermore, it should beobvious that this system does notaddress the growing number of e-mailworms that spread by exploiting othertypes of security flaws and humancuriosity.Software engineering, programminglanguages, security, and networkingare all components in developing thesystem. At the very least, some of thetechniques we have developed shouldhelp in the traditional “penetrate andpatch” cycle.A CCDC whose role was conﬁned tomanaging a large number of hon-eypots and attack-detection sen-sors would be valuable in spreading theword of new attacks. Organizations, ortheir security service providers, couldrun software vaccination systems inde-pen- dently of each other. All that thishypothetical CCDC would do is broad-cast the newly captured attack vectorand allow individual organizations todevelop their own patches in real time:Trust but verify! Angelos D. Keromytis is an assistantprofessor in the Department of Com-puter Science and director of the Net-work Security Lab at Columbia Uni-versity. Contact him at angelos@cs.columbia.edu.S e c u r i t yEditor: William A. Arbaugh, Dept. of Computer Science, University of Marylandat College Park; waa@cs.umd.eduVisit Computermagazine online for current articles,links to onlineresources, and a collection of classics that changed the computing field. www.computer.org/computer/

"Patch-on-Demand" Saves Even More Time?

https://academiccommons.columbia.edu/doi/10.7916/D8ZP4GJ3/download

"Patch-on-Demand" Saves Even More Time?

Abstract

Similar works

Full text

Available Versions

Columbia University Academic Commons