Aslinda çok kolay bir soru degil mi? “ Java C den daha mi güvenli?” ancak yeterli bir cevap bulmak da bir o kadar zor… Java için SEI CERT Oracle standartlarinda kod yazmaya basladigimizda; Java’nin , SEI CERT C Kod Standartlarina göre birkaç güvenlik kuralina daha fazladan sahip oldugunu gördük, zaten JAVA kendi güvenligi ile birlikte tasarlanmisti. Bizde safça bunu kabul ettik. Ancak Java ve C karsilastirildiginda ; Java 168 güvenli kodlama kuralina C ise 116 güvenli kodlama kuralina sahip, yani aradaki fark birkaç kuraldan (!) fazla.
Bizim (kuskusuz basit olan) varsayimimiz tamamen uydurma mi? Yada Java ve C kurallarimiz ile ilgili sorunlar mi var ?Ya da Java Programlari da ortalama programlar ve C programlari gibi güvenlik zafiyetlerine sahip mi? Bu yazidagenel bir yargi olan “Java C’den daha güvenlidir” tabirinin dogrulugunu belirlemek adina hem C hem de JAVA için CERT kurallarini analiz edecegiz.
C ve Java dillerinin ayri ayri kapsamli ve tutarli diller oldugunu farz edelim. Her güvenlik açigi ; her iki standardin da kapsam bölümlerinde belirtildigi gibi, C ve Java alt bölümleri kullanilarak kodlanabilir ve tek bir kurala bagli kalmayacak sekilde kategorize edilebilir.
Bu iki kural herhangi bir güvenlik açigina ne sahiptir nede ihtimal verir.
Her iki standart ta aslinda ayni amaçla olusturulmus. C dili için ISO C [C11] standartlari bizi kisitliyor , Java için ise JAVA dil özellikleri veek olarak bazi çekirdek kütüphaneler bizi kisitliyor. Bu kurallar bizim Wiki’miz üzerinde gelistirildi. Bu gelistirmeler C ve JAVA komitelerinden uzmanlar tarafindan gözden geçirildi. Fark ediyoruz kiherhangi bir alan adi (domain) için bu krallarin sayisi ilginç olmakla birlikte ikna edici bir güvenlik ölçüsü degil. Daha önemli nokta ise ; Eger herhangi birdomain için güvenli Kodlama kurallari , ikinci bir domain için olusturulmus güvenli kodlama kurallarinin uygun bir alt kümesi ise ; birinci domain ikinci domainden daha güvenlidir. Biz birinci domainin kullaniminin daha uygun oldugunu düsünüyoruz çünkü bir gelistiricigüvenlik ile ilgileniyorsa daha az kural hatirlamasi onun daha kolay çalismasina olanak saglayacaktir.
JavaPC uygulamalari veServer uygulamalarinin Exploitleri medyada yeteri kadar yanki olusturmamistir. Java birkaç yüksek seviye exploit tarafindan zarar gördügünde bunlardan en öne çikan Exploitin kullandigi güvenlik açigi ; Java çekirdek kütüphanelerinde bulunuyordu ve sadece uygulamalarda kendini gösteriyordu. Java ya müdahil olan bir çokExploit , enjeksiyon exploittir, tipki Cross Site Scripting (XSS) gibi, dilin kendisine özgü degildirler.1980’lerin ilk yarisina kadar gidildiginde C dilinin Exploitlerle sikinti dolu bir geçmisi oldugunu görüyoruz. Bu sebeplerden ötürü Java daha fazla güvenlik üzerine odaklanmisti.
Bu analiz için biz C ve Java Standartlarinda bulunanen kritik kurallara odaklandik. Bu iki standart her kural için ciddi bir ölçü saglar, Kural ihlalleri karsisinda olusan problemler ve seviyeleri asagida verilmistir:
Bu yüzden C ve Java için yüksek öneme sahip kurallari saydik, Java’nin C dilne göre daha az yüksek önemli kurallara sahip olduguna dair varsayimimizla ilgili sonuçlarimiz asagida listelenmistir:
Java’nin daha az kurala sahip oldugu görülmektedir. Ardindan Java ve C için önemli kurallari daha detayli inceleyip onlari :”Neden yüksek öneme sahiptir?” sorusunun cevabina göre kategorize etmeye çalistik. Asagida bu çalismamizin özeti görülmektedir:
ÖNEMLI KURALLARIN KATEGORILERE AYRILMASI
Bellek Bozulmasi:
Bellek bozulmasi C dilinin önemli kurallari arasinda en büyük paya sahip. Java herhangi bir analog kurala sahip degil çünküJava’nin güvenlik açiklarina , bellek tasmalarina, biçim dizesi açiklarina , use-after-free hatalarina olanak saglayan yapisi; bellek bozulmasina müsaade etmez. Bu hata artik C programlarinda zor hale gelmistir ancak bellek bozulmasindan yararlanmak( Açiktan faydalanmak) ASLR ve DEP gibi bellek koruma teknolojilerinin olusumuna meydan vermistir.
ASLR program tasarimini ve bu tasarima bagli verileri rastsallastirir. Tipik bir 32 bir Linux Sistem üzerinde ASLR 65,526 faktörlük bir kod yürütme saldirisinin basari oranini düsürür.(Kaynak :Shacham and Colleagues (Shacham,2004)) ASLR Bellek tasarimini ortaya çikartan daha düsük seviyeli birkaç exploiti kullanarak ; uzun süreli çalisan programlar vasitasiyla çözümlenebilir. ASLR: isletim sistemi , tüm ilgili kütüphaneler ve program tarafindan desteklenmesi gerekir.
DEPyazilabilir bellek ( veri içeren) ve yürütülebilir bellek (kod içeren) ve yazilabilir olan ama yürütülmesi yasaklanmis kod içeren bellek olarak bellekbölümlerine ayrilmistir. Sonuç olarak DEP basit Exploit tekniklerine engel olabilir ancak Return odakli Programlama gibi daha gelismis tekniklere konu olabilir.(Shacham 2007) ASLR ve DEP ; PCve mobil aygitlar tarafindan desteklenir. Kullanilabilir olmayabilirler ancak gömülü platformlar üzerinde C programlari tarafindan desteklenebilirler. Çünkü bu teknolojiler ne mükemmeller nede evrensel olarak kullanilabilir durumdalar, biz Bellek bozulmasiyla ilgili CERT C kurallarimizi gelistirmeye bagliligimizi devam ettirecegiz.
Ayricalik Yükseltme(Privilege Escalations) ;
C de Java da ayricalik eskalasyonunu tanimlayan kurallara sahiptir fakat iki dil arasindaki büyük farkliliklar var. Java, bazi kodlarin hiçbir kisitlamaya sahip olmadan çalistirilabilecegi yine bazi kodlarin ise gerekli ayricaliklara sahip olmadigi durumlarda engellendigi -tipki bir sabit diske yazabilme kabiliyeti gibi- kendi iç ayricalik sistemine sahiptir. Java uygulamalari tipik olarak , kisitli bir ayricaliga sahiptir ve en çok bilinen exploitler Javanin bu iç ayricalik modelini hedefler ve kendilerini Java PC uygulamalari ile ayni ayricaliklarin verilmesini saglarlar. Böylece Java’nin iç güvenlik modellini zayiflatan Java kurallarinin adresi Iç ayricalik eskalasyonu oluyor. (Internal Privilege Escalation “IPE”)
Diger yandan C böyle bir sisteme sahip degildir, C standartlarindabir programin , programin baska bölümlerinin kabiliyetlerini kullanabilme konusunda bir limit tanimlayan herhangi bir özellige sahip degildir. C bu ayricalik eskalasyonunu , bazi C programlarinda bulunan Dis ayricalik eskalasyon modeline odaklanarak yönetir. C’nin Dis ayricalik sistemine (EPE) Windows’un ayricalik modeli ve UNIX’in izinler modeli örnek bir Ayricalik sistem olarak gösterilebilir. Bu ayricalik modelleri baska programlama dilleri tarafindan da kullanilabilir bu yüzden C kodlamasinda uygulanabildigi gibiJava kodlari ile de uygulanabilir .
Enjeksiyon:
EnjeksiyonSaldirganin kötü kod parçaciklarini C ve JAVA disinda bazi dillerde çalistirabilme yetenegine denir. SQL Enjeksiyoniçin dil SQL , XSS için dil Javascript ve Flash’ta da kullanilabilen Html’dir. Enjeksiyon sorununu kapsayan iki C kurali ENV33-C ve FIO30-C’dir. FIO30-C kuralini bellek bozulmasi ve enjeksiyon kategorilerinin ikisine de koyabiliriz. Biz enjeksiyon altinda kategorize ettik çünkü baska birkaç kural da burada siniflandirilabilirdi.Enjeksiyon açiklari her iki dilde de meydana gelir. Java enjeksiyon konusunda C’ye nazaran basitçe daha fazla kurala sahip oldugunu söyleyebiliriz çünkü Java C den daha fazla alt sisteme sahiptir. Örnek olarak SQL Enjeksiyon Java ve C de de mümkündür fakat sadece JAVA SQL veri tabanlarina baglanma konusunda bir standart kütüphane sunar.(JDBC) dolayisiyla sadece JAVA da SQL enjeksiyon hakkinda bir kural vardir.
Diger Kategoriler;
Kalan kategoriler sadece yedi adet C kurali ve dokuz adet Java kurali içeriyor. Size tüm Java kurallarinin C kurallarina paralel oldugunu gösterecegim . Bir baska deyisle bu kategoriler sadece Java’da ve ayni zamanda C’de bulunan sistem açiklarini ortaya koyacaktir.
C kod yürütülmesine dair Java’nin tek kurali JNI03-J(JNI kodlarinda bulunan JAVA nesnelerinde direkt isaretçiler kullanmayiniz)’dir. Bu bizim Java Native Interface (JNI) hakkindaki ilk kuralimiz ve baska herhangi bir kategoriye tam olarak oturmuyor. Bu kural genellikle C ile yazilan JNI kodlarini tanimladigi için yüksek bir öneme sahiptir.
Son olarak , C Standardi ( C11, Bölüm 3.4.3) bize tanimsiz davranis’i (undefined behavior) su sekilde aktariyor:
Tanimsiz Davranis: Uluslararasi Standarda hiçbir sart empoze etmeksizin ,kullanilabilir yada hatali program mimarisi yada hatali veri kullanimina bagli olarak meydana gelen davranistir.
C standardi derleyici yazarlarina ve platform olusturuculara odaklanir bu yüzden bu tanimlama bu iki odak noktasina tanimsiz davranisin ne yapacagini kontrol edebilme adina gecikmeye neden oluyor buda nihayetinde sistem zafiyetinin kullanilmasi ile son buluyor.
Beklenmedik Davranislar kategorisine ait iki Java Kuralimiz sirasiyla MET00-J(argümanlari dogrulama yöntemi), MSC02-J(Güçlü rastsal sayilar olustur). Bu kurallar yüksek öneme sahip çünkü herhangi bir saldirgan bu kurallarda meydana gelebilecek bir ihlali kullanarak sistemin kimlik dogrulama mekanizmasini bypass edebilir ve ayricaliklarda eskalasyona sebep olabilir. Bütün bu problemler C koduna tipki Java koduna oldugu gibi odaklanir.
DEGERLENDIRME;
Yukaridaki analiz gösteriyor ki yüksek öneme sahip kurallar için de JAVA dili için en büyük kategori IPE ile ilgili kurallardir. C bu kategoride bir kurala sahip degil çünkü IPE kullanmiyor. C için en büyük kategori ise bellek bozulmasi olarak gözüküyor. Bellek Bozulmasi ise JAVA da etkin bir kategori degil çünkü bellek bozulmalarina JAVA yapisindan ötürü bagisiklik sahibidir. Sonuç olarak Java yüksek öneme sahip kurallarda C’ye göre daha düsük bir yüzdeye sahiptir.
Simdi, bu kurallarin kapsamini inceleyelim. Basitçe belirtmek gerekir ki bazi programlar için bazi kurallarimiz kapsam disi kalabilir. Örnek olarak uyumluluk kurallari Single-Threaded programlarda uygulanabilir degildir. Single-Thread program yazan bir gelistiricinin Multiple thread program yazan bir gelistiriciye kiyasla daha az güvenlik kurali kullanarak islemlerini tamamlamasi mümkündür.
Java’nin IPE kategorisi incelendiginde ise: JAVA ‘da Güvenilmeyen kod parçaciklarinin ayni program üzerinde çalistirilabilmesi adina tasarlanmis kurallardir. Buna ragmen bir çok JAVA kodlari bu güvenilmeyen kod parçaciklari ile çalismaz. Masaüstü uygulamalar bu güvenilmeyen kod parçaciklari ile çalismaz. Framework eklentisine sahip bir uygulama , örnek olarak Eclipse, eklentileri kisitlayabilmek için JAVA’nin Güvenlik Mimarisini kullanabilirler fakat kullanmiyorlar. Örnegin Eclipse yüklenen tüm eklentileri ana program kadar güvenilir olarak kabul eder. Diger bir deyisle Eclipse kullanicinin kendisini korumasi fikrine dayali bir yapiya sahiptir. Sonuç olarak IPE kurallariEclipce’de ve bir çok masaüstü uygulamada uygulanilmayan bir kurallardir.
Peki Java uygulamalari ve Servlet hakkinda ne söyleyebiliriz? Java uygulamalarinin nesli tükeniyor olabilir fakat Servelts hala ayakta ve JBoss , Apache Tomcat gibi programlar tarafindan kullaniliyor. Eger bir Java kütüphanesi kodluyorsaniz yada kodunuz servlet framework kullaniyorsa IPE kurallari uygulanabilir konumdadir. Eger siz sadece masaüstü uygulamalar yaziyorsaniz ki Applet yada Servlet olabilir IPE kurallarini göz ardi edebilirsiniz.
C tarafindan saglanan en yakin analog ; ayricaliksiz kodlarla en fazla iliskisi olan bir platformla C kodlari ayricaliklari kullanirlar. UNIX programlar Root ayricaliklari ve Windows programlari yönetici ayricaliklariyla burada devreye gireceklerdir.
Sonuç olarak; ayricaliksiz bir C kodu yaziyorsaniz ; C diline ait EPE kurallarini yok sayabilirsiniz. Eger ayricaliksiz birJAVA kodu yaziyorsaniz 20 IPE kuralini yok sayabilirsiniz. C ve JAVA da bir çok kod ayricaliksizdir.
Bu yüzden asagida IPE ve EPE kurallarinin disarida birakildigi Yüksek öneme sahip güvenlik kurallarinin sayilarini ve oranlarini göreceksiniz:
Yukaridaki tabloyu inceledigimizde : ayricalik eskalasyonu kategorisine ait kurallari hesaba katmadigimiz zaman C ve JAVA arasindaki yüksek öneme sahip kurallarin oranlari arasindaki fark biraz daha açilmistir. JAVA sadece %6 seviyesinde yüksek öneme sahip kural kullanirken , C sahip oldugu kurallarin % i yüksek öneme sahiptir. Bu tabloya göre JAVA’nin C’den daha güvenli bir dil oldugu bariz bir sekilde görülmektedir. Makalemizin önceki kisimlarinda göstermis oldugumuz dokuz adet yüksek öneme sahip Java kurali ayni zamanda C için de kabul görmüs kurallardir.
ÖZET VE GELECEGE DAIR
Özet olarak bellek bozulmasi sorunlarina karsi üretilmis teknolojiler hala CERT C kurallarini yok sayabilecek kadar C komiteleri tarafindan güven kazanmamistir. Tersine Java ise bellek bozulmalarina karsi bir sikinti çekmemektedir çünkü JAVA sanal makinesi güvenilmeyen kodlari özellikle belirtilmedigi sürece hafizaya yazmaz. Bir çok Java programi güvenilmeyen kodlari bellege yüklemez,bu yüzden Java standardimizdaki birçok kural ki yüksek öneme sahip 20 IPE kurali da buna dahildir , bahsettigimiz programlarda kullanilmaz.
Eger ayricaliksiz bir JAVA kodunu yönetebilmek için bir kod yaziyorsaniz , tipki C’de kod yazilarken oldugu gibi agir kurallara tabidir. Ancak ayricaliksiz bir JAVA kodu yaziyorsaniz yada JAVA’nin ayricalik modelini yok sayiyorsaniz, daha az yüksek öneme sahip güvenlik kuralina tabi olursunuz.
NOTLAR
Servlets: Sunucu Kaynakli ufak programlar
Applets: Java Uygulamalari
IPE: Internal Privilege Escalation : Içsel ayricalik eskalasyonu
EPE: External Privilege Escalation: Dissal Ayricalik Eskalasyonu
SQL: Veri tabani dili.
Injection: Enjeksiyon olarak çeviriyoruz ancak herkesin de bildigi ve Ingilizcesini kullandigi Hacking methodu.
Wiki: Kuruluslar wikipedia dan örnek alarak kendi platformlarinda tartismaya açik alanlar olusturabiliyorlar. Bu alanlara wiki adi veriliyor.
Exploit: Bu da kült bir terimimiz.
XSS : Cross Site Scripting : bir Hack yöntemi
Use-after-free : Ayrilan bir hafiza öbegine kullanim disi birakilmasindan sonra yeniden erismeye çalisma durumuna denir.
Thread Kavrami:Kabaca thread’ler bir programin paralel ve birbirinden bagimsiz islemler yapmasini sagladigini söyleyebiliriz.
Single_thread program:Islemcinin thread kavramini desteklemedigi durumlar; programimizda thread kullandigimizi anlamaz.
Multiple-thread program:Islemcinin ayni process içinde farkli thread’lerin kullanimini destekledigi durumdur.
