Comments 38
К сожалению, сделать такое с блокчейном невозможно по определению.
Почему невозможно? Там же прослойка в виде api, на стороне которого такую проверку запросто можно реализовать. Скорее всего она там давно имеется.
Проблема в подходе.
Если будет реализовано "удаление" (пусть и через запрет обращения к определённым контрактам) то вместо блокчейна будет "просто ещё одна база данных" что в корне подрывает саму идеологию блокчейна.
И да, я подобного давно ожидал.
Ещё бы и ЦП распространяли, но данных много больше чем вредонос нужно.
Зачем удаление, идет же обращение к rpc провайдеру в JsonRpcProvider, вот на стороне провайдера проверять контракт на вшивость по какому нибудь блоклисту и возвращать отказ никто не мешает. Публичных JsonRpcProvider по пальцам пересчитать, если все они блэк листы контрактов будут поддерживать и проблема уйдёт, а злоумышленникам придется свои rpc поднимать и светиться, а это уже другой коленкор.
Если появится возможность блокировать контракты ( не важно по каким причинам ), это станет инструментом для манипуляций. Кто решает, что контракт вредоносный? Какой-то единый орган/организация? Но ведь сеть децентрализована, а если это решается пользователями, возможны способы обмана. В любом случае прецедент будет и это подорвет доверие к сети
Можно сделать децентрализованный реестр чёрного списка контактов...
И кто будет модерировать?
децентрализованный реестр чёрного списка контактов...
А потом в реестр протащат вредоносный контракт и придётся делать децентрализованный реестр особо чёрного списка контрактов децентрализованного реестра чёрного списка контрактов, ага.
И, да, децентрализация реестров не решает начальной проблемы - кто решает, что контракт вредоносный?
Кто решает, что контракт вредоносный?
Владелец домена binance.org, к которому идёт обращение.
Хорошо, один контракт можно заблокировать. А что если несколько записей из разных блокчейнов через какую-нибудь операцию типа XOR будут давать вредоносный код?
Владельцу необязательно самому обнаруживать вредоносный код или убеждаться в том, что он действительно таков.
Принцип такой же, как если бы части вредоноса лежали на бесплатных хостингах или в виде рар-джипегов на аватарках.
Как только проблема становится хоть немного заметной, всем причастным владельцам рассылается уведомление, что вот такие-то и такие-то ответы их серверов приводят к вредоносной активности. С объяснением, как и почему.
И дальше уже владельцы решают, хотят они поменять ответы своих серверов, или нет.
Что значит "появится"? Эта возможность уже есть. Владелец точки доступа решает будет он отдавать контракт или нет.
То что сейчас он делает вид что не может этого - не делает ситуацию лучше.
Не хочу расстраивать, но ЦП есть в блокчейне биткойна
У той же ipfs есть blocklist'ы в том числе по умолчанию. см например https://github.com/ipfs-inactive/faq/issues/176 и https://blog.ipfs.tech/2023-content-blocking-for-the-ipfs-stack/ правда gateway не обязан следовать им...
Этериуму это не помешало. Когда нашли серьезную проблему в смарт контракте, этериум форкнули а закрытый контракт вернули.
Ну, решение в виде форка всегда будет означать, что на классической версии всё осталось по-прежнему. Это не полное и бесконтрольное руление без последствий в виде новой валюты со старыми правилами.
Вовсе нет. Сделать форк, при желании, можно в любой момент, если это опессоурс. А если другие участники не поддержать форк то ему грош цена. Тот же этериум классик значительно дешевле.
Ну так это решение сообщества. В одном случае оно одно, в другом другое. Тут нет предопределённости. Посмотрел сейчас курс Этериум Классик - 20,63 USD, не то чтобы прям грош, это по-прежнему больше стоимости любой фиатной валюты во много раз. Bitcoin Cash хоть и сильно уступает битку в стоимости, но в рейтинге всей крипты по стоимости входит в топ-5/топ-10 самых дорогих, в зависимости от того, включать ли туда биржевые монеты типа BNB и прочие вторичные вещи. Ну даже если ничего не исключать - 6 место, никакой не грош (а у Этериум Классик 16 место - то есть входит в топ20 самых дорогих криптовалют мира).
Ну то есть я не вижу в форках сценарий, в котором вторая монета не сможет отыграться, или что она рухнет совсем в ноль - тем более у нас уже есть долгая история таких монет, и крушения в ноль нет и за долгие годы. Они на втором плане, да, но с нулевой ценностью.
Как будто давно было понятно, что это возможно? https://safe.cnews.ru/news/top/2018-03-21_v_blokchejne_bitkoina_najdeny_obraztsy_detskoj
Что дальше? Хранение вредоносного кода в числе пи?
Однажды придумают внедрить в крипту крипто-крипту. Паразитный код для вычисления другой крипты. Или этой же, но для другого хозяина.
А вам слабо, господа програмисты?
Однажды придумают внедрить в крипту крипто-крипту. Паразитный код для вычисления другой крипты. Или этой же, но для другого хозяина.
Пффф, это слишком просто. Вот внедрить в крипто-крипту крипто-крипто-крипту... Паразито-паразитный код для вычисления другой крипто-крипты. Или этой же, но для другого хозяина другого хозяина. :)
Хотя, это тоже слишком просто! Вот внедрить в крипто-крипто-крипту крипто-крипто-крипто-крипту...
Сервер с воровайкой конечно же русский. Гордимся)
О том, что в блокчейне можно хранить вредоносное ПО или нелегальный контент давным-давно известно. Об этом еще десять лет назад предупреждал Интерпол на конференции Black Hat Asia 2015, проходившей в Сингапуре. И способов стереть эту информацию исследователи безопасности, работавшие на Интерпол, не нашли.
Проблему можно решить только через репутацию источников информации, которая на фундаментальном уровне связана с достоверностью информации, поскольку высокая репутация может быть только у тех, кто говорит то, что делает и делает то же, что и говорит. В общем, это длинная цепочка причин и следствий и здесь предстоит большая коллективная работа, общий план которой подробно описан в этой статье https://habr.com/ru/articles/874440
А зачем это делать? Почему бы тот же кусочек кода не вставить в этот js напрямую, чтобы он не делал лишний сетевой вызов?
Если идея в том, чтобы обойти какой-то pattern matching антивируса, так он же сможет матчить и по этому константному адресу 0x7f36D9292e7c70A204faCC2d255475A861487c60
В чем профит?
Я нашёл другой перевод, где приводят такое разъяснение:
Код, полученный из BSC, так же внедряется на страницу, чтобы вызывать скачивание полезной нагрузки третьего этапа, на этот раз с управляющего сервера злоумышленников. Адрес этого сервера берется непосредственно из блокчейна, поэтому злоумышленники могут легко и часто менять его для обхода блокировок.
<...>
Когда один из доменов злоумышленников обнаруживают, они просто обновляют цепочку, заменяют вредоносный код и связанные домены, продолжая атаку практически без перерыва. Кроме того, за внесение таких изменений не взимается плата, поэтому хакеры могут злоупотреблять этой системой столько, сколько им нужно.
Получается, они используют записи в блокчейне, как практически бесплатное хранилище данных доступа к серверу с полезной нагрузкой.
Он создаёт новый смарт-контракт, инициализируя его с контролируемого злоумышленником адреса в блокчейна
Ребят... Этот код просто делает JS-обертку над уже существующим смарт-контрактом, который как раз и расположен в блкочейне под указанным адресом. Через эту обертку он делает запросы к этому существующему смарт-контракту. Она просто для удобства, даже не является обязательной.
Он не создает смарт-контракт. И уже точно не "инициализирует его с контролируемого злоумышленником адреса". Как можно что-то инициализировать с чужого адреса? И уж тем более - с чужого адреса, который контролирует кто-то другой?
Уф, переведите этот блок через что-то другое.
Ну такое себе... Обращение к контракту в блокчейне всё равно через инжекцию кода. Но если у нас прокатила инжекция кода, нас нахлобучат и без блокчейна.
34
Чем-то это напоминает ситуацию с фрагментами древних вирусных ДНК в составе ДНК людей.
Вредоносный код навсегда сохранили в блокчейне