Bir Saldırının Anatomisi ve Application Domain Sınıfı-2

Bir Saldırının Anatomisi ve Application Domain Sınıfı-2

Bir önceki yazıda ufak bir ihmalin ne gibi sıkıntılara sebep olduğunu okumuştunuz. Bu yazıda ise yazılım güvenliğinde çok önemli bir yer tutan Application Domain’ler ve bunun detaylarını bulacaksınız.

Öncelikle güvenlikle ilgil olan izolasyon kavramını netleştirmek gerekir. Windows gibi çok görevlilik sunan sistemlerle birlikte çok farklı ve yeni kavramlar gelişmişti. Bunlardan en önemlisi, çalışan uygulamaların birbirlerini etkilemeden sadece kendi işlerine yapabilmelerini sağlamaktı.  Windows’ta bu iş processlerin sınırlayıcılarıyla (Application Domain) yapılmaktadır. Klasik windows uygulamalarında herbir process’in (yani exe’nin) sadece bir Domaini (sınırlayıcı) olurdu ve halende böyledir. Fakat .Net ile birlikte bu iş biraz daha gelişti ve daha güvenli bir hal alması için bir default domain ve sonrasında processe özgü alt domainler (Child Application Domainler) halinde desteklendi.

O halde şöyle düşünebilirz aslında klasik .Exe lerde olduğu gibi .Net exelerindede tek bir domain vardır. Evet aslında bu doğru, CLR’in çalışmasına hatta herşeyden önce .Net Uygulamalarının nasıl çalıştırıldığına bir bakalım;

Gerçekte  Windows .Net uygulamlarını destekelemez. Her hangi bir .Net uygulaması çalıştırılmak istendiğinde öncelikle onun için bir CLR Host processi oluşturulur,  işte bu CLR Host gerçek anlamda Windowsun desteklediği bir uygulamadır yani Unmanaged uygulamadır. Bu CLR Host üzerinde Default bir Application Domain oluşturulur ve .Net Uygulaması bu domain üzerinde çalışır. Host alan .Net kodlarını systemin anlıyacağı hale getirir.

 

Csoft.exe ‘nin process durumu

 

Gördüğünüz gibi aslında her process kendi içerisinde bir Application Domain barındırmaktadır. Hernangi bir .Net uygulaması çalıştırılmak istendiğinde, tıpkı yukarıdaki gibi process içersinde CLR tarafından otomatik olarak oluşturulurlar.

Default Domainlerle ilgili en önemli özellik CLR Host yani Process sonlandırılmadan Unload edilemeyişleridir. Düşünecek olursak doğru olanda budur çünkü default domainin unload edilmesi procesinin boş bırakılması demektir buda anlamsızdır. Buradan şu sonuçta oraya çıkmaktadır madem default domain process için var o zaman ondan kodda çalıştırmayayım, nasılsa kendi uyuglamam içinde izolasyon sağlamaz ve Default Domain içerisindeki bir kodu bağımsız olarak Unload edememde.

Burada önemli bir noktaya daha dikkat çekmek isterim. Bir default domain process içerinde CLR tarafından oluşturlur ve kendiyle ilgili yani uygulamayla ilgili özellik ve yetkileride barındırır buda aslında bir risktir ve bu sebepten Default Domain içerisinde kodlar direk çalıştırlımazlar.

Peki Default Domainde bir Application Domain ise Application Domian nedir ? Kısaca Application Domainler;

.Net Uygulamalarında izolasyonun ve güvenliği bir parçasıdır. Bu sayede bir process içerisindeki her bir uygulama ve assembly bağımsız olarak processten atılabilir. Kısıtlanmış bir  Application Domain içerisine başka processten erişilemez ve process içerisinde bir Application Domainde hata oluştuğunda veya çöktüğünde uygulamanın diğer bölümleri etkilenmez. Bunların hepsi size gerçekten uygulamanızı her açıdan kontroletme olanağı tanımaktadır. Şimdi sanırım kafanızda biraz daha şekillenmeye başlamıştır J. O halde bir örnekle pekiştirmekte fay var. Şimdi örnek bir Console uygulaması açıp şu kodları deniyorum.  (başlamadan önce belirteyim ben denemeleri D: dizininde yapacağım ve her yazdığım kod bir önceki kodu kapsıyarak gidecek)

    class Program    {        static void Main(string[] args)        {            Console.Write("Default Domain Adı : {0} "+                          "Uygulama Dizini    : {1} ",                          AppDomain.CurrentDomain.FriendlyName, AppDomain.CurrentDomain.SetupInformation.ApplicationBase);

                          Console.ReadKey();

        }

}

 

 

 

Bu kodla konu başında bahsettiğim CLR tarafından oluşturulan Default Domain ile ilgili bilgilere ulaşmış olduk. Domain adı ve uygulama dizini gibi, bunların dışında Domain ile ilgili stenilen tüm bilgilere AppDomain.CurrentDomain ile ulaşılabilir.

Bundan sonra oluşturacağımz tüm domainler kendi procesimiz içerisinde yer alacak haliyle CurrentDomain’de. Kendi domainlerimizi;

      AppDomain.CreateDomain(..); +5

 

      Fonksiyonu ile oluşturuyoruz. AppDomain sınını abstrac bir classdır ve constructure’ı yoktur. Bu fonksiyonun 5 Overloadı vardır önemli 3 tanesinde bahsedeceim,

 

1.       sadece domaine bir isim vererek yeni bir domain oluşturur

2.       domain adı ve güvenlikle iligi bilgerlin bulunduğu bir evidance’ nesnesi ister

3.       Domain adı, Evidance ve AppDomainSetup nesnesi, bu nesne Domain oluşturlurken ihtiyaç duyulan bazı bilgileri barındır

 

Diğer iki overload ise AppDomainSetup kullanmadan farklı bir kaç parametreyle oluşturmak için kullanılır

Örnek bir domain oluşturalım;

    class Program

    {

        static void Main(string[] args)

        {

            AppDomainSetup domainBilgi = new AppDomainSetup();

            domainBilgi.ApplicationBase = "D:\Alt_Domain";

 

            AppDomain ozelAlan = AppDomain.CreateDomain("domain#1", null, domainBilgi);

 

            Console.Write("Default Domain Adı : {0} " +

                          "Uygulama Dizini    : {1} " +

                          "------------------------ " +

                          "Alt Domain Adı     : {2} " +

                          "Uygulama Dizini    : {3} ",

                          AppDomain.CurrentDomain.FriendlyName,

                          AppDomain.CurrentDomain.SetupInformation.ApplicationBase,

                          ozelAlan.FriendlyName,

                          ozelAlan.SetupInformation.ApplicationBase

                          );

            

            Console.ReadKey();

        }

 

Kodumuzun ekran çıktısı

 

Yeri gelmişken AppDomainSetup sınıfına değinmekte fayda var isim olarak her nekadar AppDomain ile ilgili ayarların yapılabileceği bir sınıf gibi görünsede aslında değil. Sadece bir domain oluşturlurken ihtiyaç duyulan bazı bilgiler yada özel yapılandırmalar bu sınıf ‘ın bir örneği üzerinden yapılır ve AppDomain.CreateDomain constructure’ına parametre olarak gönderilir ve daha sonrada değiştirilmesi Domaini etkilemez!

Önemli bir kaç üyesi şunlardır;

ApplicationBase  : AppDomain’nin çalıştırdığı uygulamanın yer aldığı dizini belirtir. Bu dizindeki dll veya exe’ler domaine doğrudan yüklenmez. Burası bir internet adresi de bulabilir, Domainleri evidance’larla kullandığımızda buraları güvenli bölgeler olarak kullanacağız.

ShadowCopyFiles : AppDomain içerisinde yer alan Assemblylerinin shadow copylerin üzerinden çalışmasını sağlar bu orjinal Assembly’erin serbest kalmasını ve herbir instance’ın tamamen farklı çalışmasını sağlar, ASP.Net olduğu gibi, bu özellik “true” verilirse aktif, “false” verilirse pasif olur fakat bool değil string olarak değer atamak gerekir.

CachePath  :Assemblyler’in ShadowCopyler’inin kopyalanacağı yolu belirtir

 

AppDomainSetup nesnesinede şimdilik kısaca değindikten sonra, artık domainler nasıl kullanılır onu görelim, tüm örneklerde kullanacağım bir test classı yazıyorum, birinci kural MarshalByRefObject ‘ten türetiyorm ve bir function ile bir void ekliyorum

·         Yeni bir Classlibrary oluştrdum

·         Aşşağıdaki kodları yazdım

namespace expTestAssembly

{

    public class Test : MarshalByRefObject

    {

        public void Navigate(string adres)

        {

            System.Diagnostics.Process.Start(adres);

        }

 

        public void SaveFile(string file, string text)

        {

            FileStream fs = new FileStream(file, FileMode.OpenOrCreate, FileAccess.Write);

            StreamWriter sw = new StreamWriter(fs);

            sw.Write(text);

            sw.Close();

            fs.Close();

        }

    }

}

 

·         Kodu derleyip çıktısını expTestAssembly.dll  D:Alt_Domain dizinine kopyaladım,

 

Class’ımı MarshalByRefObject ’ten türettim, bunun sebebi  AppDomainler arasında iletişim remotingle sağlanır ve haberleşme modeli için gerekli yapı MarshalByRefObject ‘ten gelmektedir. Bir sonraki adımda göreceğiniz gibi kendi oluturduğumuz domainlere direk assebmly yükeleyemiyoruz. Bunun yerine önce Default Domain’e yüklüyor sonrasında Child Domain’e alıyoruz. Bunun sebeblerinden biride alt domainlerin istekleri default domainden alması. Yinede neden Chile Domain’e direk Assembly yüklenemediği MicroSoft tarafından da net bir şekilde belirtilmiyor. Ne msdn’de nede Developer Bloglarında’ bunun net bir açıklaması yok! Belkide ciddi bir güvenlik politikasıdır kim bilebilir.

Örneğimize dönecek olursak, şimdi sırada Default Domain ve ozelAlan Domainimizdeki  Assembly listesini  almak var, hadi alalım.

    class Program

    {

        static void Main(string[] args)

        {

 

            AppDomainSetup domainBilgi = new AppDomainSetup();

            domainBilgi.ApplicationBase = "D:\Alt_Domain";

            domainBilgi.PrivateBinPath = "D:\Alt_Domain";

 

            AppDomain ozelAlan = AppDomain.CreateDomain("domain#1", null, domainBilgi);

 

            Console.Write("Default Domain Adı : {0} " +

                          "Uygulama Dizini    : {1} " +

                          "------------------------ " +

                          "Alt Domain Adı     : {2} " +

                          "Uygulama Dizini    : {3} ",

                          AppDomain.CurrentDomain.FriendlyName,

                          AppDomain.CurrentDomain.SetupInformation.ApplicationBase,

                          ozelAlan.FriendlyName,

                          ozelAlan.SetupInformation.ApplicationBase

                          );

            Console.Write(" Default Domain Assemblies ------------------------ ");

            foreach (Assembly assm in AppDomain.CurrentDomain.GetAssemblies())

            { Console.WriteLine(" " + assm.GetName().Name); }

            Console.Write(" Child Domain Assemblies ------------------------ ");

            foreach (Assembly assm in ozelAlan.GetAssemblies())

            { Console.WriteLine(" " + assm.GetName().Name); }

 

            Console.ReadKey();

        }

    }

Default Domain ve Kendi domaimizdeki assembly’ler

 

Buraya kadar aslında henüz hiç bir şey yapmadık sade Application Domain lerin ne olduğu neden kullanıldığı ve nasıl oluşturulduklarıyla ilgilendik. Bir sonraki yazıda bu alanlara Assembly nasıl yüklenir ve bu Assembly’lere nasıl erişilir göreceğiz. Ama bu defa bir sonraki makale hemen geliyor ,  :-)

 

suattuncer@hotmail.com

Döküman Arama

Başlık :

Kapat