Aslında çok kolay bir soru değil mi? Java C den daha mı güvenli? ancak yeterli bir cevap bulmak da bir o kadar zor
Java için SEI CERT Oracle standartlarında kod yazmaya başladığımızda; Javanın , SEI CERT C Kod Standartlarına göre birkaç güvenlik kuralına daha fazladan sahip olduğunu gördük, zaten JAVA kendi güvenliği ile birlikte tasarlanmıştı.Bizde safça bunu kabul ettik. Ancak Java ve C karşılaştırıldığında ; Java 168 güvenli kodlama kuralına C ise 116 güvenli kodlama kuralına sahip, yani aradaki fark birkaç kuraldan (!) fazla.
Benim (kuşkusuz basit olan) varsayımım tamamen uydurma mı? Yada Java ve C kurallarımız ile ilgili sorunlar mı var ? Ya da Java Programları da ortalama programlar ve C programları gibi güvenlik zafiyetlerine sahip mi? Bu yazıda genel bir yargı olan Java Cden daha güvenlidir tabirinin doğruluğunu belirlemek adına hem C hem de JAVA için CERT kurallarını analiz edeceğim.
C ve Java dillerinin ayrı ayrı kapsamlı ve tutarlı diller olduğunu farz edelim. Her güvenlik açığı ; her iki standardın da kapsam bölümlerinde belirtildiği gibi, C ve Java alt bölümleri kullanılarak kodlanabilir ve tek bir kurala bağlı kalmayacak şekilde kategorize edilebilir.
Bu iki kural herhangi bir güvenlik açığına ne sahiptir nede ihtimal verir.
Her iki standart ta aslında aynı amaçla oluşturulmuş. C dili için ISO C [C11] standartları bizi kısıtlıyor , Java için ise JAVA dil özellikleri veek olarak bazı çekirdek kütüphaneler bizi kısıtlıyor. Bu kurallar bizim Wikimiz üzerinde geliştirildi. Bu geliştirmeler C ve JAVA komitelerinden uzmanlar tarafından gözden geçirildi. Fark ediyoruz ki herhangi bir alan adı (domain) için bu kralların sayısı ilginç olmakla birlikte ikna edici bir güvenlik ölçüsü değil. Daha önemli nokta ise ; Eğer herhangi bir domain için güvenli Kodlama kuralları , ikinci bir domain için oluşturulmuş güvenli kodlama kurallarının uygun bir alt kümesi ise ; birinci domain ikinci domainden daha güvenlidir. Biz birinci domainin kullanımının daha uygun olduğunu düşünüyoruz çünkü bir geliştirici güvenlik ile ilgileniyorsa daha az kural hatırlaması onun daha kolay çalışmasına olanak sağlayacaktır.
Java PC uygulamaları ve Server uygulamalarının Exploitleri medyada yeteri kadar yankı oluşturmamıştır. Java birkaç yüksek seviye exploit tarafından zarar gördüğünde bunlardan en öne çıkan Exploitin kullandığı güvenlik açığı ; Java çekirdek kütüphanelerinde bulunuyordu ve sadece uygulamalarda kendini gösteriyordu. Java ya müdahil olan bir çok Exploit , enjeksiyon exploittir, tıpkı Cross Site Scripting (XSS) gibi, dilin kendisine özgü değildirler.1980lerin ilk yarısına kadar gidildiğinde C dilinin Exploitlerle sıkıntı dolu bir geçmişi olduğunu görüyoruz. Bu sebeplerden ötürü Java daha fazla güvenlik üzerine odaklanmıştı.
Bu analiz için biz C ve Java Standartlarında bulunan en kritik kurallara odaklandım. Bu iki standart her kural için ciddi bir ölçü sağlar, Kural ihlalleri karşısında oluşan problemler ve seviyeleri aşağıda verilmiştir:
Bu yüzden C ve Java için yüksek öneme sahip kuralları saydım, Javanın C diline göre daha az yüksek önemli kurallara sahip olduğuna dair varsayımımla ilgili sonuçlarımız aşağıda listelenmiştir:
Javanın daha az kurala sahip olduğu görülmektedir. Ardından Java ve C için önemli kuralları daha detaylı inceleyip onları :Neden yüksek öneme sahiptir? sorusunun cevabına göre kategorize etmeye çalıştık. Aşağıda bu çalışmamızın özeti görülmektedir:
ÖNEMLİ KURALLARIN KATEGORİLERE AYRILMASI
Bellek Bozulması:
Bellek bozulması C dilinin önemli kuralları arasında en büyük paya sahip. Java herhangi bir analog kurala sahip değil çünküJavanın güvenlik açıklarına , bellek taşmalarına, biçim dizesi açıklarına , use-after-free hatalarına olanak sağlayan yapısı; bellek bozulmasına müsaade etmez. Bu hata artık C programlarında zor hale gelmiştir ancak bellek bozulmasından yararlanmak( Açıktan faydalanmak) ASLR ve DEP gibi bellek koruma teknolojilerinin oluşumuna meydan vermiştir.
ASLR program tasarımını ve bu tasarıma bağlı verileri rastsallaştırır. Tipik bir 32 bir Linux Sistem üzerinde ASLR 65,526 faktörlük bir kod yürütme saldırısının başarı oranını düşürür.(Kaynak :Shacham and Colleagues (Shacham,2004)) ASLR Bellek tasarımını ortaya çıkartan daha düşük seviyeli birkaç exploiti kullanarak ; uzun süreli çalışan programlar vasıtasıyla çözümlenebilir. ASLR: işletim sistemi , tüm ilgili kütüphaneler ve program tarafından desteklenmesi gerekir.
DEPyazılabilir bellek ( veri içeren) ve yürütülebilir bellek (kod içeren) ve yazılabilir olan ama yürütülmesi yasaklanmış kod içeren bellek olarak bellekbölümlerine ayrılmıştır. Sonuç olarak DEP basit Exploit tekniklerine engel olabilir ancak Return odaklı Programlama gibi daha gelişmiş tekniklere konu olabilir.(Shacham 2007) ASLR ve DEP ; PCve mobil aygıtlar tarafından desteklenir. Kullanılabilir olmayabilirler ancak gömülü platformlar üzerinde C programları tarafından desteklenebilirler. Çünkü bu teknolojiler ne mükemmeller nede evrensel olarak kullanılabilir durumdalar, biz Bellek bozulmasıyla ilgili CERT C kurallarımızı geliştirmeye bağlılığımızı devam ettireceğiz.
Ayrıcalık Yükseltme(Privilege Escalations) ;
C de Java da ayrıcalık eskalasyonunu tanımlayan kurallara sahiptir fakat iki dil arasındaki büyük farklılıklar var. Java, bazı kodların hiçbir kısıtlamaya sahip olmadan çalıştırılabileceği yine bazı kodların ise gerekli ayrıcalıklara sahip olmadığı durumlarda engellendiği -tıpkı bir sabit diske yazabilme kabiliyeti gibi- kendi iç ayrıcalık sistemine sahiptir. Java uygulamaları tipik olarak , kısıtlı bir ayrıcalığa sahiptir ve en çok bilinen exploitler Javanın bu iç ayrıcalık modelini hedefler ve kendilerini Java PC uygulamaları ile aynı ayrıcalıkların verilmesini sağlarlar. Böylece Javanın iç güvenlik modellini zayıflatan Java kurallarının adresi İç ayrıcalık eskalasyonu oluyor. (Internal Privilege Escalation IPE)
Diğer yandan C böyle bir sisteme sahip değildir, C standartlarındabir programın , programın başka bölümlerinin kabiliyetlerini kullanabilme konusunda bir limit tanımlayan herhangi bir özelliğe sahip değildir. C bu ayrıcalık eskalasyonunu , bazı C programlarında bulunan Dış ayrıcalık eskalasyon modeline odaklanarak yönetir. Cnin Dış ayrıcalık sistemine (EPE) Windowsun ayrıcalık modeli ve UNIXin izinler modeli örnek bir Ayrıcalık sistem olarak gösterilebilir. Bu ayrıcalık modelleri başka programlama dilleri tarafından da kullanılabilir bu yüzden C kodlamasında uygulanabildiği gibiJava kodları ile de uygulanabilir .
Enjeksiyon:
EnjeksiyonSaldırganın kötü kod parçacıklarını C ve JAVA dışında bazı dillerde çalıştırabilme yeteneğine denir. SQL Enjeksiyoniçin dil SQL , XSS için dil Javascript ve Flashta da kullanılabilen Htmldir. Enjeksiyon sorununu kapsayan iki C kuralı ENV33-C ve FIO30-Cdir. FIO30-C kuralını bellek bozulması ve enjeksiyon kategorilerinin ikisine de koyabiliriz. Biz enjeksiyon altında kategorize ettik çünkü başka birkaç kural da burada sınıflandırılabilirdi.Enjeksiyon açıkları her iki dilde de meydana gelir. Java enjeksiyon konusunda Cye nazaran basitçe daha fazla kurala sahip olduğunu 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 tabanlarına bağlanma konusunda bir standart kütüphane sunar.(JDBC) dolayısıyla sadece JAVA da SQL enjeksiyon hakkında bir kural vardır.
Diğer Kategoriler;
Kalan kategoriler sadece yedi adet C kuralı ve dokuz adet Java kuralı içeriyor. Size tüm Java kurallarının C kurallarına paralel olduğunu göstereceğim . Bir başka deyişle bu kategoriler sadece Javada ve aynı zamanda Cde bulunan sistem açıklarını ortaya koyacaktır.
C kod yürütülmesine dair Javanın tek kuralı JNI03-J(JNI kodlarında bulunan JAVA nesnelerinde direkt işaretçiler kullanmayınız)dir. Bu bizim Java Native Interface (JNI) hakkındaki ilk kuralımız ve başka herhangi bir kategoriye tam olarak oturmuyor. Bu kural genellikle C ile yazılan JNI kodlarını tanımladığı için yüksek bir öneme sahiptir.
Son olarak , C Standardı ( C11, Bölüm 3.4.3) bize tanımsız davranışı (undefined behavior) şu şekilde aktarıyor:
Tanımsız Davranış: Uluslararası Standarda hiçbir şart empoze etmeksizin ,kullanılabilir yada hatalı program mimarisi yada hatalı veri kullanımına bağlı olarak meydana gelen davranıştır.
C standardı derleyici yazarlarına ve platform oluşturuculara odaklanır bu yüzden bu tanımlama bu iki odak noktasına tanımsız davranışın ne yapacağını kontrol edebilme adına gecikmeye neden oluyor buda nihayetinde sistem zafiyetinin kullanılması ile son buluyor.
Beklenmedik Davranışlar kategorisine ait iki Java Kuralımız sırasıyla MET00-J(argümanları doğrulama yöntemi), MSC02-J(Güçlü rastsal sayılar oluştur). Bu kurallar yüksek öneme sahip çünkü herhangi bir saldırgan bu kurallarda meydana gelebilecek bir ihlali kullanarak sistemin kimlik doğrulama mekanizmasını bypass edebilir ve ayrıcalıklarda eskalasyona sebep olabilir. Bütün bu problemler C koduna tıpkı Java koduna olduğu gibi odaklanır.
DEĞERLENDİRME;
Yukarıdaki analiz gösteriyor ki yüksek öneme sahip kurallar için de JAVA dili için en büyük kategori IPE ile ilgili kurallardır. C bu kategoride bir kurala sahip değil çünkü IPE kullanmıyor. C için en büyük kategori ise bellek bozulması olarak gözüküyor. Bellek Bozulması ise JAVA da etkin bir kategori değil çünkü bellek bozulmalarına JAVA yapısından ötürü bağışıklık sahibidir. Sonuç olarak Java yüksek öneme sahip kurallarda Cye göre daha düşük bir yüzdeye sahiptir.
Şimdi, bu kuralların kapsamını inceleyelim. Basitçe belirtmek gerekir ki bazı programlar için bazı kurallarımız kapsam dışı kalabilir. Örnek olarak uyumluluk kuralları Single-Threaded programlarda uygulanabilir değildir. Single-Thread program yazan bir geliştiricinin Multiple thread program yazan bir geliştiriciye kıyasla daha az güvenlik kuralı kullanarak işlemlerini tamamlaması mümkündür.
Javanın IPE kategorisi incelendiğinde ise: JAVA da Güvenilmeyen kod parçacıklarının aynı program üzerinde çalıştırılabilmesi adına tasarlanmış kurallardır. Buna rağmen bir çok JAVA kodları bu güvenilmeyen kod parçacıkları ile çalışmaz. Masaüstü uygulamalar bu güvenilmeyen kod parçacıkları ile çalışmaz. Framework eklentisine sahip bir uygulama , örnek olarak Eclipse, eklentileri kısıtlayabilmek için JAVAnın Güvenlik Mimarisini kullanabilirler fakat kullanmıyorlar. Örneğin Eclipse yüklenen tüm eklentileri ana program kadar güvenilir olarak kabul eder. Diğer bir deyişle Eclipse kullanıcının kendisini koruması fikrine dayalı bir yapıya sahiptir. Sonuç olarak IPE kurallarıEclipcede ve bir çok masaüstü uygulamada uygulanılmayan bir kurallardır.
Peki Java uygulamaları ve Servlet hakkında ne söyleyebiliriz? Java uygulamalarının nesli tükeniyor olabilir fakat Servelts hala ayakta ve JBoss , Apache Tomcat gibi programlar tarafından kullanılıyor. Eğer bir Java kütüphanesi kodluyorsanız yada kodunuz servlet framework kullanıyorsa IPE kuralları uygulanabilir konumdadır. Eğer siz sadece masaüstü uygulamalar yazıyorsanız ki Applet yada Servlet olabilir IPE kurallarını göz ardı edebilirsiniz.
C tarafından sağlanan en yakın analog ; ayrıcalıksız kodlarla en fazla ilişkisi olan bir platformla C kodları ayrıcalıkları kullanırlar. UNIX programlar Root ayrıcalıkları ve Windows programları yönetici ayrıcalıklarıyla burada devreye gireceklerdir.
Sonuç olarak; ayrıcalıksız bir C kodu yazıyorsanız ; C diline ait EPE kurallarını yok sayabilirsiniz. Eğer ayrıcalıksız birJAVA kodu yazıyorsanız 20 IPE kuralını yok sayabilirsiniz. C ve JAVA da bir çok kod ayrıcalıksızdır.
Bu yüzden aşağıda IPE ve EPE kurallarının dışarıda bırakıldığı Yüksek öneme sahip güvenlik kurallarının sayılarını ve oranlarını göreceksiniz:
Yukarıdaki tabloyu incelediğimizde : ayrıcalık eskalasyonu kategorisine ait kuralları hesaba katmadığımız zaman C ve JAVA arasındaki yüksek öneme sahip kuralların oranları arasındaki fark biraz daha açılmıştır. JAVA sadece %6 seviyesinde yüksek öneme sahip kural kullanırken , C sahip olduğu kuralların % i yüksek öneme sahiptir. Bu tabloya göre JAVAnın Cden daha güvenli bir dil olduğu bariz bir şekilde görülmektedir. Makalemizin önceki kısımlarında göstermiş olduğumuz dokuz adet yüksek öneme sahip Java kuralı aynı zamanda C için de kabul görmüş kurallardır.
ÖZET VE GELECEĞE DAİR
Özet olarak bellek bozulması sorunlarına karşı üretilmiş teknolojiler hala CERT C kurallarını yok sayabilecek kadar C komiteleri tarafından güven kazanmamıştır. Tersine Java ise bellek bozulmalarına karşı bir sıkıntı çekmemektedir çünkü JAVA sanal makinesi güvenilmeyen kodları özellikle belirtilmediği sürece hafızaya yazmaz. Bir çok Java programı güvenilmeyen kodları belleğe yüklemez,bu yüzden Java standardımızdaki birçok kural ki yüksek öneme sahip 20 IPE kuralı da buna dahildir , bahsettiğimiz programlarda kullanılmaz.
Eğer ayrıcalıksız bir JAVA kodunu yönetebilmek için bir kod yazıyorsanız , tıpkı Cde kod yazılarken olduğu gibi ağır kurallara tabidir. Ancak ayrıcalıksız bir JAVA kodu yazıyorsanız yada JAVAnın ayrıcalık modelini yok sayıyorsanız, daha az yüksek öneme sahip güvenlik kuralına tabi olursunuz.
NOTLAR
Servlets: Sunucu Kaynaklı ufak programlar
Applets: Java Uygulamaları
IPE: Internal Privilege Escalation : İçsel ayrıcalık eskalasyonu
EPE: External Privilege Escalation: Dışsal Ayrıcalık Eskalasyonu
SQL: Veri tabanı dili.
Injection: Enjeksiyon olarak çeviriyoruz ancak herkesin de bildiği ve İngilizcesini kullandığı Hacking methodu.
Wiki: Kuruluşlar wikipedia dan örnek alarak kendi platformlarında tartışmaya açık alanlar oluşturabiliyorlar. Bu alanlara wiki adı veriliyor.
Exploit: Bu da kült bir terimimiz.
XSS : Cross Site Scripting : bir Hack yöntemi
Use-after-free : Ayrılan bir hafıza öbeğine kullanım dışı bırakılmasından sonra yeniden erişmeye çalışma durumuna denir.
Thread Kavramı:Kabaca threadler bir programın paralel ve birbirinden bağımsız işlemler yapmasını sağladığını söyleyebiliriz.
Single_thread program:İşlemcinin thread kavramını desteklemediği durumlar; programımızda thread kullandığımızı anlamaz.
Multiple-thread program:İşlemcinin aynı process içinde farklı threadlerin kullanımını desteklediği durumdur.
Benim (kuşkusuz basit olan) varsayımım tamamen uydurma mı? Yada Java ve C kurallarımız ile ilgili sorunlar mı var ? Ya da Java Programları da ortalama programlar ve C programları gibi güvenlik zafiyetlerine sahip mi? Bu yazıda genel bir yargı olan Java Cden daha güvenlidir tabirinin doğruluğunu belirlemek adına hem C hem de JAVA için CERT kurallarını analiz edeceğim.
C ve Java dillerinin ayrı ayrı kapsamlı ve tutarlı diller olduğunu farz edelim. Her güvenlik açığı ; her iki standardın da kapsam bölümlerinde belirtildiği gibi, C ve Java alt bölümleri kullanılarak kodlanabilir ve tek bir kurala bağlı kalmayacak şekilde kategorize edilebilir.
Bu iki kural herhangi bir güvenlik açığına ne sahiptir nede ihtimal verir.
Her iki standart ta aslında aynı amaçla oluşturulmuş. C dili için ISO C [C11] standartları bizi kısıtlıyor , Java için ise JAVA dil özellikleri veek olarak bazı çekirdek kütüphaneler bizi kısıtlıyor. Bu kurallar bizim Wikimiz üzerinde geliştirildi. Bu geliştirmeler C ve JAVA komitelerinden uzmanlar tarafından gözden geçirildi. Fark ediyoruz ki herhangi bir alan adı (domain) için bu kralların sayısı ilginç olmakla birlikte ikna edici bir güvenlik ölçüsü değil. Daha önemli nokta ise ; Eğer herhangi bir domain için güvenli Kodlama kuralları , ikinci bir domain için oluşturulmuş güvenli kodlama kurallarının uygun bir alt kümesi ise ; birinci domain ikinci domainden daha güvenlidir. Biz birinci domainin kullanımının daha uygun olduğunu düşünüyoruz çünkü bir geliştirici güvenlik ile ilgileniyorsa daha az kural hatırlaması onun daha kolay çalışmasına olanak sağlayacaktır.
Java PC uygulamaları ve Server uygulamalarının Exploitleri medyada yeteri kadar yankı oluşturmamıştır. Java birkaç yüksek seviye exploit tarafından zarar gördüğünde bunlardan en öne çıkan Exploitin kullandığı güvenlik açığı ; Java çekirdek kütüphanelerinde bulunuyordu ve sadece uygulamalarda kendini gösteriyordu. Java ya müdahil olan bir çok Exploit , enjeksiyon exploittir, tıpkı Cross Site Scripting (XSS) gibi, dilin kendisine özgü değildirler.1980lerin ilk yarısına kadar gidildiğinde C dilinin Exploitlerle sıkıntı dolu bir geçmişi olduğunu görüyoruz. Bu sebeplerden ötürü Java daha fazla güvenlik üzerine odaklanmıştı.
Bu analiz için biz C ve Java Standartlarında bulunan en kritik kurallara odaklandım. Bu iki standart her kural için ciddi bir ölçü sağlar, Kural ihlalleri karşısında oluşan problemler ve seviyeleri aşağıda verilmiştir:
Bu yüzden C ve Java için yüksek öneme sahip kuralları saydım, Javanın C diline göre daha az yüksek önemli kurallara sahip olduğuna dair varsayımımla ilgili sonuçlarımız aşağıda listelenmiştir:
Javanın daha az kurala sahip olduğu görülmektedir. Ardından Java ve C için önemli kuralları daha detaylı inceleyip onları :Neden yüksek öneme sahiptir? sorusunun cevabına göre kategorize etmeye çalıştık. Aşağıda bu çalışmamızın özeti görülmektedir:
ÖNEMLİ KURALLARIN KATEGORİLERE AYRILMASI
Bellek Bozulması:
Bellek bozulması C dilinin önemli kuralları arasında en büyük paya sahip. Java herhangi bir analog kurala sahip değil çünküJavanın güvenlik açıklarına , bellek taşmalarına, biçim dizesi açıklarına , use-after-free hatalarına olanak sağlayan yapısı; bellek bozulmasına müsaade etmez. Bu hata artık C programlarında zor hale gelmiştir ancak bellek bozulmasından yararlanmak( Açıktan faydalanmak) ASLR ve DEP gibi bellek koruma teknolojilerinin oluşumuna meydan vermiştir.
ASLR program tasarımını ve bu tasarıma bağlı verileri rastsallaştırır. Tipik bir 32 bir Linux Sistem üzerinde ASLR 65,526 faktörlük bir kod yürütme saldırısının başarı oranını düşürür.(Kaynak :Shacham and Colleagues (Shacham,2004)) ASLR Bellek tasarımını ortaya çıkartan daha düşük seviyeli birkaç exploiti kullanarak ; uzun süreli çalışan programlar vasıtasıyla çözümlenebilir. ASLR: işletim sistemi , tüm ilgili kütüphaneler ve program tarafından desteklenmesi gerekir.
DEPyazılabilir bellek ( veri içeren) ve yürütülebilir bellek (kod içeren) ve yazılabilir olan ama yürütülmesi yasaklanmış kod içeren bellek olarak bellekbölümlerine ayrılmıştır. Sonuç olarak DEP basit Exploit tekniklerine engel olabilir ancak Return odaklı Programlama gibi daha gelişmiş tekniklere konu olabilir.(Shacham 2007) ASLR ve DEP ; PCve mobil aygıtlar tarafından desteklenir. Kullanılabilir olmayabilirler ancak gömülü platformlar üzerinde C programları tarafından desteklenebilirler. Çünkü bu teknolojiler ne mükemmeller nede evrensel olarak kullanılabilir durumdalar, biz Bellek bozulmasıyla ilgili CERT C kurallarımızı geliştirmeye bağlılığımızı devam ettireceğiz.
Ayrıcalık Yükseltme(Privilege Escalations) ;
C de Java da ayrıcalık eskalasyonunu tanımlayan kurallara sahiptir fakat iki dil arasındaki büyük farklılıklar var. Java, bazı kodların hiçbir kısıtlamaya sahip olmadan çalıştırılabileceği yine bazı kodların ise gerekli ayrıcalıklara sahip olmadığı durumlarda engellendiği -tıpkı bir sabit diske yazabilme kabiliyeti gibi- kendi iç ayrıcalık sistemine sahiptir. Java uygulamaları tipik olarak , kısıtlı bir ayrıcalığa sahiptir ve en çok bilinen exploitler Javanın bu iç ayrıcalık modelini hedefler ve kendilerini Java PC uygulamaları ile aynı ayrıcalıkların verilmesini sağlarlar. Böylece Javanın iç güvenlik modellini zayıflatan Java kurallarının adresi İç ayrıcalık eskalasyonu oluyor. (Internal Privilege Escalation IPE)
Diğer yandan C böyle bir sisteme sahip değildir, C standartlarındabir programın , programın başka bölümlerinin kabiliyetlerini kullanabilme konusunda bir limit tanımlayan herhangi bir özelliğe sahip değildir. C bu ayrıcalık eskalasyonunu , bazı C programlarında bulunan Dış ayrıcalık eskalasyon modeline odaklanarak yönetir. Cnin Dış ayrıcalık sistemine (EPE) Windowsun ayrıcalık modeli ve UNIXin izinler modeli örnek bir Ayrıcalık sistem olarak gösterilebilir. Bu ayrıcalık modelleri başka programlama dilleri tarafından da kullanılabilir bu yüzden C kodlamasında uygulanabildiği gibiJava kodları ile de uygulanabilir .
Enjeksiyon:
EnjeksiyonSaldırganın kötü kod parçacıklarını C ve JAVA dışında bazı dillerde çalıştırabilme yeteneğine denir. SQL Enjeksiyoniçin dil SQL , XSS için dil Javascript ve Flashta da kullanılabilen Htmldir. Enjeksiyon sorununu kapsayan iki C kuralı ENV33-C ve FIO30-Cdir. FIO30-C kuralını bellek bozulması ve enjeksiyon kategorilerinin ikisine de koyabiliriz. Biz enjeksiyon altında kategorize ettik çünkü başka birkaç kural da burada sınıflandırılabilirdi.Enjeksiyon açıkları her iki dilde de meydana gelir. Java enjeksiyon konusunda Cye nazaran basitçe daha fazla kurala sahip olduğunu 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 tabanlarına bağlanma konusunda bir standart kütüphane sunar.(JDBC) dolayısıyla sadece JAVA da SQL enjeksiyon hakkında bir kural vardır.
Diğer Kategoriler;
Kalan kategoriler sadece yedi adet C kuralı ve dokuz adet Java kuralı içeriyor. Size tüm Java kurallarının C kurallarına paralel olduğunu göstereceğim . Bir başka deyişle bu kategoriler sadece Javada ve aynı zamanda Cde bulunan sistem açıklarını ortaya koyacaktır.
C kod yürütülmesine dair Javanın tek kuralı JNI03-J(JNI kodlarında bulunan JAVA nesnelerinde direkt işaretçiler kullanmayınız)dir. Bu bizim Java Native Interface (JNI) hakkındaki ilk kuralımız ve başka herhangi bir kategoriye tam olarak oturmuyor. Bu kural genellikle C ile yazılan JNI kodlarını tanımladığı için yüksek bir öneme sahiptir.
Son olarak , C Standardı ( C11, Bölüm 3.4.3) bize tanımsız davranışı (undefined behavior) şu şekilde aktarıyor:
Tanımsız Davranış: Uluslararası Standarda hiçbir şart empoze etmeksizin ,kullanılabilir yada hatalı program mimarisi yada hatalı veri kullanımına bağlı olarak meydana gelen davranıştır.
C standardı derleyici yazarlarına ve platform oluşturuculara odaklanır bu yüzden bu tanımlama bu iki odak noktasına tanımsız davranışın ne yapacağını kontrol edebilme adına gecikmeye neden oluyor buda nihayetinde sistem zafiyetinin kullanılması ile son buluyor.
Beklenmedik Davranışlar kategorisine ait iki Java Kuralımız sırasıyla MET00-J(argümanları doğrulama yöntemi), MSC02-J(Güçlü rastsal sayılar oluştur). Bu kurallar yüksek öneme sahip çünkü herhangi bir saldırgan bu kurallarda meydana gelebilecek bir ihlali kullanarak sistemin kimlik doğrulama mekanizmasını bypass edebilir ve ayrıcalıklarda eskalasyona sebep olabilir. Bütün bu problemler C koduna tıpkı Java koduna olduğu gibi odaklanır.
DEĞERLENDİRME;
Yukarıdaki analiz gösteriyor ki yüksek öneme sahip kurallar için de JAVA dili için en büyük kategori IPE ile ilgili kurallardır. C bu kategoride bir kurala sahip değil çünkü IPE kullanmıyor. C için en büyük kategori ise bellek bozulması olarak gözüküyor. Bellek Bozulması ise JAVA da etkin bir kategori değil çünkü bellek bozulmalarına JAVA yapısından ötürü bağışıklık sahibidir. Sonuç olarak Java yüksek öneme sahip kurallarda Cye göre daha düşük bir yüzdeye sahiptir.
Şimdi, bu kuralların kapsamını inceleyelim. Basitçe belirtmek gerekir ki bazı programlar için bazı kurallarımız kapsam dışı kalabilir. Örnek olarak uyumluluk kuralları Single-Threaded programlarda uygulanabilir değildir. Single-Thread program yazan bir geliştiricinin Multiple thread program yazan bir geliştiriciye kıyasla daha az güvenlik kuralı kullanarak işlemlerini tamamlaması mümkündür.
Javanın IPE kategorisi incelendiğinde ise: JAVA da Güvenilmeyen kod parçacıklarının aynı program üzerinde çalıştırılabilmesi adına tasarlanmış kurallardır. Buna rağmen bir çok JAVA kodları bu güvenilmeyen kod parçacıkları ile çalışmaz. Masaüstü uygulamalar bu güvenilmeyen kod parçacıkları ile çalışmaz. Framework eklentisine sahip bir uygulama , örnek olarak Eclipse, eklentileri kısıtlayabilmek için JAVAnın Güvenlik Mimarisini kullanabilirler fakat kullanmıyorlar. Örneğin Eclipse yüklenen tüm eklentileri ana program kadar güvenilir olarak kabul eder. Diğer bir deyişle Eclipse kullanıcının kendisini koruması fikrine dayalı bir yapıya sahiptir. Sonuç olarak IPE kurallarıEclipcede ve bir çok masaüstü uygulamada uygulanılmayan bir kurallardır.
Peki Java uygulamaları ve Servlet hakkında ne söyleyebiliriz? Java uygulamalarının nesli tükeniyor olabilir fakat Servelts hala ayakta ve JBoss , Apache Tomcat gibi programlar tarafından kullanılıyor. Eğer bir Java kütüphanesi kodluyorsanız yada kodunuz servlet framework kullanıyorsa IPE kuralları uygulanabilir konumdadır. Eğer siz sadece masaüstü uygulamalar yazıyorsanız ki Applet yada Servlet olabilir IPE kurallarını göz ardı edebilirsiniz.
C tarafından sağlanan en yakın analog ; ayrıcalıksız kodlarla en fazla ilişkisi olan bir platformla C kodları ayrıcalıkları kullanırlar. UNIX programlar Root ayrıcalıkları ve Windows programları yönetici ayrıcalıklarıyla burada devreye gireceklerdir.
Sonuç olarak; ayrıcalıksız bir C kodu yazıyorsanız ; C diline ait EPE kurallarını yok sayabilirsiniz. Eğer ayrıcalıksız birJAVA kodu yazıyorsanız 20 IPE kuralını yok sayabilirsiniz. C ve JAVA da bir çok kod ayrıcalıksızdır.
Bu yüzden aşağıda IPE ve EPE kurallarının dışarıda bırakıldığı Yüksek öneme sahip güvenlik kurallarının sayılarını ve oranlarını göreceksiniz:
Yukarıdaki tabloyu incelediğimizde : ayrıcalık eskalasyonu kategorisine ait kuralları hesaba katmadığımız zaman C ve JAVA arasındaki yüksek öneme sahip kuralların oranları arasındaki fark biraz daha açılmıştır. JAVA sadece %6 seviyesinde yüksek öneme sahip kural kullanırken , C sahip olduğu kuralların % i yüksek öneme sahiptir. Bu tabloya göre JAVAnın Cden daha güvenli bir dil olduğu bariz bir şekilde görülmektedir. Makalemizin önceki kısımlarında göstermiş olduğumuz dokuz adet yüksek öneme sahip Java kuralı aynı zamanda C için de kabul görmüş kurallardır.
ÖZET VE GELECEĞE DAİR
Özet olarak bellek bozulması sorunlarına karşı üretilmiş teknolojiler hala CERT C kurallarını yok sayabilecek kadar C komiteleri tarafından güven kazanmamıştır. Tersine Java ise bellek bozulmalarına karşı bir sıkıntı çekmemektedir çünkü JAVA sanal makinesi güvenilmeyen kodları özellikle belirtilmediği sürece hafızaya yazmaz. Bir çok Java programı güvenilmeyen kodları belleğe yüklemez,bu yüzden Java standardımızdaki birçok kural ki yüksek öneme sahip 20 IPE kuralı da buna dahildir , bahsettiğimiz programlarda kullanılmaz.
Eğer ayrıcalıksız bir JAVA kodunu yönetebilmek için bir kod yazıyorsanız , tıpkı Cde kod yazılarken olduğu gibi ağır kurallara tabidir. Ancak ayrıcalıksız bir JAVA kodu yazıyorsanız yada JAVAnın ayrıcalık modelini yok sayıyorsanız, daha az yüksek öneme sahip güvenlik kuralına tabi olursunuz.
NOTLAR
Servlets: Sunucu Kaynaklı ufak programlar
Applets: Java Uygulamaları
IPE: Internal Privilege Escalation : İçsel ayrıcalık eskalasyonu
EPE: External Privilege Escalation: Dışsal Ayrıcalık Eskalasyonu
SQL: Veri tabanı dili.
Injection: Enjeksiyon olarak çeviriyoruz ancak herkesin de bildiği ve İngilizcesini kullandığı Hacking methodu.
Wiki: Kuruluşlar wikipedia dan örnek alarak kendi platformlarında tartışmaya açık alanlar oluşturabiliyorlar. Bu alanlara wiki adı veriliyor.
Exploit: Bu da kült bir terimimiz.
XSS : Cross Site Scripting : bir Hack yöntemi
Use-after-free : Ayrılan bir hafıza öbeğine kullanım dışı bırakılmasından sonra yeniden erişmeye çalışma durumuna denir.
Thread Kavramı:Kabaca threadler bir programın paralel ve birbirinden bağımsız işlemler yapmasını sağladığını söyleyebiliriz.
Single_thread program:İşlemcinin thread kavramını desteklemediği durumlar; programımızda thread kullandığımızı anlamaz.
Multiple-thread program:İşlemcinin aynı process içinde farklı threadlerin kullanımını desteklediği durumdur.
