Grafana'da DuckDB'ye yönlendirilen SQL ifadeleri Viewer hesaplarına sunucu dosyalarını okuma imkânı verdi

Grafana'nın SQL Expressions özelliği, 11.0.0'dan 11.1.6'ya kadar olan sürümlerde ve 11.2 hattının daha dar bir bölümünde, panel ifadelerini sunucudaki bir DuckDB client binary'sine iletiyordu. DuckDB basit bir hesap yardımcısı değil, tam kapsamlı bir analitik veritabanı motoru olduğundan, bu tasarım kimliği doğrulanmış kullanıcılara host dosya sistemine giden bir yol açıyordu. Bu açık CVE-2024-9264 olarak takip ediliyor ve konuyu ele alan bir dev.to analizine göre, yalnızca Viewer rolüne — ürünün en düşük yetkili kimliği doğrulanmış rolüne — sahip birinin rastgele dosya okuma ve Grafana sürecinin kendi izinlerinin izin verdiği her yerde dosya yazma gerçekleştirmesini sağlıyordu.

Skor konusunda anlaşmazlık var: yazıya göre Grafana'nın satıcı danışma belgesi sorunu 9.9 olarak derecelendiriyor ve NVD de aynı fikirde, ancak bazı üçüncü taraf incelemeler 9.4 belirtiyor. Hangisi doğru olursa olsun, operasyonel olarak önemli detay gereken ayrıcalık seviyesi — salt okunur bir hesap yeterliydi.

Nasıl çalışıyordu

Bir kurulumun gerçekten açık olup olmadığını iki ön koşul belirliyordu. Expressions özelliğinin etkinleştirilmiş olması ve sunucunun aradığı yol üzerinde bir duckdb binary'sinin bulunabilir olması gerekiyordu. Koşullardan hiçbiri garanti değil, ancak ikisi de yeterince yaygın; bu yüzden sürüm numarası tek başına belirli bir dağıtımın savunmasız olup olmadığını göstermek için zayıf bir rehber.

Mekanizma, Grafana'nın kendi girdi işlemesinin neden hiçbir zaman eksiksiz bir çözüm olamayacağını da açıklıyor. İfade dizgesi yalnızca Grafana içinde değerlendirilmiyor; dosya okuyan, dosya yazan ve extension yükleyen fonksiyonlar dahil eksiksiz bir SQL lehçesi uygulayan harici bir sürece ulaşıyor. Grafana kod tabanındaki doğrulama miktarı ne olursa olsun, alıcı süreç bir dizgeyi kabul ettiğinde yapabileceklerini değiştirmez.

Dosya okuma neyi ortaya çıkarır

Dosya okuma genellikle düşük etkili bir sonuç olarak küçümsenir, ancak bir izleme sunucusu bunu küçümsemek için kötü bir yerdir. dev.to analizinin ortaya koyduğu gibi, Grafana süreci ve erişilebilir çevresi tipik olarak şunları içeriyor: datasource bağlantı dizelerini ve sık sık düz metin halinde API token'larını barındıran provisioning yapılandırması; kullanıcıları, API anahtarlarını ve dashboard tanımlarını içeren Grafana örneğinin arkasındaki veritabanı dosyası; ortama render edilen secret mount'ları, örneğin cluster API'sine kimlik doğrulayan bir Kubernetes token'ı; ve iş yükünün buna karşı sağlamlaştırılmadığı durumlarda cloud instance metadata'sı.

Bunların herhangi birini etkiye dönüştürmek genellikle tek adımlık bir iş — bir token oturuma, bir bağlantı dizgesi veri ambarı erişimine, bir service account pod'a dönüşür. Yazı ayrıca, ifşanın hemen ardından herkese açık proof-of-concept kodunun ortaya çıktığına dikkat çekiyor; yani sömürü artık bir saldırının pahalı kısmı değil.

Tekrarlayan bir örüntü

Yazıda atıf yapılan Grafana danışma dizini, 2025 sonu ve 2026 boyunca bunun tek seferlik değil kalıcı bir sorun sınıfı olduğunu gösteriyor: sqlExpressions içindeki bir uzaktan kod yürütme sorunu 9.1 puan aldı; bir image renderer, rastgele kod yürütmeye yol açan bir girdi kabul etti ve 9.9 puan aldı; bir Alloy özelliği rastgele bir yerel dosyayı okuyup içeriğini bearer token olarak gönderdi, 7.7 puan aldı; ayrıca Enterprise sürümünde ayrıcalık atama ve MCP yapılandırması yoluyla server-side request forgery ile ilgili ayrı sorunlar yer aldı. Grafana bir entegrasyon merkezi olacak şekilde tasarlandı ve bir entegrasyon merkezi dışa çağrılar yapmalı, yapılandırma okumalıdır — küçük hataların kimlik bilgisi ifşasına dönüşmesini sağlayan tam da bu yetkinliklerdir.

Kontrol ve sağlamlaştırma

Yazının doğrulama kontrol listesi basit: expressions özelliğinin etkin olup olmadığını teyit edin, çünkü genellikle tek bir ekip için açılıp bir daha gözden geçirilmemiş olabiliyor; duckdb binary'sinin süreç arama yolunda olup olmadığını ve Grafana service account'ının işe yarar bir yere yazıp yazamadığını kontrol edin; Viewer seviyesindeki hesapları denetleyin, çünkü salt okunur kullanıcılar sunucu dosyalarını okuyabilmiş olabilir; örnek yamasız çalışırken erişilebilir olan provisioning veya datasource token'larını döndürün; ve maruz kalma penceresi sırasında Grafana pod'undan beklenmeyen hedeflere giden dış bağlantılara bakın.

Sağlamlaştırma için öneri, yamasız bir sürüme yükseltmek ve ardından izleme sunucusunun yalnızca grafikler değil kimlik bilgileri de barındırdığını varsaymaktır: datasource secret'larını kısa ömürlerle runtime'da render edilen bir secret manager'a taşıyın, container dosya sisteminden dosya yazma yeteneğini kaldırın, metadata erişimini ağ seviyesinde engelleyin ve Grafana namespace'inden dışa trafiği yalnızca sorguladığı datasource'larla sınırlayın. Bu kontrollerin hiçbiri bir sonraki CVE'nin ifşa edilmesine bağlı değil.

Neden önemli

Bu bir bileşim hikâyesi: basit matematik gibi görünen bir özellik, tesadüfen secret'ların yanında duran genel amaçlı bir sorgu motoruna devredildiği için dosya sistemi ilkesine dönüştü. Operatörler skor anlaşmazlığına not düşebilir ama odağı ayrıcalık seviyesine — en düşük kimliği doğrulanmış rol yeterliydi — ve izleme altyapısının tam da bir saldırganın sıradaki istediği kimlik bilgilerini yoğunlaştırdığı gerçeğine vermeli. dev.to analizinden çıkan pratik ders şu: entegrasyon yoğunluklu bir üründe bir başka dosya okuma hatasının er ya da geç geleceği muhtemel ve tek açık soru, geldiğinde ne bulacağı.