Increased security through open source

Increased securit y through op en source ∗ Jaap-Henk Ho epman, Bart Jacobs Securit y of Systems (SoS) group Institute for Computing and Information Sciences Radb oud Univ ersit y Nijmegen P .O. Bo x 9010, 6500 GL Nijmegen, the Netherlands { jhh,bart } @cs. ru.nl August 23, 2021 1 In tro duction The last few y ears hav e sho wn a w orldwide rise in the atten tion for, and actual use of, op en source soft w are (OSS ), most notably of th e op erating system Lin ux and v arious applications ru n ning on top of it. V arious ma jor companies and go v ernmen ts are adopting OSS. As a result, there a re many publications concerning its adv an tage s and disadv a nta ges. The ongoing dis- cussions co ver a wide ran ge of topics, suc h as Windows versus Linux, cost issues, in tellect ual prop ert y righ ts, dev elopment metho ds, etc. Here w e wish to fo cus on security issues surroun ding O S S. It h as b ecome a reasonably w ell-established con viction within the compu ter securit y comm unit y that publishin g designs and p r otocols con tributes to the securit y of systems built on them. But s hould one go all the wa y and publish source co de as well? That is the fundamen tal question that w e wish to address in th is pap er. The follo wing analo gies may help to introd uce the issues and con trov er- sies surroun ding the op en source deb ate. • W ould yo u, while tra v elling far from home, tak e medicines of an un- kno wn b rand giv en to y ou by a self-pro claimed “do ctor”, without do c- ument ation, and hence withou t (ind ep enden t) assurance ab out the nature and prop er w orking of the ingredien ts? • Who wo uld you trust most? A lo c ksmith who keeps the working of his lo c ks secret, so that thieves cannot exp loit this kn owledge? Or a lo c ksmith who publishes the w orkings of his lo c ks, so that ev ery one (in - cluding thiev es) ca n jud ge ho w goo d/bad they are (so y ou excl usively rely on the complexit y of the k eys for protection)? ∗ Id: oss-acm.tex,v 1.16 2005/04/26 17:44:29 jhh Exp 1 In the remainder of this pap er w e will d iscuss the impact of op en sour ce on b oth the secur it y and transparency of a soft w are system. W e fo cus on the more tec hnical asp ects of this issu e (and refer to Glass [ 4 ] for a d iscussion of the economica l persp ectiv e of op en source), com bining and extending argumen ts deve lop ed o ve r the y ears [ 12 ]. W e stress that our discussion of the problem only applies to soft w are for general p urp ose computing sys tems. F or em b edded systems, where the soft w are us u ally cannot easily b e patc hed or upgraded, differen t considerations ma y apply . 1.1 Securit y through obscurity: d esign vs. implemen tation Through the centuries, secrecy w as the p r edominan t method olog y su rround- ing the design of an y secure system. Securit y of military communicat ion sys- tems, for example, w as mostly based on the f act that only few p eople knew ho w it work ed, and not on an y inherentl y secure m ethod of comm unication. Ciphers in those da ys w ere v ery insecure. In 1883, Auguste Kerc khoffs [ 5 ] extensivel y argued that an y secure m il- itary sy s tem ”... must not require secrecy and can b e stolen b y the enemy without causing trouble”. In th e academic securit y comm unity Kerc khoffs’ Principle is widely supp orted: in the design of a system, se curity thr ough obscurity is considered bad practice, for many reasons s im ilar to the ones we will discuss later on. This p oint is starting to get across to industry as w ell, witnessed b y the f act th at, for instance, the security of the third genera- tion of cellular telephone net w orks (UMTS) is based on op en and p ublished standards. In Kerckhoffs’ da ys there wa s hardly an y difference b etw een the design of a system and its actual implementatio n . T hese days, ho wev er, th e d ifference is h uge: system d esigns are already v ery complex, and their implemen tation is hard to get completely r igh t. The qu estion then arises whether Kerc khoffs’ Principle applies only to the design of a system, or also to its implementa tion. In other w ords, should secure systems also b e op en source, or not? There is n o agreemen t on the answer to this question ev en in the aca- demic comm unit y [ 1 ]. According to us, the answ er is: ”absolutely!”. In the remainder of this pap er we will argue why . 1.2 Securit y , risk and exp osure When discussing whether op en source m akes systems more secure, we ha v e to b e precise ab out what w e mean by that. In fact, for th e pur p ose of this d iscussion we need to distinguish b et w een th e se curity of a system, the exp o sur e of that sys tem, and th e risk asso ciate d with usin g that system. W e define these terms next. The ultimate d ecisiv e factor that determines whether a sy s tem is “secure enough” is the risk asso ciated w ith using that s ystem. This risk is defin ed as 2 a com bination of the likeli ho o d of a successful attac k on a system together with the damage to th e assets resulting fr om it. The exp osur e of a system completely ignores the damage that is incurred b y a successful atta c k, and is defined as just the lik eliho o d of a su ccessful attac k. This d ep ends on sev eral factors, like the num b er and sev erit y of vul- nerabilities in the system, bu t also whether these vulnerabilities are known to attac k ers, ho w hard it is to exploit suc h a vuln erabilit y , and whether th e system is a high-profile target or n ot. Finally , w e consid er the se cu rity of a system to b e an ob jectiv e measur e of the n umber of its vu lnerabilities and their severit y (i.e., the p rivileges obtained b y exploiting the vulnerabilit y). T o summ arise, exp osure com bines securit y with the lik eliho o d of attac k, and risk com bin es exp osure with th e d amage s ustained by the atta ck. W e note that in other pap ers on this and similar topics, securit y h as b een used to mean either security prop er, exp osure or risk as defined ab ov e. With these definitions in place, w e see that op ening the source clearly do es not c hange the securit y of a system (simply b ecause it do esn’t introdu ce new bugs), while the exp osure is lik ely to increase in the short term (b ecause it mak es the existing bugs more visible). The question is what happ ens to the securit y and the exp osure of an op en sou r ce system in the long run. 1.3 Op en vs. c losed source The increased atten tion paid to op en source in the media and by so ciet y at large has made op en source an almost catc h -all ph rase. Here, w e use it in its original, rather sp ecific, meaning. Op en s ource soft ware is soft w are for whic h the corresp onding sour ce (and all relev ant do cumenta tion) is a v ailable for insp ection, use, mo dification and redistribution by the user 1 . W e do not d istinguish b et wee n any kin d of dev elopmen t metho dology (e.g., the Cathedral or the Bazaar[ 10 ]). Neither do we care ab out the p ricing mo del (freew are, sharew are, etc. ). W e do assume how ev er that users (in principle) are allo wed and able to reb uild th e s ystem from the (mo d ified) s ou r ces, and that they ha ve access to the p r op er to ols to do so. In some cases, allo wing the u s er to redistribute the mo d ified sou r ces (in full, or through patc h es) is also necessary (e.g., F ree S oftw are an d the GNU Pu blic License 2 ). Most of our argumen ts also hold for sour c e available soft w are, where the license do es not allo w r edistribution of th e (mo dified) source. 1 See http://www .opensource.org / . 2 http://www .gnu.org/copyle ft/gpl.html 3 2 Op en source necessary for securit y W e b eliev e that using op en source softw are is a necessary requirement to build systems that are more secure. Ou r main argument is that op ening the source allo ws indep end en t assessment of th e exp osu re of a system and the risk asso ciated with using the system, m ak es p atc hing bugs easier and more lik ely , and forces soft wa re d evelo p ers to sp end more effort on the qualit y of their code. The remainder of this pap er is dev oted to arguing our case in detail. W e will fir st review argument s in fav our of k eeping the source closed, and then discuss reasons why op en sour ce d oes (in the long ru n) increase securit y . As n oted in the in tro duction, there is a d istinctio n b et ween making the design of a system public and also m aking its implemen tation public. W e fo cus on the latter case, bu t note th at most (but n ot all) of these argumen ts also apply to th e question whether th e d esign sh ould b e op en or not. 2.1 Keep t he source closed: argumen ts against op en source First of all, k eeping the sour ce closed preve nts the attac ker from h a ving easy access to in formation that ma y b e helpfu l to successfully launc h an attac k [ 2 ]. Op ening the source gives the attac k er a wea lth of information to searc h f or vuln er ab ilities and/or bugs, like p otent ial buffer o v erflows, and th us increases the exp osure of the sy s tem. Also, there is a h uge difference b et w een op enness of the d esign and op en- ness of the source. Op enness of the design m a y rev eal logical errors in the securit y in the w orst case. With prop er r eview, these errors can and usu- ally are found. F or sour ce co de, this is not, or at least not completel y , the case. In the foreseeable future, s ou r ce co de will conti nue to con tain bu gs, no matter ho w h ard we look, test or v erify . Moreo ver, openin g the source giv es un f air adv an tage to th e attac ker. The attac ker n eeds to fi n d but one vulnerabilit y to s u ccessfully attac k the system. T he defen d er needs to patc h al l vulnerabilities to protect hims elf completely . This is considered an unev en battle. F ourth, there is no direct guarante e that th e bin ary ob ject co de runnin g in the computer corresp onds to the source co de that has b een ev aluated [ 11 ]. P eople u nable or un willing to compile f rom source m ust rely on a trusted third part y to v ouc h for this 3 . Also, making the source p ublic do es not guarant ee that an y qualified p erson w ill actually lo ok at the sou r ce and ev aluate (let alone impro ve ) it. There are many op en sour ce p ro jects that, after a br ief flurry of activit y , are only marginally maintai ned and quic kly sink in to oblivion. Th e attac kers, on the other h and, most surely wil l scru tinise the source. 3 Or could use tools like systrace to confi ne untrusted ob ject code, and to enforce a securit y p olicy n ev ertheless [ 9 ]. 4 In bazaar st yle op en sou r ce pr o jects, bac k-do ors may b e sneak ed in to the source b y hac ke rs p osing as trustful con tributors. T hat th is is not an idle threat b ecame clear in No vem b er 2003, when Linux kernel d ev elop ers disco v ered a bac k-do or in a h armlessly lo oking error-chec king feature add ed to a system call 4 . Finally , and more generally , the qualit y of a piece of soft ware (and patc h es to it) dep end on the skills of the programmers working on it [ 8 ]. F or man y op en source pro jects there is no a pr iori selection of program- mers based on their skill. Usually an y help is app r eciat ed, and there is only rudimentary qualit y control . 2.2 Closed is not so closed: a rgumen ts against closed source Let us fi rst review the argumen ts put forw ard against op en sour ce in the previous section. T he last tw o argumen ts against op en source are actually aimed at the deve lopment metho dology instead. The systems dev elop ed in that manner w ould also b e more insecure if they w ere closed source. W e assume a minimal stand ard of p rop er co d ing practices, pro ject m anage ment, c hange con trol and qualit y control. In fact, one of our main p oints is that by op ening up the source, soft w are pro jects cannot get aw a y with p oor p ro ject managemen t and p o or qualit y con trol s o easily . No w turnin g to the first argumen t against closed source, we note that k eeping the source closed for a long time app ears to b e hard [ 7 ]. Last y ear, source co de for certain t yp es of vot ing mac hines m an u factured by Dieb old w ere d istributed on the Inte rn et, and subsequent r esearc h on that source co de rev ealed horrib le programming errors and securit y vulnerabilities [ 6 ]. Recen tly eve n parts of the source to Microsoft Windo ws NT b ecame pu blic. Within da ys the fir st exp loit based on this source cod e w as p ublished. T he Dieb old case also reve aled ho w bad co ding s tand ards of curren t closed sour ce systems can b e, and h o w they lead to a wfully insecure systems. Ev en if the source remains closed, vulnerabilities of such closed source systems will ev entually b e found and b ecome kn o wn to a larger public after a w hile. V ulnerabilities in existing closed sour ce soft wa re are ann ou n ced on a d aily basis. In fact, to ols lik e debu ggers and disassem blers allo w at- tac kers to fi nd vulnerabilities in applications without access to the source relativ ely quic kly . Moreo ver, not all vu lnerabilities that are disco v ered will b e pu blished. Their discov erers m a y k eep th em s ecret to av oid p atc hes for them, allo wing u se of the vulnerability to exploit systems for a p rolonged p erio d of time. W e see that wh ile the p erceiv ed exp osure of a closed sou r ce system may app ear to b e lo w, the actual exp osure ev entual ly b ecomes m uc h higher (app roac hing the exp osure that w ould exist initially if the system w ere completely op en source). 4 http://www .securityfocus. com/news/7388 . 5 Ev en w orse, only the pro ducer of closed source soft ware can release patc h es for an y v u lnerabilities that are found . Many of those patc hes are released w eeks or months after th e vulnerabilit y is discov ered, if at all. Th e latter case o ccurs for instance with legacy soft ware for w hic h the company pro ducing it no longer exists (or refuses to give su pp ort for it after a while, e.g., Microsoft Windo ws NT Server 4.0 or Netscap e Calendar). The conse- quence is that systems sta y exp osed longer, increasing the risk of usin g that system. W e see that k eeping the sou r ce closed actually hurts th e defend er m u ch more than the attac k er: w hile a determined attac ker can still disco v er weak- nesses easily , the defender is prev ent ed fr om patc hing them. Finally , closed s ou r ce softw are sev erely limits the user of su ch soft w are to ev aluate its securit y for or b y himself. The situation impro ve s if at least the design of the system is op en. If the system is ev aluated b y an inde- p endent part y acc ordin g to some generally accepted metho dology (like the Common Criteria), this giv es the user another basis for trusting the securit y of th e soft ware. Ho w ev er suc h ev aluations are r are (b ecause they are exp en- siv e), and usu ally limited to certain restricted usage scenarios or parameter settings that ma y not corresp ond to the actual op erating en vironment of a particular user. Moreo ver, su ch ev aluations app ly only to a sp ecific v ersion of the soft ware: n ew versions need to b e r eev aluated. 2.3 The wa y forw ard: argumen ts suppor ting op en source W e see that the argument s against ”securit y through obscurity” generally apply to the implementat ion of a s ystem as w ell. It is a w idely held design principle that the securit y of a system should only dep end on the secrecy of the (user-sp ecific) keys, on the groun d th at all other information of the system is shared b y man y other p eople and therefore will b eco me pu blic as a matter of cours e. Moreo ver, op en source enables u sers to ev aluate the securit y by them- selv es, or to hire a party of their c hoice to ev aluate the securit y for them. Op en s ource even enables sev eral different and indep end en t teams of p eo- ple to ev aluate the securit y of the system, remo ving the dep en d ence on a single part y to decide in fa vour or against a certain system. All this do es not d ecrease the securit y or exp osure of the system. Ho w eve r, it d oes help to asses the real exp osure of the system, closing the gap b et w een p erceiv ed and actual exp osu re. Op en source enables users to find bu gs, and to patc h these bu gs them- selv es. Th ere is also a p oten tial net wo rk effect: if users sub mit their p atc hes to a cen tral rep ository , all other us ers can up date their system to in clud e this patc h, increasing their security too. Giv en th at differen t users are likel y to find d ifferen t b ugs, m an y bugs are p oten tially remo ve d. Th is leads to more an d faster patc hes, and hence more secure co de (this corresp onds to 6 ”Lin us’s La w”: ”Giv en enough eyebal ls, bu gs are sh allo w” [ 10 ]). Evidence suggests that patc hes for op en sour ce soft wa re are released almost twice as fast as f or closed source s oft ware, thus h alving th e vulnerabilit y p er io d [ 12 ]. If a user is un able to patc h a bug himself, op en sour ce at least en ab les him to comm un icat e ab out bugs with d ev elop ers more efficien tly (b ecause b oth can use the same frame of reference — i.e., the source co de — f or comm unication [ 10 ]). Also, op en source s oft ware enables u sers to add extra secur ity m easures. Sev eral tools exist to enhance the securit y of existing systems, p ro vided the source is a v ailable [ 3 ]. These to ols do not rely on static c h ec king of the co de. Instead, they add generic ru n time c hec ks to the co de to d etect e.g., buffer o v erflo ws or stac k fr ame corruptions. Moreo v er, op en source soft wa re allo ws the user to limit the complexit y of the system (and thereb y increasing its securit y) by r emo ving un needed parts. Finally , and imp ortantly , op en sour ce forces dev elop er communities to b e more careful, and to use the b est p ossible to ols to secure th eir systems. It also forces them to use clean co ding st yles (”sloppy” cod e is untrust wor- th y), and to pu t more effort in to qu ality con tr ol. Otherwise, companies and individual programmers alik e will lo ose r esp ect and credibilit y . As a side ef- fect, this w ill stimulate researc h and d ev elopment in new, imp ro ved tools for soft w are dev elopment, testing and ev aluation and p er h aps ev en verificatio n. 3 Conclusions W e conclude that op enin g the source of existing systems will at first in crease their exp osure, d ue to the fact that more inform ation ab out vulnerabilities b ecomes a v ailable to attac k ers. Ho we ve r, this exp osure (and the associated risk of using the system) can no w b e determined p ublicly . With clo sed source systems the p erceiv ed exp osu r e ma y app ear to b e lo w, w hile the actual exp osure (due to increased kn o wledge of th e attac k ers) may b e muc h higher. Moreo ver, b ecause the source is op en, all interested parties can assess the exp osure of a system, h unt for bugs and issue patc hes for them, or otherwise increase the secur it y of the system. Security fixes will qu ickly b e a v ailable, so that the p eriod of increased exp osure is sh ort. In the long run, openn ess of the sour ce will increase its securit y . S lopp y co de is visible to eve ryone, and questions ev en th e o ve rall qualit y of it. An y a v ailable tools to v alidate the source will b e us ed more often b y the pro ducers. If not, the users will do it themselves, afterw ards. New, muc h more adv anced, to ols will b e dev elop ed to impr o ve the security of softw are ev en further. Op en sou r ce allo w s users to make a muc h more informed c hoice ab out the securit y of a system, based on their o wn or on in dep enden t judgement . 7 It is our con viction that all th ese b enefits out w eigh the disad v an tages of a short p erio d of increased exp osure. References [1] Ross And erson. Securit y in op en v ersus closed systems — the dance of Boltzmann, Coase and Mo ore. In Confer enc e on Op en Sour c e Softwar e Ec onomics , T oulouse (F rance), June 20–2 1 2002. [2] Kenneth Bro wn. Op ening the op en source debate. T ec hnical rep ort, Alexis de T o cqueville Institution, June 200 2. [3] Crispin Cow an. S oft ware securit y for op en-sour ce systems. IE EE J. Se curity & Privacy , 1(1):38 –45, 2003. [4] Robert L. Glass. A lo ok at th e economics of op en sour ce. Comm. ACM , 47(2): 25–27, F ebru ary 2004. [5] Auguste Kerckhoffs. La cryptographie militaire. J ournal des scienc es militair es , IX, 1983. pp. 5–3 8, Jan. 1883, and pp. 161 –191, F eb. 1883. [6] T. Kohno, A. S tubblefield, A. D. Ru bin, and D. S. W allac h. Analysis of an electronic vo ting sy s tem. In IEEE Se curity & P rivacy , Berk e- ley/Oakland, CA, USA, Ma y 9–12 2004. IEEE. [7] Rebecca T. Mercuri and Pete r G. Neumann . I n side Risks: Securit y by obscurit y . Comm. ACM , 46(11):160, Decem b er 2003. [8] P eter G. Neumann. In side Risks: Information system securit y redux. Comm. ACM , 46(1 0):136, O ctober 2003. [9] Nie ls Prov os. Impro ving h ost security with s ystem call p olicies. In 12th USENIX Se c. Symp. , W ashington D.C., USA, August 2003 . USENIX. [10] Er ic S. Ra ymond. T h e cathedral and the bazaar, 2000. [11] Ken Thompson. Reflections on tru sting trus t. Comm. ACM , 27(8):7 61– 763, August 198 4. [12] Brian Witten, Carl Landw ehr, and Mic hael Calo yannides. Do es op en source impro v e system securit y? IEEE Softwar e , pages 57–6 1, Septem- b er – O ctober 2001. 8