Wyłączone opkody, czyli Quine oraz inne ataki

[garlonicon]

Społeczności, takie jak na przykład BSV, szczycą się tym, że zostały przywrócone opkody, które na innych monetach są wyłączone. Jednym z takich opkodów jest OP_CAT. Analogicznym opkodem jest również OP_SUBSTR (zastąpione niekiedy przez OP_SPLIT). Oba opkody wyglądają niepozornie: no bo niby dlaczego łączenie napisów albo ich rozdzielenie mogłoby być groźne? Myślę, że ten wpis pozwoli lepiej zrozumieć, dlaczego Satoshi wyłączył niektóre opkody oraz jakie ataki stają się możliwe w momencie ich przywrócenia, jeśli zrobi się to w tej formie, w jakiej istniały wcześniej.

Wyjaśnienie stanowiące podstawę techniczną niniejszego wpisu jest wzięte z listy mailingowej: https://lists.linuxfoundation.org/piper ... 20462.html

Typowemu programiście zdarza się trafić na różne sprytne sztuczki, które wyglądają niewinnie, ale są w istocie dość groźne. Na przykład plik ZIP, który można rozpakowywać w nieskończoność: https://kottke.org/14/06/the-infinitely-large-zip-file. Podobną sztuczkę stanowi Quine, czyli program, który wypisuje swój własny kod źródłowy po uruchomieniu. W pierwszej chwili nie jest to takie oczywiste, czy takie rzeczy w ogóle da się zrobić. Jednakże, po przejściu przez takie sztuczki okazuje się, że nie tylko jest to realne, ale również może stanowić potencjalną lukę bezpieczeństwa.

Dlaczego nieskończony ZIP jest groźny? Otóż: wyobraźmy sobie, że na komputerze użytkownika znajduje się antywirus. Taki program skanuje podejrzane paczki, sprawdza ich zawartość, a następnie albo usuwa, jeśli plik jest groźny (i informuje o tym użytkownika), albo zostawia, jeśli jest nieszkodliwy. W przypadku wspomnianego pliku, problem polega na ciągłej próbie rozpakowania takiego ZIPa do samego końca. To się nigdy nie uda, antywirus może się zawiesić i zapchać dysk niepotrzebnymi kopiami tego pliku, który z punktu widzenia atakującego waży jedynie niecały kilobajt.

Co to ma wspólnego z kryptowalutami? Otóż takie opkody, jak OP_CAT albo OP_SUBSTR, pozwalają na napisanie takiej transakcji, która będzie mogła być powtarzana w nieskończoność. Jest to tak zwany Quine. W ten sposób można zrobić najprzeróżniejsze brzydkie rzeczy. Przykładowo: można użyć punktu bazowego (czyli klucza prywatnego równego jeden, tudzież innego dowolnego powszechnie znanego klucza) i napisać taką transakcję, która będzie umożliwiała wysłanie monet tylko na taki adres. Następnie można utworzyć taki adres i wysłać na niego monety.

Co się stanie dalej? Monety z takiego adresu będą mogły zostać wysłane tylko na nasz znany klucz publiczny. W normalnym przypadku ktoś by mógł błyskawicznie zgarnąć takie monety i atak na tym by się zakończył. Jednakże: cechą Quine jest rekursywność. Oznacza to tyle, że monety zostaną wysłane zawsze na taki sam adres, z jakiego są wydawane. Wtedy Quine jest kompletny. Efekt końcowy jest taki, że taka transakcja jest niczym odkurzacz: zasysa istniejące monety, blokując je w nieskończonej pętli transakcyjnej.

Dlaczego taki atak jest groźny? Powody mogą być różne, ale podam następujący: istnieją boty, które zgarniają monety z łatwych do zdobycia adresów. Jest taka możliwość, że Quine będzie operował na naszym adresie atakującego i że boty nauczą się ten adres wydawać. Jeśli kilkukrotnie jakieś monety zostaną przesunięte w identyczny sposób, to może się okazać, że da się napisać taki Quine, na który jakiś bot będzie reagować. Adres atakującego może być nawet nieznany, byleby sygnatury pozwalały na przesunięcie monet i umożliwiały wydanie tego wszystkiego za pomocą prostego klucza.

Jakie są dalsze konsekwencje? Otóż w przypadku BSV nie istnieje limit wielkości bloku. Oznacza to tyle, że taki Quine mógłby zostać użyty w celu zapchania bloków niepotrzebnymi danymi tak, aby ich całkowite pobranie mogło się okazać niepraktyczne. Całkiem możliwe, że dałoby się rozszerzyć Quine tak, aby zrobić cały blok na tym oparty. W takim przypadku atakujący wydobyłby normalny blok, który z jego punktu widzenia nie byłby jakoś szczególnie duży, natomiast pozostałe węzły nieustannie usiłowałyby pobrać wszystkie transakcje w nim zawarte i mogłoby im się to nigdy nie udać, powodując zawieszenie pobierania łańcucha na bloku wybranym przez atakującego.

[zbig001]

Sporym problemem związanym z OP_CAT jest że to w połączeniu z już działającymi opkodami umożliwia on emulację działania toeretycznie każdego opkodu, zarówno tych już zaproponowanych w BIP czekających w kolejce do akceptacji, jak i nawet tych jeszcze nie wymyślonych. A w tym już zaproponowano nie wszystko wydaje mi się pozbawione kontrowersji. Mam na myśli szczególnie vaults, umożliwiające zabranie z powrotem pod kontrolę użytkownika monet które zostały przez niego stracone w wyniku oszustwa, działania malware lub kradzieży klucza prywatnego. Wydaje się to piękne do momentu kiedy sobie uświadomimy że ten mechanizm może być użyty do oszukiwania uczciwych nabywców monet. Są tysiące argumentów przemawiających za zwiększeniem zakresu swobody użytkownika w nakładaniu restrykcji w jaki sposób mogą być wydane monety z kontrolowanych przez niego adresów, ale nieodwracalność transakcji wydaje się nieodłączną częścią wizji Satoshiego. Byłbym więc przeciw uruchamianiu tego rodzaju nowości na łańcuchu głównym, tym bardziej że z pomocą BitVM może się niedługo udać uruchomienie dodatkowych warstw transakcyjnych na których mieli byśmy swobodę sprawdzenia w boju czekogolwiek co nam się tylko zamarzy.

[rav3n_pl]

Jak się wczytuję, to wygląda mi na możliwość ataku sieci jako takiej (obciążenie węzłów) ale zagrożenia dla użytkowników nie widzę.
Ponieważ skrypty są wykonywane w odseparowanym środowisku per wejście, jeżeli nie będzie jakiegoś błędu przepełnienia, nie ma możliwości wpłynięcia na inne części transakcji.
Możemy więc też mieć do czynienia z adresami, z których nie da się wydać środków - bu skrypt wydania nie będzie mógł się wykonać.
Jestem przeciwny otwieraniu drzwi, które potencjalnie mogą sparaliżować sieć.

[Bits-Bull]

Cześć społeczności! @garlonicon Ciekawy temat ...


Zastanawialiście się, jakie implikacje niesie ze sobą przywracanie opkodów takich jak OP_CAT i OP_SUBSTR w BSV? Choć mogą wydawać się niewinne, ich potencjał do tworzenia zamkniętych pętli transakcyjnych (Quine) może prowadzić do poważnych luk w bezpieczeństwie!

- Niebezpieczeństwo nieskończoności: Opkody te mogą pozwalać na nieskończone powtarzanie transakcji, co może w praktyce uniemożliwić wydanie monet.

- Ataki na sieć: Bez limitu rozmiaru bloku, taki mechanizm mógłby obciążyć sieć, a konsekwencje byłyby katastrofalne dla użytkowników.

Jak myślicie, czy ryzyko związane z takimi opkodami jest warte ich potencjalnej użyteczności? Dajcie znać, jakie są Wasze przemyślenia!

[teresa98]

Racja – OP_CAT i spółka mogą wyglądać niewinnie, ale dają dostęp do Turingowego piekła Quine na blockchainie to nie żart – masz potencjalnie nieskończoną pętlę wydawania, która może zassać UTXO w nieskończoność i zatkać sieć. Bez limitów bloku? To proszenie się o kłopoty.

To nie tylko kwestia kodu – to kwestia odpowiedzialności. Bezpieczny scripting to nie tylko „więcej opkodów = lepiej”. OP_CAT daje władzę, ale i ryzyko. Trzeba to testować off-chain zanim ktoś odpali to w mainnecie…