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%

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