Tip karışması kusuru ve çalışma şekli
Kusur, adlandırılmış alanlardan oluşan ve her alanın kendi veri türüne sahip olduğu bileşik (composite) türlerde görülüyor. PostgreSQL'de bir alanın türü değiştirilirken, sunucunun diğer kısımlarında hâlâ o alanın eski değerleri saklanabiliyor. Sunucu bu eski değerleri, artık sahip olduğu yeni tür gibi okuyarak tip karışmasına yol açabiliyor. Projenin sürüm notlarına göre açıklanan çözüm, sunucunun bir değerin türüyle artık eşleşmediğini fark etmesini sağlayan sürüm kontrolleri eklemesini içeriyor.Mehmet Ince'nin teknik analizi ve etkilendiği hizmetler
Güvenlik araştırmacısı Mehmet Ince, bu açık için çalışan bir istismarı PostgreSQL 18.6 üzerinde gösteren teknik bir yazı yayımladı. Ince'nin yöntemi, bir değeri tutan bir sorgu hazırlamayı, bu değerin alanlarından birinin türünü değiştirmeyi ve ardından sorguyu çalıştırmayı içeriyor. Yazıda, yamalanmamış bir sunucuyu bu yolla çökerten SQL kodu ve ikinci adımda hafıza adreslerini sızdıran bir teknik paylaşılıyor; ancak sunucuyu komut çalıştırmaya götüren son adımın SQL kodu paylaşılmıyor. Ince, bu çökme olayını "en düşük yetkili oturum açma rolü" olarak tetikleyebileceğini belirtiyor.Projenin güvenlik danışmanlığı belgesi, saldırganı yalnızca nesne oluşturabilen biri olarak tanımlıyor; bu yetkinin hangi izinleri gerektirdiğini net olarak açıklamıyor. PostgreSQL paketleri sunan Red Hat ise kendi değerlendirmesinde, saldırganın nesne oluşturma veya değiştirme yeteneğine sahip bir veritabanı oturumuna sahip olması gerektiğini ifade ediyor. Hiçbiri kaynak, yalnızca varsayılan izinlere sahip bir hesabın kod çalıştırmaya kadar gidebileceğini belirtmiyor.
Ince, kusurun kökenini 5 Mayıs 2004'te PostgreSQL'in bir sütunun türünü değiştirme yeteneği kazanmasına, kod çalıştırma tekniğinin ise 14 Mayıs 2015'te yapılan daha sonraki bir değişikliğe dayanıyor. Araştırmacı, istismarı yönetilen PostgreSQL hizmetlerine uyarladı ve kanıtlarını bu hizmetlerin güvenlik ekipleriyle Ağustos ayında gizli olarak paylaştı. Çalışmalarında yer alan tedarikçiler arasında AWS (Aurora ve RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks ve Ubicloud bulunuyor.
Yöneticiler için alınacak önlemler
Yöneticiler, mevcut ana sürümlerine uygun olacak şekilde sunucularını 18.7, 17.12, 16.16, 15.20 veya 14.25 sürümüne güncellemeli. Bu güncelleme sırasında, sunucuda yüklü tüm C dilinde yazılmış eklentiler de yeniden derlenmeli veya güncellenmeli. Projenin RPM paket bakım ekiplerinin deposu bildirisine göre, daha eski sürümlere karşı derlenen eklentiler hâlâ yükleniyor ancak bu sürümde giderilen açıklardan korunuyor olmayabilir. Bazı eklentiler için kaynak kodu değişiklikleri de gerekebilir. Yeni sürümler için yeniden derlenen eklentiler, eski sunucularda yüklenemez hale gelebilir.- PostgreSQL, kendi paket servisi dışında çalışıyorsa (örneğin Patroni altında), RPM paket bakım ekibinin blog yazısında belirttiği gibi güncelleme tamamlandığında hemen yeniden başlatılmalı.
- pg_dump, pg_restore, reindexdb ve vacuumdb gibi istemci araçları, bu araçların çalıştığı her makinede güncellenmeli.
- Projenin uyarısına göre, kontrolleri devre dışı bırakmak için yeni composite_type_mismatch ayarı kullanılmamalı; bu durum güvenlik riskleri taşıyor.
- Güncelleme yapıldıktan sonra, sürüm duyurusundaki yeniden dizin oluşturma adımları izlenmeli. Artık yedekleme kullananlar yeni bir tam yedek alıp, sonraki artımlı yedeklerin temelini bu yedeğe almalı.

Yazılım ve Uygulamalar
Yazılım ve Uygulamalar
Yazılım ve Uygulamalar
Yorumlar (0)
Yorum yapmak için giriş yapmalısınız.