Towards Automated Application-Specific Software Stacks

Abstract

Soft­ware com­ple­xi­ty has in­crea­sed over the years. One com­mon way to tack­le this com­ple­xi­ty du­ring de­ve­lop­ment is to en­cap­su­la­te fea­tures into a shared li­b­ra­ry. This al­lows de­ve­lo­pers to reuse al­re­a­dy im­ple­men­ted fea­tures in­s­tead of re­imple­men­ting them over and over again. Howe­ver, not all fea­tures pro­vi­ded by a shared li­b­ra­ry are ac­tual­ly used by an ap­p­li­ca­ti­on. As a re­sult, an ap­p­li­ca­ti­on using shared li­b­ra­ries loads unu­sed code into me­mo­ry, which an at­ta­cker can use to per­form code-reu­se and si­mi­lar types of at­tacks. The same holds for ap­p­li­ca­ti­ons writ­ten in a script­ing lan­gua­ge such as PHP or Ruby: The in­ter­pre­ter ty­pi­cal­ly of­fers much more func­tio­na­li­ty than is ac­tual­ly re­qui­red by the ap­p­li­ca­ti­on and hence pro­vi­des a lar­ger over­all at­tack sur­face.

In this paper, we tack­le this pro­blem and pro­po­se a first step towards au­to­ma­ted ap­p­li­ca­ti­on-spe­ci­fic soft­ware stacks. We pre­sent a com­pi­ler ex­ten­si­on ca­pa­ble of re­mo­ving un­nee­ded code from shared li­b­ra­ries and—with the help of do­main know­ledge—also ca­pa­ble of re­mo­ving unu­sed func­tio­na­li­ties from an in­ter­pre­ter's code base du­ring the com­pi­la­ti­on pro­cess. Our eva­lua­ti­on against a di­ver­se set of re­al-world ap­p­li­ca­ti­ons, among others Nginx, Lightt­pd, and the PHP in­ter­pre­ter, re­mo­ves on aver­a­ge 71.3% of the code in musl-libc, a po­pu­lar libc im­ple­men­ta­ti­on. The eva­lua­ti­on on web ap­p­li­ca­ti­ons show that a tailo­red PHP in­ter­pre­ter can miti­ga­te en­t­i­re vul­nerabi­li­ty clas­ses, as is the case for Open­Conf. We de­mons­tra­te the ap­p­lica­bi­li­ty of our de­bloa­ting ap­proach by crea­ting an ap­p­li­ca­ti­on-spe­ci­fic soft­ware stack for a Word­press web ap­p­li­ca­ti­on: we tailor the libc li­b­ra­ry to the Nginx web ser­ver and PHP in­ter­pre­ter, whe­re­as the PHP in­ter­pre­ter is tailo­red to the Word­press web ap­p­li­ca­ti­on. In this re­al-world sce­na­rio, the code of the libc is de­crea­sed by 65.1% in total, the­re­by re­du­cing the avail­able code for code-reu­se at­tacks.