Using Programmer-Written Compiler Extensions to Catch Security HolesOutlineMotivation (1)Motivation (2)Example: Range Checker (1)Range Check (2)Range Check (3)Range Check (4)Implementation (1)Implementation (2)Implementation (3)AdvantagesAbout the checkerBelief InferenceDriving Untrustworthy SourcesDeriving Trusting SinksNetwork DataAnalysis – Transitive TaintingAnalysis – Inter-procedural Analysis (1)Analysis – Inter-procedural Analysis (2)Analysis – False PositivesAnalysis – False NegativesEnforcing Obscure Rules (1)Enforcing Obscure Rules (2)Evaluation (1) – Errors OverviewEvaluation (2) – Errors OverviewEvaluation (3) – Results ValidationDiscussion (1)Discussion (2)Slide 30ReferenceUsing Programmer-Written Compiler Extensions to Catch Security HolesAuthors: Ken Ashcraft and Dawson EnglerPresented by : Hong ChenCS590F2/7/2007OutlineMotivationExample: Range CheckerSolution DetailsBelief InferenceAnalysis IssuesEnforcing Obscure RulesEvaluationDiscussionMotivation (1)ProblemFind security holes (security rules violation) in source code of system softwareSecurity rulesSanitize untrusted input before using itDo not release sensitive data to unauthorized usersObservationMany rules are poorly understood and erratically obeyedApproachUse static analysis to check if security rules are obeyedMotivation (2)Program analysis: Intuition ToolSecurity rulesDomain specificSystem specificHigh-levelMetacompilationMake it easy for programmer to add rulesExample: Range Checker (1)Security ruleIntegers supplied by untrustworthy sources should be range-checked before used for dangerous operationsRange Check (2)Checker needs to identifyUntrustworthy sources that generate dataChecks must be done to sanitize the dataTrusting sinks that must be protectedUntrustworthy sourcesSystem calls (sys_*)Routines copy data from user space (copy_from_user, copyin) Data from networkRange Check (3)Sanitizing dataSigned integers: lower and upper boundUnsigned integers: upper bound checkTricky: integer overflowRange Check (4)Trusting sinksArray indexLoop boundCopying/allocation routinesPotentially 3 x 3 x 3 = 27 types of security holes!Implementation (1)Implementation (2)State machine representationMetal: high-level, state-machine languageCompilation extension linked to xgcc States can be global or bound to expressionsHow it works?“After xgcc translates each input function into its internal representation, the checker is applied down every possible execution path in that function”Implementation (3)AdvantagesPropagate the knowledge of one programmer to manySecurity rules are subtleFind difficult-to-observe errorsCatch error without running codeMany errors are found in the driversLightweightAbout the checkerAd hoc knowledge (security rules)Effective (range checker finds 100+ errors in Linux)False negativeFalse positiveBelief InferenceTraditional checkers:Hardwired knowledgeMC:Use code behavior to infer checking properties InferenceUntrustworthy sourcesTrusting sinksNetwork DataDriving Untrustworthy SourcesChallengesThere are many untrustworthy sourcesDifficult to analyzeUse inferenceUntrustworthy input is often used in stylized waysDeriving Trusting SinksNormal checking sequence(1) OS reads data from unsafe source(2) Check the data(3) Pass it to a trusting sinkWhat if (3) is missing?Something may be wrong…Network DataChallengeNetwork data is not trustworthysk_buff holds network dataIncoming or outgoing?CandidatesIf the fields were read more often than written, the structure is incomingIf the checker sees the allocation of the structure, it’s outgoingAnalysis – Transitive TaintingAllow tainted variables to transitively taint other variablesAnalysis – Inter-procedural Analysis (1)The user only provides the “base” unsafe sources and trusting sinksAutomatically compute all procedures that transitively produces or consumes dataTwo-pass processFirst pass: Emit a call graph, compute the transitive set of functions, store calculated sources and sinks in text filesSecond pass: at call sites, taint variable / report errorsSpecial case: function pointersAnalysis – Inter-procedural Analysis (2)Analysis – False PositivesChecker designFirst write simple checkersEliminating false positivesCommon false positives“Fancy” bound checksTaint granularitySubroutine checks boundsAnalysis – False NegativesFirst of all, false negatives are expected…Potential improvementsComparison with correct valueOther information flow channel (tainted value stored in data structure)Info lost during inter-procedure analysisOnly local inferenceEnforcing Obscure Rules (1)The length-field copy attackSigned integer must be lower and upper bound checkedEnforcing Obscure Rules (2)Integer overflowFixed size arithmeticEvaluation (1) – Errors OverviewSevere erros as common as minor onesEvaluation (2) – Errors OverviewMost bugs are localLow false positive rateEvaluation (3) – Results ValidationLinux (2.4.5 – 2.4.12)Post errors to Linux KernelCount unique errorsMany resulted in kernel patchFalse result – kernel developers will explain whyMinor bugs – may introduce possibility of new bugsOpenBSD (2.9)Submitted to a local BSD hackerAll errors resulted in kernel patchesTotal kernel patches 50+Discussion (1)Core techniquesStatic analysis – State Machine model, although implementation details are not given (see details)Make ad hoc knowledge powerfulBelief inference (save effort to specify everything)Extract information from source code presentationDiscussion (2)How to do better?Static analysis (other models/tools?)Finding errors (combine with dynamic analysis?)Other applicationsFinding bugs (past work)…Thank you ReferenceUsing Programmer-Written Compiler Extensions to Catch Security HolesKen Ashcraft and Dawson Engler In Proceeding of IEEE Security and Privacy
View Full Document
Unlocking...