ACINQ poinformował, że 14 września wydał Eclair 0.14.3, aby naprawić trzy luki w swojej implementacji Bitcoin Lightning, w tym jedną, która mogła pozwolić złośliwemu peerowi kanału przenieść lokalne saldo ofiary do opłat górniczych podczas kooperacyjnego zamknięcia kanału.

Zgodnie z ujawnieniem ACINQ najpoważniejszy problem dotyczył kooperacyjnego zamykania kanałów. Złośliwy kontrahent mógł zaproponować opłatę za zamknięcie wyższą niż dostępne saldo ofiary, powodując wypłatę całego lokalnego salda jako opłat górniczych. Eclair 0.14.3 odrzuca teraz propozycje opłat przekraczające skonfigurowane maksimum.

ACINQ załatał również drugi błąd związany ze splicingiem, w którym środki mogły utknąć, jeśli splice pozostał niedokończony. Trzeci problem dotyczył finansowania on-the-fly, gdzie złośliwy portfel mógł manipulować harmonogramem płatności. Zaktualizowane oprogramowanie sprawdza teraz opłaty za przekazywanie i bufory wygaśnięcia przed zatwierdzeniem środków oraz dodaje domyślny limit opłat za otwarcie kanału.

Firma podała, że operatorzy powinni przeprowadzić aktualizację, aby uniknąć wykorzystania luk. Dostępne informacje nie zawierają formalnego odniesienia do CVE ani szczegółowej listy dotkniętych wersji poza wydaniem Eclair 0.14.3, a w dostarczonym materiale nie ma potwierdzonego doniesienia, że luki zostały wykorzystane w praktyce przed wdrożeniem łaty.

Niezależne badania techniczne przytoczone w materiałach pomocniczych opisują powiązaną słabość Eclair w monitorowaniu łańcucha podczas wymuszonego zamknięcia, w której węzeł mógł nie wykryć ujawnionego preimage'u, jeśli śledził wyłącznie HTLC z lokalnego stanu zobowiązania. Problem ten wskazuje na szersze wyzwanie bezpieczeństwa Lightning: bezpieczeństwo kanałów może zależeć od tego, jak implementacje obsługują stare, lecz nadal ważne stany zobowiązania, aktualizacje opłat i przypadki brzegowe rozliczeń w łańcuchu.

Dlaczego to ważne

Ta łata ma znaczenie, ponieważ Eclair jest oprogramowaniem infrastrukturalnym, a błędy w warstwie zarządzania kanałami mogą przełożyć się na bezpośrednią utratę środków, nawet gdy sam Bitcoin działa normalnie. Dla użytkowników Lightning i operatorów usług jest to przypomnienie, że bezpieczeństwo operacyjne zależy nie tylko od przechowywania środków i kluczy, lecz także od terminowych aktualizacji klienta oraz niezawodnej obsługi scenariuszy zamknięcia.

Wpisuje się to również w szerszy trend wzmacniania przez implementacje Lightning zabezpieczeń wokół logiki opłat i zachowania podczas wymuszonego zamykania kanałów. W miarę jak coraz więcej aktywności opiera się na pozasieciowych szynach płatniczych, błędy na poziomie implementacji mogą przyciągać większą uwagę operatorów, dostawców portfeli i firm infrastrukturalnych, które zależą od przewidywalnego zachowania rozliczeń.