Ken Thompson Hack (1984)

Ken Thompson, 1984'te bir derleyici ikilisini (ve bir * nix sistemindeki bir giriş betiği gibi diğer derlenmiş yazılımları) bozmak için bir yöntem belirledi. Modern derlemenin bu güvenlik açığını ele alıp almadığını merak ettim.

Kısa Açıklama:

Derleyici kodunu 2 hata içerecek şekilde yeniden yazın:

• Kendi ikili kodunu derlerken, derleyici bu kusurları derlemelidir.
• Başka önceden seçilmiş bir kod (giriş işlevi) derlerken, bazı isteğe bağlı arka kapıları derlemelidir.

Bu nedenle, derleyici normal çalışır - bir oturum açma komut dosyası veya benzerlerini derlediğinde, bir güvenlik arka kapısı oluşturabilir ve gelecekte kendisinin daha yeni sürümlerini derlediğinde, önceki kusurları korur - ve kusurlar yalnızca derleyicide bulunur İkili bu yüzden tespit etmek son derece zordur.

Sorular:

İnternette bunlara cevap bulamadım:

• Bu tam zamanında derleme ile nasıl ilişkilidir?
• Bir * nix sistemindeki program işleme girişleri gibi işlevler çalıştırıldıklarında derlendi mi?
• Bu hala geçerli bir tehdit mi, yoksa 1984'ten bu yana önemli bir sorun olmasını engelleyen derleme güvenliğinde gelişmeler oldu mu?
• Bu tüm dilleri etkiler mi?

Neden bilmek istiyorum

Biraz ev ödevi yaparken buna rastladım ve ilginç görünüyordu, ancak bunun güncel bir mesele mi yoksa çözülmüş bir mesele mi olduğunu somut bir şekilde anlayabilmem için arka planım yok.

Referans malzemesi

• genel bakış
• Bazı kod

Bu hack bağlam içinde anlaşılmalıdır. Her zaman ve farklı donanımlarda çalışan Unix'in baskın sistem olduğu bir zamanda ve bir kültürde yayınlandı.

Ne saldırısı kadar korkutucu yapılan C derleyicisi olmasıydı bu sistemler için yazılım merkez parçası. Sistemdeki hemen hemen her şey ilk takıldığında derleyiciden geçti (heterojen donanım nedeniyle ikili dağılımlar nadirdi). Herkes her zaman bir şeyler derledi. İnsanlar düzenli olarak kaynak kodunu denetlediler (çoğu zaman derlemek için ayarlamalar yapmak zorunda kalıyorlardı), bu nedenle derleyicinin arka kapağa enjekte etmesi, yakalanamayacağınız bir tür "mükemmel suç" senaryosu gibi görünüyordu.

Günümüzde donanımlar çok daha uyumludur ve bu nedenle derleyiciler bir sistemin günlük çalışmasında daha küçük bir role sahiptir. Tehlikeli bir derleyici artık en korkutucu senaryo değil - rootkitler ve tehlikeli bir BIOS'un tespit edilmesi ve kurtulması daha da zor.

Bu konuşmanın amacı, ele alınması gereken bir kırılganlığı vurgulamak ya da bilmemiz gereken teorik bir kırılganlık önermek değildi.

Amaç, güvenlik söz konusu olduğunda, kimseye güvenmek istemememiz gerektiğiydi, ama ne yazık ki bu imkansız. Her zaman birine güvenmek zorundasın (bu yüzden başlık: "Güvene İlişkin Düşünceler")

Masaüstü sabit diskini şifreleyen ve kendi derlemediğiniz herhangi bir yazılımı çalıştırmayı reddeden paranoyak bir tür olsanız bile, işletim sisteminize güvenmeniz gerekir. İşletim sistemini kendiniz derleseniz bile, kullandığınız derleyiciye güvenmeniz gerekir. Hatta Ve eğer kendi derleyici derlemek, sen hala güven gerekiyor o derleyici! Ve bu donanım üreticilerinden bile bahsetmiyor!

Sadece güveninle kaçamaz kimse . Karşılaştığı nokta bu işte.

Hayır

Başlangıçta tarif edildiği gibi saldırı asla bir tehdit değildi. Bir derleyici bunu teorik olarak yapabilirken, gerçekte saldırıyı kaldırmak derleyicinin programlanmasını gerektirir.

• Derlenmekte olan kaynak kodun bir derleyicide olduğu zamanları ve
• Korsanlığı içine eklemek için isteğe bağlı kaynak kodunu nasıl değiştireceğinizi öğrenin.

Bu, derleyicinin kaynak kodundan nasıl çalıştığını, bozulmadan değiştirebilmesi için nasıl çalıştığını anlamayı gerektirir.

Örneğin, linkleme formatının veri uzunluklarını veya derlenmiş makine kodunun ofsetini yürütülebilir bir yerde sakladığını hayal edin. Derleyicinin, bunlardan hangisinin ve hangisinin istismar yükünü yerleştirirken güncellenmesi gerektiğine karar vermesi gerekecektir. Derleyicinin sonraki sürümleri (zararsız sürüm) bu biçimi keyfi olarak değiştirebilir; bu nedenle, yararlanma kodunun bu kavramları etkili bir şekilde anlaması gerekir.

Bu yüksek seviyeli, kendi kendini yönlendiren bir programlama, zorlu bir AI problemi (en son kontrol ettiğimde, sanatın türü, pratikte türleri tarafından belirlenen bir kod üretiyordu). Bakın: birkaç insan bunu bile yapabilir; önce programlama dilini öğrenmeli ve ilk önce kod temelini anlamalısınız.

AI problemi çözülse bile, insanlar minik derleyicilerini derlemenin ona bağlı devasa bir AI kütüphanesiyle bir ikili olarak sonuçlanıp sonuçlanmadığını fark edeceklerdir.

Benzer saldırı: bootstrapping güven

Ancak, saldırının genelleştirilmesiyle ilgilidir. Temel sorun, güven zincirinizin bir yerden başlaması gerektiğidir ve birçok alanda kökeni, tüm zinciri tespit edilmesi zor bir şekilde altüst edebilir.

Gerçek hayatta kolayca çıkarılabilecek bir örnek

Ubuntu Linux işletim sisteminiz, indirilen güncelleme paketlerini havuzun imzalama anahtarına (genel anahtar şifrelemesi kullanarak) karşı kontrol ederek güncellemelerin güvenliğini sağlar. Ancak bu, yalnızca imzalama anahtarının yasal bir kaynağa ait olduğunu kanıtlamanız durumunda güncellemelerin orijinalliğini garanti eder .

İmza anahtarını nereden aldın? İşletim sistemi dağıtımını ilk indirdiğinizde.

Güven zincirinizin kaynağının, bu imzalama anahtarının kötü olmadığına güvenmelisiniz.

Sizinle Ubuntu indirme sunucusu arasındaki İnternet bağlantısını MITM yapabilen herhangi biri - bu ISS'niz olabilir, İnternet erişimini kontrol eden bir hükümet (örneğin Çin) veya Ubuntu'nun hosting sağlayıcısı bu işlemi kaçırmış olabilir:

• Ubuntu CD görüntüsünü indirdiğinizi tespit edin. Bu basittir: talebin (genel olarak listelenen) Ubuntu aynalarından herhangi birine gideceğini ve ISO görüntüsünün dosya adını istediğini görün.
• İsteği kendi sunucularından göndererek size saldırganın ortak anahtarını ve Ubuntu yerine depo konumunu içeren bir CD görüntüsü verin.

Bundan böyle, güncellemelerinizi saldırganın sunucusundan güvenli bir şekilde alacaksınız. Güncellemeler kök olarak çalışır, böylece saldırganın tam kontrolü vardır.

Orijinalin orijinal olduğundan emin olarak saldırıyı önleyebilirsiniz. Ancak bu, indirilen CD görüntüsünü bir karma kullanarak doğrulamanızı gerektirir ( birkaç kişi bunu gerçekten yapar ) - ve hash'in kendisi, örneğin HTTPS üzerinden güvenli bir şekilde indirilmesi gerekir. Eğer saldırganınız bilgisayarınıza bir sertifika ekleyebilir (şirket ortamında yaygın olarak bulunur) veya bir sertifika yetkilisini (örneğin Çin) denetlerse, HTTPS bile koruma sağlamaz.

İlk olarak, bu hack'le ilgili en sevdiğim yazımın adı Strange Loops .

Bu belirli kesmek kesinlikle (*) bugün herhangi bir büyük açık kaynaklı işletim sistemi projesinde, özellikle Linux, * BSD ve benzerlerinde yapılabilir. Neredeyse aynı şekilde çalışacağını umuyorum. Örneğin, openssh'ı değiştirmek için sömürülen bir derleyiciye sahip FreeBSD'nin bir kopyasını indirirsiniz. O andan itibaren openssh veya derleyiciyi kaynağa göre her güncellediğinizde soruna devam edeceksiniz. Saldırganın FreeBSD'yi ilk sırada paketlemek için kullanılan sistemden yararlandığını varsayalım (muhtemelen, görüntü bozuksa veya saldırgan aslında paketleyiciyse), o zaman sistem FreeBSD ikili dosyalarını yeniden oluşturduğu zaman, sorunu reddedecektir. Bu saldırının başarısız olması için birçok yol var, ancak Ken'in saldırısının nasıl başarısız olabileceğinden temelde farklı değiller (**). Dünya gerçekten bu kadar değişmedi.

Elbette, benzer saldırılar sahipleri tarafından Java, iOS SDK, Windows veya başka herhangi bir sisteme kolayca veya daha kolay enjekte edilebilir. Bazı güvenlik kusurları donanıma bile dahil edilebilir (özellikle rasgele sayı oluşumunu zayıflatır).

(*) Ama "kesinlikle" demek istediğim "pricinciple". Herhangi bir sistemde bu tür bir delik bulunmasını mı beklemelisiniz? Hayır. Çeşitli pratik nedenlerden dolayı pek olası değildir. Zamanla, kod değiştikçe ve değiştikçe, bu tür bir kesmenin garip hatalara neden olma olasılığı artar. Ve bu keşfedilme ihtimalini arttırıyor. Daha az zeki arka kapılar, komploların sürdürülmesini gerektirir. Elbette, çeşitli telekomünikasyon ve ağ sistemlerinde "yasal yollara müdahale etmenin" arka kapıların yerleştirilmiş olduğu gerçeğini biliyoruz, bu nedenle çoğu durumda bu tür ayrıntılı bir kesmek gereksizdir. Kesmek açıkça takılır.

Yani her zaman, derinlemesine savunma.

(**) Ken'in saldırısının gerçekten var olduğunu varsayarsak. O sadece nasıl ele verebilir yapılabilir. Aslında bildiğim kadarıyla yaptığını söylemedi.

Bu tüm dilleri etkiler mi?

Bu saldırı öncelikle kendi kendini barındıran dilleri etkiler. Derleyicinin dilin kendisinde yazıldığı diller. C, Squeak Smalltalk ve PyPy Python yorumlayıcısı bundan etkilenecektir. Perl, JavaScript ve CPython Python tercümanı olmaz.

Bu tam zamanında derleme ile nasıl ilişkilidir?

Çok değil. Hackerin gizlenmesini sağlayan derleyicinin kendi kendini barındırma niteliğidir. Herhangi bir kendi kendine barındırma JIT derleyicisini bilmiyorum. (Belki LLVM?)

Bir * nix sistemindeki program işleme girişleri gibi işlevler çalıştırıldıklarında derlendi mi?

Genellikle değil. Ama soru değil ne zaman o derlenmiş, ancak hangi derleyici tarafından . Giriş programı, etiketli bir derleyici tarafından derlenirse, etiketlenecektir. Temiz bir derleyici tarafından derlenirse temiz olur.

Bu hala geçerli bir tehdit mi, yoksa 1984'ten bu yana önemli bir sorun olmasını engelleyen derleme güvenliğinde gelişmeler oldu mu?

Bu hala teorik bir tehdittir, ancak pek olası değildir.

Azaltmak için yapabileceğiniz bir şey, birden çok derleyici kullanmaktır. Örneğin, kendisi GCC tarafından derlenen bir LLVM Derleyicisi bir arka kapıdan geçmeyecektir. Benzer şekilde, LLVM tarafından derlenen bir GCC arka kapıdan geçmeyecektir. Yani, bu tür bir saldırı için endişeleniyorsanız, derleyicinizi başka bir derleyici türü ile derleyebilirsiniz. Bu, kötü niyetli bilgisayar korsanının (işletim sistemi satıcınızda?) Her iki derleyiciyi de birbirlerini tanıması için bağlamak zorunda kalacağı anlamına gelir; Çok daha zor bir problem.

Bunun gerçekleşmesi için teorik bir şans var. Bununla birlikte, David A. Wheeler'ın Diverse çift derlemesi aracılığıyla belirli bir derleyicinin (mevcut kaynak koduyla birlikte) tehlikeye atılıp atılmadığını kontrol etmenin bir yolu vardır .

Temel olarak, şüpheli derleyicinin kaynağını derlemek için hem şüpheli hem de bağımsız olarak geliştirilen başka bir derleyiciyi kullanın. Bu size SC _sc ve SC _{T verir} . Şimdi, şüpheli kaynağı her iki ikili dosyayı da kullanarak derleyin. Sonuçta ortaya çıkan ikili dosyalar aynıysa (çeşitli zaman damgaları gibi yasal olarak değişken olabilecek çeşitli şeyler hariç), şüpheli derleyici aslında güveni kötüye kullanmadı.

Belirli bir saldırı olarak, şimdiye kadar olduğu gibi bir tehdit, bu da neredeyse hiç tehdit değil.

Bu tam zamanında derleme ile nasıl ilişkilidir?

Ne demek istediğinden emin değilim. Bir JITter buna bağışıklık kazanıyor mu? Hayır. Daha savunmasız mı? Pek sayılmaz. Bir geliştirici olarak YOUR uygulamanız daha savunmasızdır, çünkü yapıldığını doğrulayamazsınız. Henüz geliştirilmemiş uygulamanızın temelde bu ve tüm pratik varyasyonlara karşı bağışıklık kazandığını, yalnızca kodunuzdan daha yeni bir derleyici için endişelenmeniz gerektiğini unutmayın.

Bir * nix sistemindeki program işleme girişleri gibi işlevler çalıştırıldıklarında derlendi mi?

Bu gerçekten alakalı değil.

Bu hala geçerli bir tehdit mi, yoksa 1984'ten bu yana önemli bir sorun olmasını engelleyen derleme güvenliğinde gelişmeler oldu mu?

Gerçek bir derleme güvenliği yoktur ve olamaz. Bu onun konuşmasının asıl meselesiydi, bir noktada birine güvenmelisin.

Bu tüm dilleri etkiler mi?

Evet. Temel olarak, bir süre veya başka bir durumda, talimatlarınız bilgisayarın tükettiği bir şeye dönüştürülmelidir ve bu çeviri yanlış yapılabilir.

David Wheeler'ın iyi bir makalesi var: http://www.dwheeler.com/trusting-trust/

Ben daha çok donanım saldırıları konusunda endişeliyim. FLOSS kaynak kodlu, tamamen kendimizi değiştirip derleyebildiğimiz, aletlerin arka kapağına yerleştirilmemiş bir mikroişlemci yapmamıza izin veren tamamen VLSI tasarım araç zincirine ihtiyacımız olduğunu düşünüyorum. Araçlar aynı zamanda çip üzerindeki herhangi bir transistörün amacını anlamamıza yardımcı olmalıdır. Daha sonra bitmiş cipslerin bir örneğini açabilir ve bir mikroskopla kontrol edebiliriz, böylece aletlerin sahip olması gereken aynı devreye sahip olduklarından emin olabiliriz.

Son kullanıcıların kaynak koduna erişimi olan sistemler, bu tür saldırıları gizlemek zorunda kalacağınız sistemlerdir. Bunlar bugünün dünyasında açık kaynaklı sistemler olacaktır. Sorun şu ki, tüm Linux sistemleri için tek bir derleyiciye bağımlılık olsa da, saldırının tüm Linux dağıtımları için yapı sunucularına girmesi gerekecek. Bunlar derleyici ikili dosyalarını her derleyici sürümü için doğrudan indirmediklerinden, saldırının kaynağı derleyicinin en az bir önceki sürümünde derleme sunucularında olmalıydı. Bu ya da derleyicinin bir ikili dosya olarak indirdikleri ilk versiyonunun tehlikeye atılması gerekirdi.

Biri, çıkarılan kaynak dosyalarının içeriğinden başka bir şeye bağlı olmaması gereken bir derleyici / derleme sistemi için kaynak koduna sahipse ve biri birkaç derleyiciye sahipse ve hepsinin aynı derleyici kesmesini içermediğini biliyorsa, biri birinin kaynak kodundan başkasına bağlı olmayan bir çalıştırılabilir dosya aldığından emin olun.

Birinin bir derleyici / linker paketi için (örneğin, Groucho Suite) kaynak kodunun çıktılarının belirtilmemiş davranışlara ve girdi kaynak dosyalarının içeriğinden başka hiçbir şeye bağlı olmayacak şekilde yazıldığını varsayalım. bağımsız olarak üretilen çeşitli derleyiciler / linker paketlerini kodlayan linkler (Harpo Suite, Chico suite ve Zeppo Suite), her biri için farklı bir açılabilir dizi oluşturur (G-Harpo, G-Chico ve G-Zeppo). Bu çalıştırılabilirlerin farklı komut dizileri içermesi beklenmez, ancak işlevsel olarak aynı olmalıdırlar. Bununla birlikte, bunların tüm durumlarda fonksiyonel olarak aynı olduklarını kanıtlamak, muhtemelen anlaşılmaz bir problem olacaktır.

Neyse ki, böyle bir kanıt sadece sonuçtaki çalıştırılabilirleri tek bir amaç için kullanırsa: Groucho takımını tekrar derlemek gerekmeyecek. Eğer biri G-Harpo'yu (GG-Harpo'yu veren), G-Chico'yu (GG-Chico) ve G-Zeppo'yu (GG-Zeppo) kullanarak, Groucho takımını derlerse, sonuçta ortaya çıkan her üç dosya da, GG-Harpo, GG-Chico ve GG-Zeppo, tüm baytlar için aynı bayt olmalıdır. Eğer dosyalar eşleşirse, herhangi birinde bulunan herhangi bir "derleyici virüsü" nin hepsinde aynı olması gerektiği anlamına gelir (her üç dosyanın da byte bayt için aynı olması nedeniyle, davranışlarının hiçbir şekilde farklılık göstermesi mümkün değildir) yön).

Diğer derleyicilerin yaşına ve soylarına bağlı olarak, böyle bir virüsün içlerinde makul bir şekilde bulunamamasını sağlamak mümkün olabilir. Örneğin, biri 1980'lerde yazılmış olan bir MPW sürümüyle 2007'de sıfırdan yazılmış bir derleyiciyi beslemek için antika bir Macintosh kullanıyorsa, 1980'lerin derleyicileri 2007 derleyicisinde bir virüsün nereye yerleştirileceğini bilemez. Bugün bir derleyicinin bunu anlamak için yeterince kod analizi yapması mümkün olabilir, ancak böyle bir analiz için gereken hesaplama düzeyi, kodu basitçe derlemek için gereken hesaplama seviyesini çok fazla aşar ve çok fazla fark edilmezdi. Derleme hızının önemli bir satış noktası olduğu bir pazarda.

Üretilecek bir yürütülebilir dosyadaki baytların, sunulan kaynak dosyalarının içeriğinden başka hiçbir şeye bağlı olmaması gereken bir derleme araçlarıyla çalışıyorsa, bir Thompson'dan makul derecede iyi bir bağışıklık elde etmenin mümkün olduğunu söyleyebilirim. tarzı virüs. Ne yazık ki, bazı nedenlerden dolayı, derlemedeki determinizmsizlik bazı ortamlarda normal olarak görülüyor. Çok işlemcili bir sistemde, bir kod parçasının belirli bir iş parçasının hangisinin bir iş parçasını bitirdiğine bağlı olarak değişmesine izin verilirse, derleyicinin daha hızlı çalışmasının mümkün olabileceğini kabul ediyorum.

Öte yandan, derleyicilerin / bağlayıcıların çıktının yalnızca kaynak dosyalara ve kullanıcı tarafından geçersiz kılınabilecek bir "derleme tarihine" bağlı olduğu bir "kanonik çıktı" modu sunmaması için herhangi bir neden gördüğümden emin değilim. . Böyle bir modda kod derlemek normal derlemenin iki katı sürse bile, bayt için herhangi bir "sürüm oluşturma", bayt için, tamamen kaynak malzemelerden, tamamen kaynak malzemelerden yeniden oluşturabilmek için önemli bir değer olacağını öneririm. sürüm oluşturma sürümleri "normal sürümler" den daha uzun sürer.