SQLrand: PreventingSQLInjectionAttacks [611103]

SQLrand: PreventingSQLInjectionAttacks
Stephen W.BoydandAngelos D.Keromytis
Department ofComputer Science
Columbia University
fswb48,ang [anonimizat]
Abstract. Wepresent apractical protection mechanism against SQL injection
attacks. Such attacks targetdatabases thatareaccessible through aweb front-
end, andtakeadvantage offlawsintheinput validation logic ofWebcomponents
such asCGI scripts. Weapply theconcept ofinstruction-set randomization to
SQL, creating instances ofthelanguage thatareunpredictable totheattack er.
Queries injected bytheattack erwill becaught andterminated bythedatabase
parser .Weshowhowtousethistechnique with theMySQL database using an
intermediary proxy thattranslates therandom SQL toitsstandard language. Our
mechanism imposes negligible performance overhead toquery processing and
canbeeasily retrofitted toexisting systems.
1Introduction
Theprevalence ofbufferoverflowattacks [3,29]asanintrusion mechanism hasresulted
inconsiderable research focused ontheproblem ofpreventing [14,11], detecting [35,
23,25],orcontaining [33,31,21,12]such attacks. Considerably lessattention hasbeen
paid toarelated problem, SQL injection attacks [1].Such attacks havebeen used to
extract customer andorder information from e-commerce databases, orbypass security
mechanisms.
The intuition behind such attacks isthatpre-defined logical expressions within a
pre-defined query canbealtered simply byinjecting operations thatalwaysresult in
trueorfalsestatements. This injection typically occurs through aweb form andasso-
ciated CGI script thatdoes notperform appropriate input validation. These types of
injections arenotlimited strictly tocharacter fields. Similar alterations tothe“where”
and“having” SQL clauses havebeen exposed, when theapplication does notrestrict
numeric data fornumeric fields.
Standard SQL error messages returned byadatabase canalso assist theattack er.
Insituations where theattack erhasnoknowledge oftheunderlying SQL query orthe
contrib uting tables, forcing anexception may revealmore details about thetable orits
field names andtypes. This technique hasbeen showntobequite effectiveinpractice
[5,27].
One solution totheproblem istoimpro veprogramming techniques. Common prac-
tices include escaping single quotes, limiting theinput character length, andfiltering
theexception messages. Despite these suggestions, vulnerabilities continue tosurface
inweb applications, implying theneed foradifferent approach. Another approach isto
usethePREP ARE statement feature supported bymanydatabases, which allowsaclient

topre-issue atemplate SQL query atthebeginning ofasession; fortheactual queries,
theclient only needs tospecify thevariables thatchange. Although thePREP ARE fea-
turewasintroduced asaperformance optimization, itcanaddress SQL injection attacks
ifthesame query isissued manytimes. When thequeries aredynamically constructed
(e.g.,asaresult ofapage with severaloptions thatuser may select), thisapproach does
notworkaswell.
[22] introduced theconcept ofinstruction-set randomization forsafeguarding sys-
tems against anytype ofcode-injection attack, bycreating process-specific randomized
instruction sets(e.g.,machine instructions) ofthesystem executing potentially vulner –
able softw are.Anattack erthatdoes notknowthekeytotherandomization algorithm
willinject code thatisinvalidforthatrandomized processor (and process), causing a
runtime exception.
Weapply thesame technique totheproblem ofSQL injection attacks: wecreate
randomized instances oftheSQL query language, byrandomizing thetemplate query
inside theCGI script andthedatabase parser .Toallowforeasy retrofitting ofoursolu-
tiontoexisting systems, weintroduce ade-randomizing proxy ,which convertsrandom-
ized queries toproper SQL queries forthedatabase. Code injected bytherogue client
evaluates toundefined keywords andexpressions. When thisistheoutcome, then stan-
dard keywords (e.g.,“or”) losetheir significance, andattacks arefrustrated before they
canevencommence. Theperformance overhead ofourapproach isminimal, adding up
to6.5mstoquery processing time.
Weexplain theintuition behind oursystem, namedSQLrand, inSection 2,and
describe ourprototype implementation inSection 3.Wegivesome performance results
inSection 4,andanovervie wofrelated workinSection 5.
2SQLrand SystemArchitecture
Injecting SQL code into aweb application requires little effortbythose who under –
stand both thesemantics oftheSQL language andCGI scripts. Numerous applica-
tions takeuser input andfeed itintoapre-defined query .Thequery isthen handed to
thedatabase forexecution. Unless developers properly design their application code
toprotect against unexpected data input byusers, alteration tothedatabase structure,
corruption ofdata orrevelation ofprivateandconfidential information may begranted
inadv ertently .
Forexample, consider alogin page ofaCGI application thatexpects auser-name
andthecorresponding passw ord.When thecredentials aresubmitted, theyareinserted
within aquery template such asthefollo wing:
"select *frommysql.user
whereusername=' ".$uid."'and
password=password(' ".$pwd."');"
Instead ofavaliduser-name, themalicious user setsthe$uid variable tothestring:
’or1=1; –’,causing theCGI script toissue thefollo wing SQL query tothedatabase:
"select *frommysql.user

Database Server
CGI
ScriptsDB
Middle−
ware
Result
SetResult
SetStandard
SQLRandomized
SQL
RequestsHTTPClientDatabase
ProxyWeb Server
Fig.1.SQLrand System Architecture
whereusername='' or1=1;–''and
password=password('_any_text_');"
Notice thatthesingle quotes balance thequotes inthepre-defined query ,andthe
double hyphen comments outtheremainder oftheSQL query .Therefore, thepassw ord
value isirrele vantandmay besettoanycharacter string. The result setofthequery
contains atleast onerecord, since the“where” clause evaluates totrue. Iftheapplication
identifies avaliduser bytesting whether theresult setisnon-empty ,theattack ercan
bypass thesecurity check.
Oursolution extends theapplication ofInstruction-Set Randomization [22] tothe
SQL language: theSQL standard keywords aremanipulated byappending arandom
integertothem, onethatanattack ercannot easily guess. Therefore, anymalicious user
attempting anSQL injection attack would bethwarted, fortheuser input inserted into
the“randomized” query would alwaysbeclassified asasetofnon-k eywords, resulting
inaninvalidexpression.
Essentially ,thestructured query language hastakenonnewkeywords thatwillnot
berecognized bythedatabase’ sSQL interpreter .Adifficult approach would betomod-
ifythedatabase’ sinterpreter toaccept thenewsetofkeywords. However,attempting to
change itsbeha viorwould beadaunting task. Furthermore, amodified database would
require allapplications submitting SQL queries toconform toitsnewlanguage. Al-
though dedicating thedatabase serverforselected applications might bepossible, the
random keywould notbevaried among theSQL applications using it.Ideally ,having
theability tovarytherandom SQL key,while maintaining onedatabase system, grants
agreater levelofsecurity ,bymaking itdifficult tosubvertmultiple applications by
successfully attacking theleast protected one.
Ourdesign consists ofaproxy thatsitsbetween theclient anddatabase server(see
Figure 1).Note thattheproxy may beonaseparate machine, unlik ethefigure’ sdepic-
tion.
Bymoving thede-randomization process outside theDataBase Management Sys-
tem(DBMS) totheproxy ,wegain inflexibility ,simplicity ,andsecurity .Multiple prox-
iesusing unique random keystodecode SQL commands canbelistening forconnec-
tions onbehalf ofthesame database, yetallowing disparate SQL applications tocom-
municate intheir own“tongue. ”Theinterpreter isnolonger bound totheinternals of

theDBMS. Theproxy’ sprimary obligation istodecipher therandom SQL query and
then forw ardtheSQL command with thestandard setofkeywords tothedatabase for
computation. Another benefit oftheproxy istheconcealment ofdatabase errors which
may unveiltherandom SQL keywordextension totheuser.Atypical attack consists of
asimple injection ofSQL, hoping thattheerror message willdisclose asubset ofthe
query ortable information, which may beused todeduce intuiti velyhidden properties
ofthedatabase. Bystripping awaytherandomization tags intheproxy ,weneed not
worry about theDBMS inadv ertently exposing such information through error mes-
sages; theDBMS itself neversees therandomization tags. Thus, toensure thesecurity
ofthescheme, weonly need toensure thatnomessages generated bytheproxy it-
selfareeversent totheDBMS orthefront-end server.Giventhattheproxy itself is
fairly simple, itseems possible tosecure itagainst attacks. Intheeventthattheproxy
iscompromised, thedatabase remains safe, assuming thatother security measures are
inplace.
Toassist thedeveloper inrandomizing hisSQL statements, weprovide atoolthat
reads anSQL statement(s) andrewrites allkeywords with therandom keyappended.
Forexample, intheClanguage, anSQL query ,which takesuser input, may look like
thefollo wing:
selectgender, avg(age)
fromcs101.students
wheredept=%d
groupbygender
Theutility willidentify thesixkeywords intheexample query andappend thekeyto
each one(e.g.,when thekeyis“123”):
select123 gender, avg123(age)
from123 cs101.students
where123 dept=%d
group123 by123gender
This SQL template query canbeinserted into thedeveloper’ sweb application. The
proxy ,upon recei ving therandomized SQL, translates andvalidates itbefore forw arding
ittothedatabase. Note that theproxy performs simple syntactic validation —itis
otherwise unawareofthesemantics ofthequery itself.
3Implementation
Todetermine thepracticality oftheapproach wejustoutlined, webuiltaproof-of-
concept proxy serverthat sitsbetween theclient (web server)andSQL server,de-
randomizes requests recei vedfrom theclient, andconveysthequery totheserver.Ifan
SQL injection attack hasoccurred, theproxy’ sparser willfailtorecognize therandom-
ized query andwillreject it.Thetwoprimary components were thede-randomization
element andthecommunication protocol between theclient anddatabase system. In
order tode-randomize theSQL query ,theproxy required amodified SQL parser that

expected thesuffixofintegers applied toallkeywords. Asa“middle man, ”ithadto
conceal itsidentity bymasquerading asthedatabase totheclient andvice versa. Al-
though ourimplementation focused onCGI scripts asthequery generators, asimilar
approach applies when using JDBC.
The randomized SQL parser utilized twopopular tools forwriting compilers and
parsers: flexandyacc. Capturing theencoded tokensrequired regular expressions that
matched each SQL keyword(case-insensiti ve)follo wedbyzero ormore digits. (Techni-
cally ,itdidnotrequire akey;practically ,itneeds one.) Ifproperly encoded, thelexical
analyzer strips thetoken’sextension andreturns ittothegrammar forreassembly with
therestofthequery .Otherwise, thetokenremains unaltered andislabeled asanidenti-
fier.Bydefault, flexreads asource file,butourdesign required anarray ofcharacters as
input. Tooverride thisbeha vior,theYYINPUT macro wasre-defined toretrie vetokens
from acharacter string introduced bytheproxy .During theparsing phase, anysyntax
error signals theimproper construction ofanSQL query using thepre-selected random
key.Either thedeveloper’ sSQL template isincorrect ortheuser’ sinput includes un-
expected data, whether good orbad. Onencountering this, theparser returns NULL;
otherwise, inthecase ofasuccessful parse, thede-randomized SQL string isreturned.
Theparser wasdesigned asaClibrary .
Withtheparser completed, thecommunication protocol hadtobeestablished be-
tween theproxy andadatabase. Weused MySQL, apopular andwidely used open-
source database system, tocreate afictitious customer database. Therecord sizeofthe
tables ranged from twenty toalittle more than eleventhousand records. These sample
tables were used intheevaluation ofbenchmark measurements described inSection 4.
The remaining piece involvedintegrating thedatabase’ scommunication mechanism
within theproxy .
Depending upon theclient’ slanguage ofchoice, MySQL provides manyAPIs toac-
cess thedatabase, yetthesame application protocol. Since theproxy willactasaclient
tothedatabase, theCAPI library wassuitable. One problem existed: themysqlclient
Clibrary does nothaveaserver-side counterpart foraccepting anddisassembling the
MySQL pack etssentusing theclient API. Therefore, theprotocol ofMySQL hadtobe
analyzed andincorporated intotheproxy .Unfortunately ,there wasnoofficial documen-
tation; however,arough sketch oftheprotocol existed which satisfied therequirements
ofthethree primary pack ets:thequery ,theerror ,andthedisconnect pack ets.
The query pack etcarries theactual request tothedatabase. The quit message is
necessary incases where theclient isabruptly disconnected from theproxy orsends an
invalidquery totheproxy .Ineither case theproxy gains theresponsibility ofdiscretely
disconnecting from thedatabase byissuing thequitcommand onbehalf oftheclient.
Finally ,theerror pack etisonly sent totheclient when animproper query generates a
syntax error ,thus indicating apossible injection attack.
Theclient application needs only todefine itsserverconnection toredirect itspack-
etsthrough theproxy rather than directly tothedatabase. Initsconnection method, this
isachie vedsimply bychanging theport number ofthedatabase totheport where the
proxy islistening. After recei ving aconnection, theproxy inturn establishes acon-
nection with thedatabase andhands offallmessages itrecei vesfrom theclient. Ifthe
command byte oftheMySQL pack etfrom theclient indicates thepack etcontains a

query ,theproxy extracts theSQL andpasses ittotheinterpreter fordecoding. When
unsuccessful, theproxy sends anerror pack etwith ageneric “syntax error” message
totheclient anddisconnects from thedatabase. Ontheother hand, asuccessful pars-
ingoftheSQL query produces atranslation tothede-randomized syntax. The proxy
overwrites theoriginal, randomized query with thestandard query thatthedatabase is
expecting intothebody oftheMySQL pack et.Thepack etsizeisupdated intheheader
andpushed outtothedatabase. Thenormal flowofpack etscontinues until theclient
requests another query .
The API libraries define some methods which will notworkwith theproxy ,as
theyhardcode theSQL query submitted tothedatabase. Forexample, mysql listdbs()
sends thequery “SHO Wdatabases LIKE<wild-card-input >”.Without modification to
theclient library ,theworkaround would betoconstruct thequery string with theproper
randomized keyandissue themysql query() method. Presently ,binary SQL cannot be
passed totheproxy forprocessing; therefore, mysql realquery() must beavoided.
4Evaluation
Toaddress thepracticality ofusing aproxy tode-randomize encoded SQL foradatabase,
twoobjecti veswere considered. First, theproxy must preventknownSQL injection vul-
nerabilities within anapplication. Second, theextraoverhead introduced bytheproxy
must beevaluated.
4.1QualitativeEvaluation
First, asample CGI application waswritten, which allowed auser toinject SQL into
a“where” clause that expected anaccount ID.Withnoinput validation, auser can
easily inject SQL toretrie veaccount information concerning allaccounts. When using
theSQLrand proxy ,theinjected statement isidentified andanerror message issued,
rather than proceeding with theprocessing ofthecorrupted SQL query .After testing
thereliability oftheproxy ona“home grown” example, thenextstep wastoidentify
anSQL injection vulnerability inapre-e xisting application.
Anopen-source bulletin board, phpBB v2.0.5, presented anopportunity toinject
SQL intoviewtopic.php, revealing thepassw ordofauser onebyte atatime. After the
attack wasreplicated inthetestenvironment, thesection ofvulnerable SQL wasran-
domized andtheconnection wasredirected through theproxy .Asexpected, theproxy
recognized theinjection asinvalidSQL code anddidnotsend ittothedatabase. The
phpBB application didnotsuccumb totheSQL injection attack asverified without the
proxy .However,itwasobserv edthattheapplication displays anSQL query totheuser
bydefaultwhen zero records arereturned. Since anexception does notreturn anyrows,
theproxy’ sencoding keywasrevealed. Again, therandomization method stillrequires
good coding practices. Ifadeveloper chooses torevealtheSQL under certain cases,
there islittle benefit totherandomization process. Ofcourse, onemust remember that
theapplication wasnotdesigned with theproxy implementation inmind.
Another content management application prone toSQL injection attacks, Php-Nuk e
depends onthemagic quotes gpcoption tobeturned ontoprotect against some of

them. Without thissetting, severalmodules areopen tosuch attacks. Evenwith the
option set,injections onnumeric fields arenotprotected because theapplication does
notcheck fornumeric input. Forexample, when attempting todownload content from
thephp-nuk eapplication, thedownload option dopissetto’getit’ andaccepts an
uncheck ed,numeric parameter name ’lid’.Itlooks uptheURL forthecontent from the
download table based onthelidvalueandsetsitintheHTTP location header statement.
Ifanattack erfinds aninvalidlid(determined byPHP-Nuk ereloading itshome page)
andappends ’union select pass from users table’ toit,thebrowser responds with an
error message stating thattheURL hadfailed toload, thus revealing thesensiti veinfor –
mation. However,when applying theproxy ,injection attacks intheaffected download
module were averted. These vulnerabilities areopen inother modules within PHP-Nuk e
thatwould also bequickly secured byusing theproxy .The same common injection
schemes arecited invarious applications.
4.2PerformanceEvaluation
Next,wequantified theoverhead imposed bySQLrand. Anexperiment wasdesigned
tomeasure theadditional processing time required bythree setsofconcurrent users,
respecti vely10,25,and50.Each class executed, inaround-robin fashion, asetoffive
queries concurrently over100trials. The average length ofthefivedifferent queries
was639bytes, andtherandom keylength wasthirty-tw obytes. Thesample customer
database created during theimplementation wasthetargetofthequeries. Thedatabase,
proxy ,andclient program were onseparatex86machines running RedHat Linux, within
thesame netw ork.Theoverhead ofproxy processing ranged from 183to316microsec-
onds for10to50concurrent users respecti vely.Table 1showstheproxy’ sperformance.
Table1.ProxyOverhead(inmicroseconds)
Users Min Max Mean Std
10 741300 183.5 126.9
25 732782 223.8 268.1
50 736533 316.6 548.8
Theworst-case scenario adds approximately 6.5milliseconds totheprocessing time
ofeach query .Since acceptable response times formost web applications usually fall
between afewseconds totens ofseconds, depending onthepurpose oftheapplica-
tion, theadditional processing time oftheproxy contrib utesinsignificant overhead ina
majority ofcases.
5RelatedWork
Todate, little attention hasbeen paid toSQL injection attacks. Theworkconceptually
closest toours isRISE [8],which applies arandomization technique similar toour

Instruction-Set Randomization [22] forbinary code only,anduses anemulator attached
tospecific processes. The inherent useofanddependenc yonemulation makesRISE
simultaneously more practical forimmediate useandinherently slowerintheabsence
ofhardw are.[26] uses more general code obfuscation techniques toharden program
binaries against static disassembly .
Inthegeneral area ofrandomization, originally proposed asawayofintroducing
diversity incomputer systems [16], notable systems include PointGuard andAddress
Obfuscation. PointGuard [11] encrypts allpointers while theyreside inmemory and
decrypts them only before theyareloaded toaCPU register .This isimplemented as
anextension totheGCC compiler ,which injects thenecessary instructions atcompila-
tiontime, allowing apure-softw areimplementation ofthescheme. Another approach,
address obfuscation [10], randomizes theabsolute locations ofallcode anddata, as
well asthedistances between different data items. Severaltransformations areused,
such asrandomizing thebase addresses ofmemory regions (stack, heap, dynamically-
linkedlibraries, routines, static data,etc.),permuting theorder ofvariables/routines,
andintroducing random gaps between objects (e.g.,randomly padstack frames ormal-
loc() ’edregions). Although veryeffectiveagainstjump-into-libc attacks, itislessso
against other common attacks, since theamount ofpossible randomization isrelati vely
small (especially when compared toourkeysizes). However,address obfuscation can
protect against attacks thataimtocorrupt variables orother data. This approach can
beeffectivelycombined with instruction randomization tooffercomprehensi veprotec-
tion against allmemory-corrupting attacks. [13] givesanovervie wofvarious protec-
tionmechanisms, including randomization techniques, andmakesrecommendations on
choosing obfuscation (ofinterf aceorimplementation) vs.restricting thesame.
[6]describes some design principles forsafeinterpreters, with afocus onJavaScript.
The Perl interpreter canberuninamode that implements some ofthese principles
(access toexternal interf aces, namespace management, etc.).While thisapproach can
some what mitigate theeffects ofanattack, itcannot altogether prevent,orevencontain
itincertain cases (e.g.,inthecase ofaPerl CGI script thatgenerates anSQL query to
theback-end database).
Increasingly ,source code analysis techniques arebrought tobear ontheproblem
ofdetecting potential code vulnerabilities. Themost simple approach hasbeen thatof
thecompiler warning ontheuseofcertain unsafe functions, e.g.,gets().More recent
approaches [17,35,23,34,15]havefocused ondetecting specific types ofproblems,
rather than trytosolvethegeneral “bad code” issue, with considerable success. While
such tools cangreatly help programmers ensure thesafety oftheir code, especially
when used inconjunction with other protection techniques, they(aswell asdynamic
analysis tools such as[25,24]) offerincomplete protection, astheycanonly protect
against anddetectknown classes ofattacks andvulnerabilities. Unfortunately ,none of
these systems havebeen applied tothecase ofSQL injection attacks.
Process sandboxing [31] isperhaps thebestunderstood andwidely researched area
ofcontaining badcode (oritseffects), asevidenced bytheplethora ofavailable systems
likeJanus [21], Consh [4],Mapbox [2],OpenBSD’ ssystrace[33], andtheMediating
Connectors [7].These operate atuser levelandconfine applications byfiltering access
tosystem calls. Toaccomplish this, theyrelyonptrace(2) ,the/procfilesystem, and/or

special shared libraries. Another category ofsystems, such asTron[9],SubDomain
[12] andothers [18,20,36,30,37,28,32],goastepfurther .Theyintercept system calls
inside thekernel, andusepolic yengines todecide whether topermit thecallornot.
Themain problem with allthese isthattheattack isnotprevented: rather ,thesystem
tries tolimit thedamage such code cando,such asobtain super -user privileges. In
theconte xtofaweb server,thismeans thataweb servermay only beable toissue
queries toparticular databases oraccess alimited setoffiles,etc.[19] identifies several
common security-related problems with such systems, such astheir susceptibility to
various types ofrace conditions.
6Conclusions
Wepresented SQLrand, asystem forpreventing SQL injection attacks against web
servers.Themain intuition isthatbyusing arandomized SQL query language, specific
toaparticular CGI application, itispossible todetect andabort queries thatinclude in-
jected code. Byusing aproxy forthede-randomization process, weachie veportability
andsecurity gains: thesame proxy canbeused with various DBMS back-end, andit
canensure thatnoinformation thatwould expose therandomization process canleak
from thedatabase itself. Naturally ,care must betakenbytheCGI implementor toavoid
exposing randomized queries (asisoccasionally done inthecase oferrors). Weshowed
thatthisapproach does notsacrifice performance: thelatenc yoverhead imposed oneach
query wasatmost 6.5milliseconds.
Webelie vethatSQLrand isaverypractical system thatsolvesaproblem heretofore
ignored, inpreference tothemore “high profile” bufferoverflowattacks. Our plans
forfuture workinclude developing tools thatwillfurther assist programmers inusing
SQLrand andextending coverage toother DBMS back-ends.
References
1.CER TVulnerability Note VU#282403. http://www.kb.cert.org/vuls/id/
282403 ,September 2002.
2.A.Acharya andM.Raje. Mapbox: Using parameterized behaviorclasses toconfine applica-
tions. InProceedings ofthe9thUSENIXSecuritySymposium ,pages 1–17, August 2000.
3.Aleph One. Smashing thestack forfunandprofit.Phrack,7(49), 1996.
4.A.Alexandro v,P.Kmiec, andK.Schauser .Consh: Aconfined execution environment for
internet computations, December 1998.
5.C.Anle y.Advanced SQL Injection InSQL ServerApplications. http://www.
nextgenss.com/papers/advanced\_sql\_inj ection.pdf ,2002.
6.V.Anupam andA.Mayer .Security ofWebBrowser Scripting Languages: Vulnerabilities,
Attacks, andRemedies. InProceedings ofthe7thUSENIXSecuritySymposium ,pages 187–
200, January 1998.
7.R.Balzer andN.Goldman. Mediating connectors: Anon-bypassable process wrapping tech-
nology .InProceeding ofthe19thIEEEInternational ConferenceonDistributedComputing
Systems ,June 1999.
8.E.G.Barrantes, D.H.Ackle y,S.Forrest, T.S.Palmer ,D.Stefanovic,andD.D.Zovi.Ran-
domized Instruction SetEmulation toDisrupt Binary Code Injection Attacks. InProceedings

ofthe10thACMConferenceonComputer andCommunications Security(CCS) ,pages 281–
289, October 2003.
9.A.Berman, V.Bourassa, andE.Selber g.TRON: Process-Specific File Protection forthe
UNIX Operating System. InProceedings oftheUSENIX TechnicalConference,January
1995.
10.S.Bhatkar ,D.C.DuVarney,andR.Sekar .Address Obfuscation: anEfficient Approach to
Combat aBroad Range ofMemory Error Exploits. InProceedings ofthe12thUSENIX
SecuritySymposium ,pages 105–120, August 2003.
11.C.Cowan,S.Beattie, J.Johansen, andP.Wagle. PointGuard: Protecting Pointers From
BufferOverflowVulnerabilities. InProceedings ofthe12thUSENIXSecuritySymposium ,
pages 91–104, August 2003.
12.C.Cowan,S.Beattie, C.Pu,P.Wagle, andV.Gligor .SubDomain: Parsimonious Security for
ServerAppliances. InProceedings ofthe14thUSENIXSystemAdministr ationConference
(LISA2000) ,March 2000.
13.C.Cowan,H.Hinton, C.Pu,andJ.Walpole. The Crack erPatch Choice: AnAnalysis of
Post Hoc Security Techniques. InProceedings oftheNationalInformation SystemsSecurity
Conference(NISSC) ,October 2000.
14.C.Cowan,C.Pu,D.Maier ,H.Hinton, J.Walpole, P.Bakk e,S.Beattie, A.Grier ,P.Wagle,
andQ.Zhang. Stackguard: Automatic adapti vedetection andprevention ofbuffer-overflow
attacks. InProceedings ofthe7thUSENIXSecuritySymposium ,Jan.1998.
15.N.Dor,M.Rodeh, andM.Sagiv.CSSV :Towards arealistic toolforstatically detecting all
bufferoverflowsinC.InProceedings oftheACMConferenceonProgrammingLanguage
DesignandImplementation (PLDI) ,June 2003.
16.S.Forrest, A.Somayaji, andD.Ackle y.Building DiverseComputer Systems. InHotOS-VI ,
1997.
17.J.Foster ,M.Fa¨hndrich, andA.Aiken.Atheory oftype qualifiers. InProceedings ofthe
ACMSIGPLAN ConferenceonProgrammingLanguageDesignandImplementation (PLDI) ,
May 1999.
18.T.Fraser ,L.Badger ,andM.Feldman. Hardening COTSSoftw arewith Generic Softw are
Wrappers. InProceedings oftheIEEESymposium onSecurityandPrivacy ,Oakland, CA,
May 1999.
19.T.Garfink el.Traps andPitfalls: Practical Problems inSystem Call Interposition Based Se-
curity Tools. InProceedings oftheSymposium onNetworkandDistributedSystemsSecurity
(SNDSS) ,pages 163–176, February 2003.
20.D.P.Ghormle y,D.Petrou, S.H.Rodrigues, andT.E.Anderson. SLIC: AnExtensibility
System forCommodity Operating Systems. InProceedings ofthe1998USENIX Annual
TechnicalConference,pages 39–52, June 1998.
21.I.Goldber g,D.Wagner ,R.Thomas, andE.A.Brewer.ASecure Environment forUntrusted
Helper Applications. InProcedings ofthe1996USENIX AnnualTechnicalConference,
1996.
22.G.S.Kc,A.D.Keromytis, andV.Prevelakis. Countering Code-Injection Attacks With
Instruction-Set Randomization. InProceedings oftheACMComputer andCommunications
Security(CCS)Conference,pages 272–280, October 2003.
23.D.Larochelle andD.Evans. Statically Detecting LikelyBufferOverflowVulnerabilities. In
Proceedings ofthe10thUSENIXSecuritySymposium ,pages 177–190, August 2001.
24.E.Larson andT.Austin. High Coverage Detection ofInput-Related Security Faults. In
Proceedings ofthe12thUSENIXSecuritySymposium ,pages 121–136, August 2003.
25.K.Lhee andS.J.Chapin. Type-assisted dynamic bufferoverflowdetection. InProceedings
ofthe11thUSENIXSecuritySymposium ,pages 81–90, August 2002.

26.C.Linn andS.Debray .Obfuscation ofExecutable Code toImpro veResistance toStatic Dis-
assembly .InProceedings ofthe10thACMConferenceonComputer andCommunications
Security(CCS) ,pages 290–299, October 2003.
27.D.Litchfield. WebApplication Disassembly wthODBC Error Messages. http://www.
nextgenss.com/papers/webappdis.doc .
28.P.Loscocco andS.Smalle y.Integrating Flexible Support forSecurity Policies intotheLinux
Operating System. InProceedings oftheUSENIX AnnualTechnicalConference,Freenix
Track,pages 29–40, June 2001.
29.M.Cono verandw00w00 Security Team. w00w00 onheap overflows.http://www.
w00w00.org/files/articles/heaptut.txt ,January 1999.
30.T.Mitchem, R.Lu,andR.O’Brien. Using Kernel Hypervisors toSecure Applications. In
Proceedings oftheAnnualComputer SecurityApplications Conference,December 1997.
31.D.S.Peterson, M.Bishop, andR.Pandey.AFlexible Containment Mechanism forExecuting
Untrusted Code. InProceedings ofthe11thUSENIXSecuritySymposium ,pages 207–225,
August 2002.
32.V.Prevelakis andD.Spinellis. Sandboxing Applications. InProceedings oftheUSENIX
TechnicalAnnualConference,FreenixTrack,pages 119–126, June 2001.
33.N.Provos.Impro ving Host Security with System Call Policies. InProceedings ofthe12th
USENIXSecuritySymposium ,pages 257–272, August 2003.
34.U.Shankar ,K.Talwar,J.S.Foster ,andD.Wagner .Detecting Format String Vulnerabilities
with TypeQualifiers. InProceedings ofthe10thUSENIXSecuritySymposium ,pages 201–
216, August 2001.
35.D.Wagner ,J.S.Foster ,E.A.Brewer,andA.Aiken. AFirst Step towards Automated
Detection ofBufferOverrun Vulnerabilities. InProceedings oftheISOCSymposium on
NetworkandDistributedSystemSecurity(SNDSS) ,pages 3–17, February 2000.
36.K.M.Walker,D.F.Stern, L.Badger ,K.A.Oosendorp, M.J.Petkac, andD.L.Sherman.
Confining rootprograms with domain andtype enforcement. InProceedings oftheUSENIX
SecuritySymposium ,pages 21–36, July 1996.
37.R.N.M.Watson. TrustedBSD: Adding Trusted Operating System Features toFreeBSD. In
Proceedings oftheUSENIXAnnualTechnicalConference,FreenixTrack,pages 15–28, June
2001.