UniSan:ProactiveKernelMemoryInitializationto
EliminateDataLeakages
Kangjie Lu,Chengyu Song,Taesoo Kim,Wenke Lee
SchoolofComputerScience,GeorgiaTech
AnyProblemHere?/*File:drivers/usb/core/devio.c*//*definedatastructure“usbdevfs_connectinfo”*/struct usbdevfs_connectinfo {unsigned int devnum;unsigned char slow;
};
/*createandinitializeobject“ci”struct usbdevfs_connectinfo ci={.devnum=ps->dev->devnum,.slow=ps->dev->speed==USB_SPEED_LOW
};/*copy“ci”touserspace*/copy_to_user(arg,&ci,sizeof(ci));
3-bytepadding
Informationleak!
SecurityMechanismsinOSKernelskASLR:Randomizingtheaddressofcode/data
– Preventingcode-reuseandprivilegeescalationattacks
StackGuard:Insertingrandomcanaryinstack– Preventingstackcorruption-basedattacks
Code/data
Memory
Code/data
Memory
Code/data
Memory
1st boot 2nd boot 3rd boot
?
n boot…
Randomcanary
TheAssumptionofEffectiveness
Assumption:Noinformationleak
Randomizedaddress
Memory
Asingleinformationleakrendersthesesecuritymechanismsineffective!
kASLR
StackGuard
Infoleak intheOS(Linux)Kernel
AccordingtotheCVEdatabase
0
20
40
60
2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016
#ofreportedInfoleakbugsintheLinuxkernelNumber
ThesesecuritymechanismsareoftenbypassedinrealitySensitivedata(e.g.,cryptographickeys)canalsobeleaked.
OurresearchaimstoeliminateinformationleaksinOSkernels
CausesofInfoleaks• Uninitializeddataread:Readingdatabeforeinitialization,whichmaycontainunclearedsensitivedata
• Out-of-boundread:Readingacrossobjectboundaries
• Use-after-free:Usingfreedpointer/sizethatcanbeattackercontrolled
• Others:Missingpermissioncheck,racecondition
CausesofInfoleaks (cont.)Infoleak CausesintheLinuxKernel(since2013)
Uninitializeddataread
Out-of-bound anduse-after-freeread
Others(e.g.,logicerror)
OOBandUAFread(29.1%)
Others(13.6%)
Uninitializeddataread(57.3%)
Ourfocus
Similarly,Chenetal.[APSys’11]showed76%infoleaks (Jan.2010-Mar.2011)arecausedbyuninitializeddatareads
Memorysafety
Modelchecking,etc.
FromUninitializedDataReadtoLeak1. Deallocatedmemoryisnotclearedbydefault.2. Allocatedmemoryisnotinitializedbydefault.3. Readingtheuninitializedmemory->leak.
sensitive
UserAallocatesobjectAand
writes“sensitive”intoit
Memory
ObjectA
UserAdeallocatesobjectA;
“sensitive”isnotcleared
UserBallocatesobjectBwithoutInitialization;“sensitive”kept
UserBreadsObjectB;“sensitive”leaked!
1 2 3 4
sensitive sensitive
ObjectB ObjectB
sensitive
Memory Memory
Troublemaker:Developer
Missingelementinitialization:Blamethedeveloper.J
Difficulttoavoid,e.g.,–Datastructuredefinitionandobjectinitializationmaybeimplementedbydifferentdevelopers
Troublemaker:CompilerDatastructurepadding:AfundamentalfeatureimprovingCPUefficiency
/*bothfields(5bytes)areinitialized*/struct usbdevfs_connectinfo ci={.devnum =ps->dev->devnum,.slow=ps->dev->speed ==
USB_SPEED_LOW};/*leaking3-byteuninitializedpadding
sizeof(ci)=8 */copy_to_user(arg,&ci,sizeof(ci));
struct usbdevfs_connectinfo {unsigned int devnum;unsigned char slow;/*3-bytespadding*/
};
CSpecifications(C11)
Chapter§6.2.6.1/6
“Whenavalueisstoredinanobjectofstructureoruniontype,includinginamemberobject,thebytesoftheobjectrepresentationthatcorrespondtoanypaddingbytestakeunspecifiedvalues.”
ResponsesfromtheLinuxCommunity
Doubted
ConfirmedKees Cook:
WillyTarreau:
BlamedGCC
Agreedsolution
LinusTorvalds:
BenHutchings:
Detecting/PreventingUninitializedDataLeaks
The-Wuninitialized optionofcompilers?Simplyinitializeallallocations?
OurUniSan approach:1) Conservativelyidentifyunsafeallocations
(i.e.,withpotentialleaks)viastaticprogramanalysis
2) Instrumentthecodetoinitializeonlyunsafeallocations
DetectingUnsafeAllocations
Integratingbyte-levelandflow-,context-,andfield-sensitivereachabilityandinitializationanalyses
Sources(i.e.,
allocations)
Sinks(e.g.,
copy_to_user)Dataflow
Reachabilityanalysis
Initializationanalysis
MainChallengesinUniSan• Sinkdefinition–Generalrules
• Globalcall-graphconstruction– Typeanalysisforindirectcalls
• Byte-leveltracking–Offset-basedanalysis,“GetElementPtr”
Beconservative!Assumeitisunsafeforspecialcases!
Instrumentation
Zero-initializationsforunsafeallocations:–Stack: Assigningzeroorusingmemset–Heap: Addingthe__GFP_ZEROflagtokmalloc
Instrumentationsaresemanticpreserving–Robust–Tolerantoffalsepositives
Implementation• UsingLLVM–Ananalysispassandaninstrumentationpass
• Makingkernelscompilable withLLVM– PatchesfromtheLLVMLinux projectandKenali [NDSS’16]
• Optimizinganalysis–Modelingbasicfunctions
HowtouseUniSan: $unisan @bitcode.list
EvaluationEvaluationgoals–Accuracyinidentifyingunsafeallocations– Effectivenessinpreventinguninitializeddataleaks– Theefficiencyofthesecuredkernels
Platforms– LatestmainlineLinuxkernelforx86_64– LatestAndroidkernelforAArch64
EvaluationofAccuracy
Statisticsofvariousnumbers:–Only10% ofallocationsaredetectedasunsafe.
Arch Module Alloca Malloc UnsafeAlloca
UnsafeMalloc
Percent
X86_64 2,152 17,878 2,929 1,493 386 9.0%AArch64 2,030 15,628 3,023 1,485 451 10.3%
EvaluationofEffectiveness
Preventingknownleaks:–Selected43recentleakswithCVE#–UniSanpreventedallofthem
Detectingunknownleaks–Withmanualverification
ConfirmedNewInfoleaks (Selected)File Object Leak
BytesCause CVE
rtnetlink.c map 4 Pad CVE-2016-4486devio.c ci 3 Pad CVE-2016-4482af_llc.c info 1 Pad CVE-2016-4485timer.c tread 8 Pad CVE-2016-4569timer.c r1 8 Pad CVE-2016-4578netlink...c link_info 60 Dev. CVE-2016-5243media-device.c
u_ent 192 P&D AndroidID-28616963
more… more… … … more…
EvaluationofEfficiencyRuntimeoverhead(geo-mean%)
Analysestookless3minutes.Binarysizeincreased<0.5%.
Category Benchmarks BlindMode(x86_64)
UniSan(x86_64)
Systemoperations
LMBench 4.74% 1.36%
Serverprograms
ApacheBench 0.8% <0.1%
Userprograms
SPEC Bench 1.92% 0.54%
LimitationsandFutureWork
• Customheapallocators–Requireannotations
• Close-sourcedmodules–Notsupported
• Otheruninitializeduses,e.g.,uninitializedpointerdereference
• GCCsupport(inprogress)
Conclusions
• InformationleaksarecommoninOSkernels.• Uninitializedreadisthedominantcause.• Developersarenotalwaystoblame—compilersmayalsointroducesecurityproblems.• UniSaneliminatesalluninitializeddataleaks.
TryUniSan:https://github.com/sslab-gatech/unisan
Top Related