Redis RESTORE RCE'leri: Önce Branch'i Yamalayın, Sonra RESTORE'u Elinden Alın

Redis 23 Temmuz'da yedi güvenlik sürümü yayımladı: 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5 ve 8.8.1. Bu sürümler, araştırmacıların hiçbir değişiklik yapılmamış Redis 6.2.22, 7.4.9, 8.6.4 ve 8.8.0'a karşı kimlik doğrulamalı uzaktan kod çalıştırma (RCE) proof of concept'lerini yayımlamasının ardından geldi. The Hacker News'in aktardığına göre araştırmacılar bu açıkları Kimi K3 agent'larının bulduğunu söylüyor. Manşetlere yapay zeka tarafı çıkacak. Beni daha çok ilgilendiren şey ise yayımlanan her zincirin RESTORE komutuna ihtiyaç duyması. Uygulama kodunun bu komutu çağırmak için neredeyse hiç sebebi yok, ama varsayılan Redis kullanıcısı onu çalıştırabiliyor.

Aslında ne düzeltildi#

İki hata sınıfı var ve ikisine de RESTORE üzerinden ulaşılıyor:

• Streams shared-NACK. 8.6.5 sürüm notu, özel olarak hazırlanmış bir stream RESTORE payload'ının iki consumer'ın aynı NACK'i paylaşmasına yol açtığını anlatıyor. Bu da uzaktan kod çalıştırmaya varabilecek bir use-after-free'ye sebep oluyor. The Hacker News'e göre iki consumer da silindiğinde aynı pending-entry kaydı iki kez serbest bırakılıyor.
• RedisBloom ve TDigest. Özel olarak hazırlanmış RESTORE payload'ları sınır dışı yazmalara (out-of-bounds write) yol açabiliyor. The Hacker News'e göre TDigest loader, bellek ayırma boyutunu serileştirilmiş bir değerden hesaplıyor ama saldırganın kontrol ettiği ayrı bir kapasite alanına güveniyordu.

Hangi branch neyi düzeltiyor:

• 6.2.23, 7.2.15 ve 7.4.10 Streams sorununu düzeltiyor.
• 8.2.8, 8.4.5 ve 8.6.5 iki sorunu da düzeltiyor.
• 8.8.1 RedisBloom ve TDigest loader'larını düzeltiyor. Streams koruması 8.8.0'da zaten vardı.

Streams zincirleri ayrıca EVAL ve XGROUP gerektiriyor. 8.8.0 zinciri ise EVAL ile birlikte paketle gelen RedisBloom modülüne ihtiyaç duyuyor. Her zincir kimliği doğrulanmış bir bağlantı gerektiriyor. 24 Temmuz itibarıyla ne Redis'in sürüm notları ne de The Hacker News'in incelediği herkese açık PoC repository'leri sahada aktif istismar bildirmişti. Sürüm notlarında yeni açıklar için bir CVE ya da CVSS puanı yer almıyor.

"Yakın zamanda yamalandı" bir sürüm numarası değil#

Beni en çok rahatsız eden, Mayıs güncellemeleri. PoC hedeflerinden ikisi, 6.2.22 ve 7.4.9, Redis'in kullanıcılara kurmalarını söylediği Mayıs güvenlik sürümleriydi ve shared-NACK sahiplik kontrolünü içermiyorlardı. The Hacker News ayrıca 8.6.4 sürüm notlarının ilgili düzeltmeye atıfta bulunduğunu, ancak 8.6.4 olarak etiketlenen kaynak kodda mükerrer sahiplik kontrolünün bulunmadığını tespit etti.

Mayıs'ta yama yapıp ticket'ı kapatan bir ekibin tekrar yükseltme yapması gerekiyor. "Yamalandı" diyen bir durum alanı yerine, her instance'ın çalıştırdığı tam sürümü INFO server üzerinden takip edin. Production, staging, compose dosyaları ve CI container'ları birbirinden bağımsız olarak kayar.

Kimlik doğrulama bir önlem değil#

Ekipler kimlik doğrulama gerektiren açıkları rutin olarak geri plana atar. Redis söz konusu olduğunda bu mantık zayıf kalıyor. ACL dokümantasyonu, varsayılan yapılandırmayla yeni başlatılmış bir sunucuda tek bir kullanıcı olduğunu gösteriyor: on nopass ~* &* +@all olarak tanımlanmış default. Her yeni bağlantı otomatik olarak kimliği doğrulanmış sayılıyor ve tüm komutları çağırabiliyor.

Parola, göründüğü kadar işe yaramıyor: requirepass sadece aynı default kullanıcısına bir parola atıyor ve bu kullanıcı hâlâ +@all yetkisine sahip. O kimlik bilgisi genellikle her uygulama sunucusunun ortam değişkenlerinde, CI secret'larında ve worker bağlantı string'lerinde duruyor. Yamalanmamış bir instance'ta sızan tek bir kimlik bilgisi, örneğin bir ortam değişkeni dökümünden, Redis sunucusunda kod çalıştırmaya giden bir yol demek.

Ucuz çözüm: RESTORE'u elinden alın#

The Hacker News'in önerisi şu: yükseltin, o zamana kadar da RESTORE yetkisini kesinlikle ihtiyaç duymayan hesaplardan geri alın ve güvenilmeyen ağ erişimini engelleyin. Sadece RESTORE'u kısıtlamak bile açıklanan iki yolu da kapatıyor.

ACL SETUSER app -restore
ACL GETUSER app

Yaygınlaştırmadan önce, dokümantasyondan:

• RESTORE hem @dangerous hem de @keyspace altında listeleniyor. @dangerous'ı kaldırmak RESTORE'u da elden alır, ama INFO, KEYS, CLIENT, SORT ve CONFIG'i de kaldırır. Bu yüzden önce bunu test edin.
• Değişikliği kalıcı hale getirin. Harici bir ACL dosyası kullanıyorsanız ACL SAVE çalıştırın, çünkü CONFIG REWRITE bunu tetiklemiyor. Kullanıcılar redis.conf içinde tanımlıysa CONFIG REWRITE kullanın.
• Migration ya da yedekleme araçlarına RESTORE yetkisini koruyan ayrı bir kullanıcı verin.

Zincirlerin ortak kullandığı diğer komut EVAL. Pek çok kütüphane lock, rate limiting ve iş kuyrukları için Lua kullanıyor, dolayısıyla EVAL'i kaldırmak nadiren gerçekçi. RESTORE'u kaldırmak ise genellikle gerçekçi.

Yapay zeka kısmı, çekinceleriyle birlikte#

Chaofan Shou, X'te Kimi K3 agent'larının yaklaşık 90 dakikada 19 Redis zero-day'i bulduğunu, başka bir çalıştırmanın da 8.8.0 exploit'ini 27 dakikada ürettiğini söyledi. The Hacker News, sayıların, sürelerin ve agent'ların ne kadar bağımsız çalıştığının tamamen beyana dayalı olduğunu açıkça belirtiyor. Redis'in kamuya açık kayıtları açıkları ve düzeltmeleri doğruluyor, rakamları değil. Bu açıklama ayrıca Mayıs'ta yamalanan, yine yapay zekayla keşfedilmiş başka bir Redis RCE'sinin ardından geliyor.

Her gün coding agent'ları kullanıyorum ve biri bu rakamları tekrar üretene kadar onlara şüpheyle bakmaya devam edeceğim. Ama önceliklendirme şeklimi değiştirmeleri için doğru olmaları gerekmiyor. "Kimlik doğrulama ve belirli bir komut gerektiriyor" eskiden "kimse uğraşmaz" demekti. Bu sefer çalışan exploit'ler, düzeltilmiş sürümler çıkmadan önce kamuya açıktı.

Bu konuda ne yapıyorum#

Redis, çalıştığım stack'lerin bir parçası. Pazartesi listem şu:

1. Dev ve CI container'ları dahil her instance'ın çalışan sürümünü envantere çıkarmak ve her birini kendi branch'inin düzeltilmiş sürümüne taşımak.
2. default kullanan tüm uygulama bağlantılarını isimli bir kullanıcıyla değiştirmek ve o kullanıcıya -restore eklemek.
3. Redis portlarına yalnızca ihtiyaç duyan host'lardan erişilebildiğini doğrulamak.
4. Bir image, Redis sürümünü kendi branch'inin düzeltilmiş sürümünün altında sabitlediğinde başarısız olan bir pipeline kontrolü eklemek.

Değişen şey sıralama: önce exploit, sonra yama, ve avcı olarak bir agent gösteriliyor.