Cetus Protocol'daki Hacker saldırısı olayına dair teknoloji pro'sunun analizine yorum yapmak

Halk versiyonu: Basit bir "çeviri" ile teknoloji pro hakkında @CetusProtocol'u yorumlayalım.

Hacker saldırı olayının analizi:

Bu saldırı, veri kesme işlemi sırasında tür dönüşümünün bir sonucu olarak ortaya çıkan klasik bir tam sayı taşma sorununu ortaya çıkardı.

Teknik detayların analizi:

1. Açık Konumlandırma: Sorun, get_amount_by_liquidity fonksiyonundaki tür dönüşüm mekanizmasında ortaya çıkıyor; u256'dan u64'e zorunlu dönüşüm, yüksek bit verisinin kaybolmasına neden oluyor.

2. Saldırı Süreci:

1. Saldırgan, add_liquidity fonksiyonu aracılığıyla büyük bir likidite miktarı parametresi gönderir;

2, sistem get_delta_b fonksiyonunu çağırarak gerekli B token miktarını hesaplar;

3. Hesaplama sürecinde, iki u128 türündeki verinin çarpımı, teorik sonuç u256 türünde olmalıdır;

Ana hata: Fonksiyon dönerken u256 sonucu u64'e zorla dönüştürmek, yüksek 128 bit verinin kesilmesine neden olur.

3. Kullanım etkisi: Önceden büyük miktarda token gerektiren likidite miktarı, artık yalnızca çok az miktarda token ile tamamlanabiliyor. Saldırganlar çok düşük maliyetle büyük likidite payları elde ederek, ardından bir kısmını yok ederek fon havuzunda arbitraj gerçekleştiriyorlar.

Basit bir analoji: Sadece 8 basamak gösteren bir hesap makinesi ile 1 milyar × 1 milyar hesaplamak gibi, 20 basamaklı sonuç sadece son 8 basamağı gösterebilir, ilk 12 basamak doğrudan kaybolur. Saldırgan, bu "hesaplama hassasiyeti kaybı" açığından yararlanıyor.

Açık olmak gerekirse, bu güvenlik açığının @SuiNetwork'ın altında yatan güvenlik mimarisiyle hiçbir ilgisi yoktur ve Move dilinin güvenlik "ihtişamı" şu an için hala güvenilirdir. Neden?

Move dili, kaynak yönetimi ve tür güvenliği konusunda gerçekten önemli avantajlara sahiptir ve çift harcama, kaynak sızıntısı gibi alt seviye güvenlik sorunlarını etkili bir şekilde önleyebilir. Ancak bu seferki Cetus protokolünde ortaya çıkan, uygulama mantığı düzeyindeki matematiksel hesaplama hatasıdır ve Move dilinin kendisinin tasarım hatası değildir.

Özellikle, Move'un tür sistemi katı olmasına rağmen, açık tür dönüşümü (explicit casting) işlemleri için geliştiricinin doğru yargısına güvenmek gerekmektedir. Program u256'dan u64'e tür dönüşümü gerçekleştirdiğinde, derleyici bunun kasıtlı bir tasarım mı yoksa mantık hatası mı olduğunu belirleyemez.

Ayrıca, bu güvenlik olayı Sui'nin konsensüs mekanizması, işlem işleme, durum yönetimi gibi temel altyapı işlevleriyle tamamen ilgisizdir. Sui Ağı, yalnızca Cetus protokolü tarafından gönderilen işlem talimatlarını yerine getirmiştir; açık, uygulama katmanı protokolünün mantıksal hatasından kaynaklanmaktadır.

Açıkça söylemek gerekirse, hiçbir gelişmiş programlama dili, uygulama katmanındaki mantıksal hataları tamamen ortadan kaldıramaz. Move, temeldeki güvenlik risklerinin çoğunu önleyebilir, ancak geliştiricileri iş mantığının sınır denetimi ve matematiksel işlemlerin taşma koruması ile değiştiremez.

Düzeltme:

Pro ile daha fazla iletişim kurdum, daha önce @CetusProtocol'ün siber saldırısına ilişkin teknik analizde bazı ayrıntılarda yanlışlıklar vardı, bunu düzeltmek isterim.

Daha önce bunun bir matematiksel hesaplama taşma türü açığı olduğunu doğru bir şekilde belirlemiştik, saldırganlar özel sayılar oluşturarak "küçükten büyüğe" temel mantığının doğru olduğunu gösterdiler. Ayrıca, herkesin merak ettiği Move dilinin güvenliği ile ilgili şüpheleri de doğru bir şekilde yanıtladılar.

Sadece matematiksel hesaplama hatalarının fenomenini gördüm, bu yüzden tip dönüşüm problemi olduğunu varsaydım, ama aslında başka fonksiyonların sınır kontrolü problemi. Aslında, Move dilinde u256'dan u64'e gibi tip dönüşümleri için katı bir denetim mekanizması vardır, bu tür açık dönüşümler normal koşullarda gerçekten güvenlik kontrolüne tabi olur.

Belirli güvenlik açıklarının konumu ve teknik uygulama mekanizmasının düzeltilmesi gerekmektedir, aşağıda.

Gerçek sorun get\_delta\_a fonksiyonunun taşma kontrol mekanizmasının başarısız olmasıdır:

1. Fonksiyonun işlevi: Belirtilen likidite eklendiğinde gereken token A miktarını hesaplamak;

2）Ana kusur: checked\_shlw fonksiyonundaki taşma kontrolünde kodlama hatası var, geçersiz büyük likidite değerlerini engelleyemiyor;

3）Saldırı Kullanımı: Hacker'lar özel likidite değerleri oluşturarak geçersizlik kontrolünü aşar ve nihayetinde div\_round'ın yukarıya yuvarlama mekanizması sayesinde gereken token A miktarını 14'e dönüştürür.

Saldırı etkisi: 1 adet token A ile büyük bir likidite basın, ardından fon havuzunu boşaltın.