Merhaba arkadaşlar, bugün electron tabanlı uygulamalarda işleri biraz karıştırmaya çalışalım. Normalde sandbox falan derler ama işin içine native modüller girince işler değişiyor. Özellikle büyük streaming client’larında kullanılan custom native addon’ları hedef almak bayağı etkili olabiliyor.
İlk önce Electron’un renderer sürecinde nodeIntegration kapalıyken bile preload scriptleri üzerinden nasıl native fonksiyonlara ulaşabildiğimize bakalım. Bazı uygulamalar kendi yazdıkları native modülü preload’a enjekte ediyor ve oradan da renderer’a expose ediyorlar. Bu expose işlemi bazen çok dikkatsiz yapılıyor.
Hidden content - for more
Konuyu Görebilmeniz için "Beğenmeniz ve Yorum yapmaniz" Gerekir.
Bunun üzerine bir de custom V8 isolate’ları devreye giriyor. Bazı geliştiriciler kendi isolate’larını oluşturup oraya native binding’leri bağlıyor. Bu binding’ler arasında buffer overflow potansiyeli taşıyan yerler olabiliyor. Özellikle C++ tarafında V8::ArrayBuffer::New allocation’larını elle yönetirken sınır kontrolü atlanabiliyor.
Daha derinlere inersek, Electron’un kullandığı Chromium versiyonundaki V8 engine’inin garbage collector’üyle native heap arasındaki race condition’ları da deneyebiliriz. Bu race’i tetiklemek için aynı anda birden fazla renderer sürecinden native modüle çağrı yapmak gerekiyor. PoC’te basitçe bir worker pool’u ile native fonksiyonu döngüye sokuyoruz.
Hidden content - for more
Konuyu Görebilmeniz için "Beğenmeniz ve Yorum yapmaniz" Gerekir.
Bu işlemler sırasında oluşan memory layout’u incelemek için WinDbg ile Electron sürecine attach olup heap segmentlerini izlemek lazım. Özellikle Large Object Space’te kalan allocation’lar native modülün kendi allocator’ıyla çakışabiliyor.
Son olarak, bu tür bir açığı persistence için kullanmak istersen electron’un single instance lock mekanizmasını da bypass etmen gerekiyor. IPC named pipe’larını farklı bir isimle açıp orijinal uygulamayı kandırabiliyorsun. Tabii bütün bunlar sadece araştırma amaçlı, gerçek hayatta denemeyin.
