В PyBitmessage (https://github.com/Bitmessage/PyBitmessage/), эталонной реализации клиента для пересылки сообщений в децентрализованной p2p-сети Bitmessage, выявлена (https://bitmessage.org) критическая уязвимость, позволяющая удалённо выполнить сторонний Python-код на стороне пользователя. Проблема устранена в выпуске 0.6.3.2 (https://github.com/Bitmessage/PyBitmessage/releases), но имеются сведения об организации атаки по похищению файлов с кошельками Electrum, которая началась ещё до публичного раскрытия сведений об уязвимости. Уязвимости подвержены только ветки 0.6.2 и 0.6.3, в 0.6.1 проблема отсутствует. Всем пользователям уязвимых версий PyBitmessage рекомендуется срочно перегенерировать ключи и сменить пароли.
Проблема вызвана (https://github.com/Bitmessage/PyBitmessage/commit/3a8016d31f...) применением функции eval() в коде, в которой выполнялось содержимое, составленное на основе внешних данных. Злоумышленник мог отправить сообщение, приводящее к выполнению произвольного Python-кода. Уязвимость активно использовалась для копирования файлов с кошельками ("~/.electrum/wallets/") с системы пользователей. В ходе атаки также зафиксирован запуск бэкдора для организации доступа извне, позволяющего получить содержимое любых файлов в системе.
Атаке подвергся (https://www.reddit.com/r/bitmessage/comments/7xaplc/in_case_.../) в том числе Peter Šurda, создатель Bitmessage, ключи которого были скомпрометированы. Тем не менее, судя по всему, основной целью атаки стали распространители вредоносных шифровальщиков, которые в последнее время активно используют Bitmessage для организации каналов связи с жертвами.
Децентрализованная p2p-сеть Bitmessage использует похожие на Bitcoin принципы построения распределённой шифрованной цепочки блоков, но вместо хранения информации о денежных транзакциях, ориентирована на пересылку сообщений. Сообщения в Bitmessage рассылаются широковещательно, но только получатель может расшифровать адресованное ему сообщение. Адресат не указывается, поэтому каждый участник получает все сообщения в сети и пытается расшифровать каждое сообщение и если сообщение адресовано ему, то расшифровка удаётся и в хранилище сообщений добавляется подтверждение получения. Если сообщение не было расшифровано в течение двух дней, оно удаляется из распределённого хранилища.URL: https://www.reddit.com/r/bitmessage/comments/7xaplc/in_case_.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=48080
> eval()Игрушечные языки такие игрушечные.
В своё время была истерия по поводу goto в результате которой про эту команду уже не каждый программист и знает-то иначе кроме как из анекдотов.
Может стоит среди скриптовиков поднять такую же бучу по поводу eval?
> goto в результате которой про эту команду уже не каждый программист и знает-тоЭто копипастакодеры, а не программисты.
...
__label__ exit;for(u32 foo = HUGE; foo; --foo){
for(u32 bar = HUGE2; bar; --bar){
if(unlikely(cond(bar)){
foobar(foo, bar);
goto exit;
}
}
}
exit:
...
И?
Вложенный цикл лучше в отдельную функцию выделить, и goto станет не нужен.
лучше в отдельную функцию выделить - и это будет яркий пример костыля(лишь бы не использовать goto). и дело не только в затруднении читаемости кода на ровном месте.ясное есть языки без goto. и ничего.
я последние годы пишу на С и asm. в воображаемом мире пугливые розовые единороги решают все свои проблемы избежанием goto.
в реальном мире есть куча куда как более глубоких логических промахов, с которыми не всегда ясно, что вообще делать.
> в воображаемом мире пугливые розовые единороги решают все свои проблемы избежанием goto.Кстати про единорогов... Правильность кода - это не пустые слова.
Можешь хоть сколько смеяться, но когда вот такое <CENSORED> пишут не для чисто своей подделки, то за это надо бить томиком чего-нибудь этакого фундаментального по голове.
этакого фундаментального по голове - я неоднократно видел как куски <CENSORED> своими фундаментальными томами вгоняли в гроб трезвые идеи.по поводу goto - можете к слову полезть поспорить к Adam Dunkels с его protothreads (c labels as values). рассказать ему как Вы круто все знаете.
*впрочем спорить не намерен. ясное дело что в своих кодах Вы можете делать что хотите.
PS: https://twitter.com/Code_Analysis/status/963450814059696129
> Вложенный цикл лучше в отдельную функцию выделить, и goto станет не нужен.Даёшь каждому циклу по функции. А лучше - по целому классу.
... о времена, о нравы ...
...
bool cancel = false;
for(u32 foo = HUGE; foo && !cancel; --foo){
for(u32 bar = HUGE2; bar && !cancel; --bar){
if(unlikely(cond(bar)){
foobar(foo, bar);
cancel = true;
}
}
}
...
По производительности уступает варианту с goto. Всё в функцию и return - это да.
на создание дополнительной функции должны быть серьезные аргументы.добавит ли в таком случае функция ясности? точно нет. зачем тогда кого-то этим всем путать?
> на создание дополнительной функции должны быть серьезные аргументы.
> добавит ли в таком случае функция ясности? точно нет. зачем тогда кого-то
> этим всем путать?Конечно. Гораздо же лучше одна функция на тысячи две строк и с кучей вложенных друг в друга циклов. С массой goto в произвольные места. Печатаешь потом такую <censored>, прибиваешь распечатку на стену от потолка до пола и разноцветными маркерами размечаешь начала и окончания разных вложенных друг в друга циклов. Очень эффективный метод изучения того что же это <censored> делает. Прежде чем его выбросить в мусор, заменив на обозримый и читабельный код...
Гораздо же лучше одна функция на тысячи две строк - это Вы написали. Я этого не утверждал и у меня есть основания полагать, что функция по длине не должна занимать более 2 страниц.
На что, в общем-то в каждом случае есть свои стандарты написания кода.Бессмысленные обертки только добавляют путаницы.
разноцветными маркерами размечаешь начала и окончания разных вложенных друг в друга циклов - это Ваш опыт. у меня к счастью такого опыта нет.
> Конечно. Гораздо же лучше одна функция на тысячи две строк и с
> кучей вложенных друг в друга циклов. С массой goto в произвольные
> места. Печатаешь потом такую <censored>, прибиваешь распечатку на стену от потолкаВ ядре Linux полно таких goto. И ничего - всё нормально.
>> Конечно. Гораздо же лучше одна функция на тысячи две строк и с
>> кучей вложенных друг в друга циклов. С массой goto в произвольные
>> места. Печатаешь потом такую <censored>, прибиваешь распечатку на стену от потолка
> В ядре Linux полно таких goto. И ничего - всё нормально.Так это твоих рук дело, аноним? Приберись там, негоже оставлять после себя мусор и позорить хакиров 5-го «Б» на всё ядро.
> Так это твоих рук дело, аноним? Приберись там, негоже оставлять после себя
> мусор и позорить хакиров 5-го «Б» на всё ядро.Таки goto обычное дело в обработке ошибок. Потому что если все профакапилось, вложенными циклами не отвертишься, знаешь ли.
> Таки goto обычное дело в обработке ошибок. Потому что если все профакапилось,
> вложенными циклами не отвертишься, знаешь ли.Уговорил.
>[оверквотинг удален]
> for(u32 bar = HUGE2; bar && !cancel; --bar){
> if(unlikely(cond(bar)){
>
> foobar(foo, bar);
>
> cancel = true;
> }
> }
> }
> ...Сами догадаетесь, почему этот метод является ущербным?
for(u32 foo = HUGE; foo; --foo){
for(u32 bar = HUGE2; bar; --bar){
if(unlikely(cond(bar)){
foobar(foo, bar);
foo = 0;
break;
}
}
}
> foo = 0;классический костыль. руки отрывать.
GOTO -- нормальная команда. Без нее нет жизни. Для выскочить из вложенного цикла при синтаксическом разборе вообще нет альтернативы. Везде, где использование GOTO дает выигрыш в ясности и производительности, его нужно использовать.
Ты забыл сообщить нам что вода мокрая и у квадрата целых 4 прямых угла.
> вложенного циклаА нечего вложенные циклы лепить. Функциональщики и вовсе без них как-то живут, и ниче.
Функциональщики и прочие маргиналы неплохо обходятся и без программирования вообще - пишут полторы хрени на всю планету, которые погоду не делают. А чтобы страдать этим - используют софт и операционки писаные на чем-нибудь "менее функциональном" и все такое.С питонистами тоже прикольно вышло. Они так на пхп пшикали, а оказалось что от пхпшников отличаются только названием своего фетиша.
> Функциональщики и вовсе без них как-то живутУ функциональщиков есть лямбды
> GOTO -- нормальная команда. Без нее нет жизни. Для выскочить из вложенного
> цикла при синтаксическом разборе вообще нет альтернативы. Везде, где использование GOTO
> дает выигрыш в ясности и производительности, его нужно использовать.Если синтаксический разбор делать yacc-ом, то все goto он создаст сам, а в коде на нём уже никакие goto не нужны. Как следствие - исходный код чист, но не совсем на C ;)
Согласен. В школьные годы всегда считал, что в каждом нормальном языке должна быть возможность загрузить код на нём из строки, и GOTO мне нравилась, но только чуть подрос - сразу понял, что и то и то - зло.
> но только чуть подрос - сразу понялНасколько "чуть"? Полгода хотя бы прошло?
Про ассемблерный JMP такой бучи не было
> Про ассемблерный JMP такой бучи не былоВот да, только хотел предложить убрать JMP и оформлять всё CALL/RET'ами.
Т.е. использование eval() вас смущает, а широковещательная рассылка сообщений с попыткой их расшифровки и масштабирование этой схемы на весь мир - нет? ;-)
> а широковещательная рассылка сообщений с попыткой
> их расшифровки и масштабирование этой схемы на весь мир - нет?
> ;-)И что именно там смущать должно?
>> а широковещательная рассылка сообщений
> И что именно там смущать должно?Может то же самое, что и вариант чисто широковещательного TCP без маршрутирования? Пускай все пакеты получают все узлы, кто получил чужой - просто дропает.
> Т.е. использование eval() вас смущает, а широковещательная рассылка сообщений с попыткой
> их расшифровки и масштабирование этой схемы на весь мир - нет? ;-)Возможно, "изучение" протокола по новостям на опеннете - не самый лучший подход?
Автор(ы), как минимум, подумали над этим:
https://bitmessage.org/bitmessage.pdf (whitepaper)
> 4. Scalability
> If all nodes receive all messages, it is natural to be concerned about the system’s scalability.
> To address this, we propose that after the number of messages being sent through the Bitmessage network reaches a
> certain threshold, nodes begin to self‐segregate into large clusters or streams. Users would start out using
> only stream 1. The stream number is encoded into each address. Streams are arranged in a hierarchy.Другое дело, что лично меня, в первую очередь бы смущал этот самый "Proof of Work" перед отсылкой (если по памяти, ибо перечитывать еще раз неохота) , который должен работать с адекватной скоростью и на лэптопе и на смартфоне.
Слишком сложный PoW – и на смартфоне фиг воспользуешся. Слишком простой (или более-менее ложащийся на GPU) – и здравствуй атака Сивиллы, привет ddos и банальный спам.
> Т.е. использование eval() вас смущает, а широковещательная рассылка сообщений с попыткой
> их расшифровки и масштабирование этой схемы на весь мир - нет? ;-)Ты все правильно понял, у штуки проблемы с масштабированием. В конце концов хипстеры заметили что атакующие могут ресурсы жрать, всего-то рассылая сообщения. Они разлетятся по всей сети. Сотни трафика и места на диске под хранение спама. У вообще всех. От 1 спамера. Это ли не круто?
Что сделали бидонохипстеры? Поделили хомяков на группы, тыщ по 5. Чтобы спамили не совсем броадкастом а группе до 5000 хомяков. Но анонимность стала не очень анонимная, адресат вычисляется 1 из 5000. Это тоже не очень, но лучше чем 1 из 7 миллиардов. И proof of work, как же без него. Поэтому сообщение отсылается минут 10 и дико грузится проц. Иначе заспамливают. Не всю сеть так 5000 хомяков за присест, что тоже неплохо.
Поэтому на практике это работает со скоростью дохлей емыла и офгенно грузит проц. И вообще эта штука всем своим видом показывает как именно питон не тормозит.
Эталон дырявости.
Питон, одним словом.
Ага, не проверите границы массивов в С - привет переполнение, рут права... Не в питоне дело, а в людях.
Используй range-based for loop, передавай по ссылке, и не будет переполнения.
Так вот в чистом Си range-based и нет, она только в плюсах.
В Си есть макросы.
Python лучше сравнивать с C++. Си - скорее системный язык.
> В Си есть макросы.Для любителей хайлевела на си есть libcello. Там и итераторы есть, и лямбды, и чего там еще. Си вообще штука довольно гибкая на самом деле.
>> В Си есть макросы.
> Для любителей хайлевела на си есть libcello. Там и итераторы есть, и
> лямбды, и чего там еще. Си вообще штука довольно гибкая на самом деле.Но и скорость у этого либчелло соответствующая, ближе к жабе и ЖС.
Сборщик мусора и куча проверок в рантайме не располагают к особой быстроте.
Тогда уж проще сразу какой нить ним или валу взять - там и ЯП помощнее, не такой васикоподобный. И народу побольше.А гибкость сишная, которая на "макросах", скорее из разряда "да, чисто теоретически можно, но ... "
Макросам для таких кунстштюков вне хеловорлдов очень желательна как минимум гигиеничность.
И нормальная поддержка дебажинга. Что, как и где раскрывается - c этим у связки классического, отдельного от компилятора, препроцессора в качестве макросдвижка вообще-то полная ж*па.
Выручает только то, что современные компиляторы сами себе препроцы и дебагинфу соотв. записать могут.
ну вот и пользуйтесь плюсами
... а мы будем и дальше за границы массива выходить. Думаю так задумывалось
Э... кем задумывалось? Если обо мне речь - то наоборот, я не вижу ни одной причины писать на сях там, где можно писать на плюсах. Ну, или D в режиме "better C" - и там и там можно получить сравнимую проиводительность и потребление с сильно уменьшенными шансами на сишные ошибки и гораздо лучшую читабельность.
На сях в коде больше народа потом может разобраться. На плюсах заканчивается тем что наворачивают зубодробильные абстракции. Это хорошо для улучшения эффективности 1 програмера. Но заканчивается тем что проект дохнет вместе с потерей интереса этого програмера, потому что кроме него вообще никто не может вштырить в эти абстракции. Получается кусок кода который некому девелопать или майнтайнить. Фэйл.С сишным кодом это не характерно - там крутые абстракции не наворачивают, поэтому шанс что знамя подхватят намного выше.
Питон - высокоуровневый язык. И программист, и пользователи за это платят гигантскую цену - капитальный жор памяти и ресурсов итоговым приложением. И при этом питон даже не обеспечивает безопасноть...
удивленно глядя на пару питоновских сервисов (не микро, в смысле, не падают, их не надо быстро-быстро-клонировать) - что я делаю не так, что у меня никаких ужасов не наблюдается?> И при этом питон даже не обеспечивает безопасноть...
к счастью. А то зачем нам еще одна жаба-EE?
Дело не в Ваших сервисах. Дело в том, что подобные вещи пропагандируются и пропихиваются как стандарт разработки прикладного ПО массового потребления. И в результате экономия нескольких часов программистов выливается в миллионы потерянных минут пользователями по всему миру. Примеры: ubuntu software center, который запускался минутами, и который Canonical так и не удалось доработать до приемлемой скорости работы; скайпом (я знаю что он не на питоне) и т.д. При том общепризнанный факт - питон не быстрый на столько, что это надо учитывать.
убунтовцы упаковщики, а не разработчики.
если у них нет денег, чтобы спроектировать и заплатить за нормальный Sowftware Center, это не значит, что "стандарт".
Вон стим почему-то на спп написан и работает хорошо. А это гораздо более массовый продукт, чем сама убунта.
Стим работает приемлемо. Не так плохо, как скайп, но и не хорошо. При том до этого лет 10 работал плохо.
> Стим работает приемлемо. Не так плохо, как скайп, но и не хорошо.
> При том до этого лет 10 работал плохо.Как угодно но игроделы это все-же не хипстеры. И плохо, не плохо, напиши лучше и покажи валву как это делать правильно. А то можно подумать у valve прямо конкурентов толпа.
> И в результате экономия нескольких часов программистов выливается в миллионы потерянных минут пользователями по всему миру.Всё правильно. Поэтому надо строить фабрики по сжиганию программистов. Слишком их много стало, обленились и обнаглели.
Точнее не в людях, а в пороге вхождения.Пока научишься на С делать что-то удобоваримое, поневоле изучишь базовые понятия правильного кодирования; а в питонах всяких или, прости господи, джаваскриптах - xуяк, xуяк и ты уже что-то написал и запустил, можешь гордиться и распространять. Не имея вообще никакого понятия о правилах хорошего тона.
Беда.
> Питон, одним словом.А что скажут анонимные аналитки о недавней уязвимости в КДЕ?
https://www.opennet.dev/opennews/art.shtml?num=48038
> Уязвимость в KDE, позволяющая выполнить код при подключении внешнего носителя
> Если метка раздела VFAT содержит символы `` или $(), то при монтировании через диалог с уведомлением о подключении устройства данные символы интерпретируются как команды shell.Тоже питон виноват? :)
А вот в Rust такого не было бы!
https://doc.rust-lang.org/std/process/struct.Command.html#me...
Втыкал флешку в Plasma 5.10 с меткой тома `kcalc`, не запускается. Похоже, что именно в 5.12.0 эту "фичу" запилили.
Кучу лет пишу на Питоне, и до сих пор не встречал ситуаций где нужно было бы использовать eval
Это Вы эталонную реализацию клиента для p2p-сети Bitmessage ещё не пробовали писать! Вот там без eval-а никак!
Если без eval никак да еще и со взодящими данными то это уже вопрос компетентности писателя
Не знаю как там с компетентностью писателей, но твой детектор сарказма явно неисправен :)
Говорить о компетентности среди гвидобейсиководов, это как говорить в доме повешенного о верёвке.
> Говорить о компетентности среди гвидобейсиководов,https://www.opennet.dev/opennews/art.shtml?num=48038
> Уязвимость в KDE, позволяющая выполнить код при подключении внешнего носителя
> Если метка раздела VFAT содержит символы `` или $(), то при монтировании через диалог с уведомлением о подключении устройства данные символы интерпретируются как команды shell.Всегда знал, что кедерасты на самом деле латентные гвидобейсиковцы!
Пишу на perl и не один раз встречал ситуацию где оптимальнее использовать eval. На самом деле ничего страшного нет если уметь пользоваться. Если уж совсем расширять возможности, что perl позволяет, к примеру, блочить/разрешать на выполнение определенных операторов. Ругаться на eval - это как ругаться на ножи, это как инструмент (как goto). Дело в том кто и как используется, а проблема в инструменте.
Иногда (в ИТ — очень часто) проблема в инструменте. Точнее в том, что не существует способов не дать обезьяне в руки гранату. А дальше уже обезьяна найдёт способ отыскать в гранате чеку.
Вы видите проблему в инструменте, но проблема возникает чуть раньше - когда обезьяна попадает в ИТ индустрию. Если сделать невозможным попадание обезьян в ИТ, то проблем в инструменте нет. Так что ..
> Вы видите проблему в инструменте, но проблема возникает чуть раньше - когда
> обезьяна попадает в ИТ индустрию. Если сделать невозможным попадание обезьян в
> ИТ, то проблем в инструменте нет. Так что ..И кто же тогда будет писать и переписывать "приложения" для браузеров, менять местами кнопочки, скруглять и распрямлять рамочки?
> И кто же тогда будет писать и переписывать "приложения" для браузеров, менять местами кнопочки, скруглять и распрямлять рамочки?Действительно, я упустил из виду необходимые и важные для обезьян вещи.
> Вы видите проблему в инструменте, но проблема возникает чуть раньше - когда
> обезьяна попадает в ИТ индустрию. Если сделать невозможным попадание обезьян в
> ИТ, то проблем в инструменте нет. Так что ..А как это сделать? Раньше этому препятствовал сравнительно высокий порог вхождения. Сегодня не препятствует ничто. Фреймворки «Для обезьян» и книги «Как стать гуру написания гoвнoкoда за 3 часа» общедоступны.
заменить их работу алгоритмами
> Иногда (в ИТ — очень часто) проблема в инструменте. Точнее в том, что не
> существует способов не дать обезьяне в руки гранату. А дальше уже
> обезьяна найдёт способ отыскать в гранате чеку.Проблема не в инструменте. Проблема в доступе обезьяны к таковому.
Вы не путайте перловый эвал, который eval { code here ; } с питоновским эвалом, который принимает строку.
> Вы не путайте перловый эвал, который eval { code here ; }
> с питоновским эвалом, который принимает строку.подскажите в чем отличие?
Перл может евалить как выражение, так и блок по сути
это вопрос контекста
~ $ perldoc -f evalДостаточно исчерпывающая дока.
В перле две формы eval'a, если что: eval { }, оно не влияет на скорость выполнения и используется как замена эксепшонов, и обычный медленный eval "string" (широко используется для загрузки модулей в рантайме, например).
Честно говоря не встречал в перле случаев, когда
евал нужен не для обработки исключения.
Я инженер правда, не зарабатываю деньги на перле,
но он мне необхадим как язык. А скажите, реально,
когда еще оптимально использовать этот оператор?
Так, чисто опыта для.
Выше, #106
> Кучу лет пишу на Питоне, и до сих пор не встречал ситуаций
> где нужно было бы использовать evalЛибо вам не надо было встраивать бекдоры, либо вы взяли что-то похитрее вроде pickle
на самом деле pickle для внешних данных это тоже бекдор :)
Если нужно обмениваться сложными данными - используйте json/xml/yaml и т.п. ну или свой язык реализуйте...
> на самом деле pickle для внешних данных это тоже бекдор :)Именно так. Но половина пакетов поставляется с пиклами. Вторая половина не имеет механизмов серализации вообще и пишет в доках "для сериализации юзайте пикл".
> Если нужно обмениваться сложными данными - используйте json/xml/yaml и т.п. ну или
> свой язык реализуйте...Понимаешь, веб-макака, шифрованные сообщения и криптографические ключи не очень хорошо текстом представляются. Самое простое UU кодирование раздувает все на треть и не хватает звезд с неба по скорости кодирования и декодирования. А более наивные и простые реализации с например представлением хекса как текста - раздувают все раза в 2-3. А в штуке типа сабжа весь протокол состоит из вот этого вот.
Поскольку броадкаст - если ты все это в json засунешь или тем паче в XML, ты утонешь в трафике. Которого станет в разы больше, при том что и так было дофига. И проц оно и так грузило очень даже, а еще json из питона на скорость парсить, или тем более XML - ну, э, оно тогда proof of work по прожорливости начнет затыкать.
Отсюда мораль: питон не особо подходящий инструмент для перекидывания шифрованными сообщениями по сети. Если сильно долбануться, это можно даже на JS и баше. Но для этого надо реально долбануться.
Вот вам и типа безопасные языки. И они от уязвимостей не застрахованы, а то тут принято на Сишечку наезжать.
Фронты производительности, потребления ресурсов и безопасности питона прорваны. Кросплатформенности никогда и не было. Теперь у питонистов один аргумент - скорость разработки. И то C++ Qt ставит его под большой вопрос.
Такое и других скриптовых языков может касаться и исполняемой в JVM Жабы тоже.
php не менее безопасный. И (местами) более производительный. А толку?
Eval внешних данных - это не уязвимость.
Это бэкдор.
Бэкдор - это если добавлено умышленно с целью получения несанкционированного доступа. И я в жизни не поверю, что рядовой аноним опеннета владеет ясновидением и может гарантировано отличить "умышленно" от "неумышленно"
> Бэкдор - это если добавлено умышленно с целью получения несанкционированного доступа."Правдоподобное отрицание" (plausible deniability), как термин, не зря придумали.
PS:
> И я в жизни не поверю, что рядовой аноним опеннета владеет ясновидениемЗачем владеть?
% ll /dev/crystalball
crw-r----- 0 ??? ??? 0x?? Jan 31 2021 /dev/crystalball
% ll /lib/libastral*
-rw-r----- 777 ??? ??? ??? Feb 29 2033 /lib/libastral.so.42
Правда да, есть временные сложности с доступом к оборудованию.
> Проблема вызвана применением в коде функции eval(), в которой выполнялось содержимое, составленное на основе внешних данныхвот бывают же идииоты..
человеку не хватило возможностей языка СВЕРХвысокого уровня и он решил расширить их за счёт eval()
Люди не хотят думать и работать. Поэтому питон, электрон и им подобные в тренде. Вот только выясняется, что не панацея, что думать то все равно надо...
Мозгов ему не хватило
Ничего страшного, там ещё есть запас в 2 eval'a, для любителей похакать:https://github.com/Bitmessage/PyBitmessage/search?q=eval&typ...
Второй вполне себе напоминает бэкдор:address = userInput("What address would you like to subscribe to?")
...
address_information = api.decodeAddress(address)
address_information = eval(address_information)
Это божественно
> Это божественноС каких пор codermonkey относят к священным животным?!
> 2018
> уязвимость с eval
>> 2018
>> уязвимость с evalНе просто уязвимость с eval, а передача untrusted input для выполнения в eval.
Это отдельная, элитная категория.
~/.electrum/wallets/Они же шифрованные, пока пароль не введёшь Electrum не знает что с ними делать. Толку их копировать?
Ну может пароль в глобальной переменной? скриптонщиков всего можно ожидать. Тогда в контексте eval он будет. Осталось его только вывести как и содержимое кошельков.
прям все шифрованные?
а дальше беспощадный брут
> а дальше беспощадный брутДелать больше нечего? Вешаешь кей-логгер. Если не терпится, можно спровоцировать ребут. eval в дикой природе — прекрасен. </sarcasm>
я, видимо, туповат.
Поясните, пожалуйста, какая взаимосвязь между
PyBitmessage (никогда о нем не слышал)
и Electrum (использую)
кроме как язык ЯП?
То, что Bitmessage используют в основном те, кто занимается криптовалютами - оно и родилось из разговоров на bitcointalk, если я правильно помню.
я с 2013-го года имею дело с криптой
в основном по работе
ни разу не слышал про Bitmessageчего тока люди не готовы написать на питоне :)
спасибо за инфо буду на хайпе теперь.
По-моему хайп на эту тему был лет пять назад, вместе с хайпом по поводу неймкоина, так что здесь вы чуток опоздали ;-)Есть разница между утверждением "большинство тех, кто связан с криптой, пользуются bitmessage" и "Большинство тех, кто пользуется bitmessage, связаны с криптой". Я говорил о втором - в основном это разного рода cypherpunks и прочие криптоанархисты, но и некоторые из core пользовались. Даже в BIP попало - https://github.com/bitcoin/bips/commits/master/bip-0047.medi...
> То, что Bitmessage используют в основном те, кто занимается криптовалютамиЕго пишут хипстеры и пользуются такие же хипстеры. Даже не панки. Cypherpunks при взгляде на это быстро понимают куда ветер дует и сносят от греха этот кусок питона. И таки циферпанков настолько халявно и нагло все-таки не нагревают.
> Атаке подвергся в том числе Peter Šurda, создатель Bitmessage, ключи которого были скомпрометированы.Это прекрасно и православно.
Авот на телеграме...
Минимум у одного свидетеля безопасного телеграма рвануло, найс.
Это не уязвимость, а бекдор. Если проект использует eval, compile, pickle, shelve и прочее - тут гадать не приходится - это бекдор. А те дeбилы, которые ставят какое попало гoвно из пакетов, даже не удосужившись просканировать код на предмет eval, compile, pickle, shelve, subprocess, os, cython заслуживают того, что получают.А основателя проекта надо внести в чёрный список как работника спецслужб, потому что это лично его фейл, что на code review не был завёрнут любой код, использующий опасные функции.
А теперь давайте подумаем, что с этим дерьмом делать.
IMHO выход только один - пакеты питона должны иметь манифест, в котором прописаны разрешения, и эти разрешения должны энфорситься на уровне интерпретатора. Динамические импорты, евалы и компиляция кода должны быть по умолчанию запрещены, на всё это должно быть отдельное разрешение.
Введём несколько определений.
* security context - список того, что можно делать модулю и его зависимостям. Каждому модулю назначается security context. Существует особый security context `*`, означающий "эту переменную можно читать всем контекстам".
* security marker - метка, присваиваемая каждому символу, используемая для проверки привилегий. Маркер содержит в себе два множества указателей на контекст: входное и выходное. Входное определяет тех, кто повлиял на переменную, выходное - всех, кому разрешено её читать. Все созданные в модуле переменные по-умолчанию имеют marker, входное множество которого состоит из контекста этого модуля, а выходное - из контекста "*".
* манифест - набор метаданных в декларативной форме, описывающий в том числе привилегии модуля.
* переменная a влияет на переменную b когда значение переменной b при прочих равных условиях (значения остальных переменных, отсутствие истиной случайности) зависит только от переменной a.
Примеры:
```
b=a+1
```
```
if a==0xf00c:
b*=100
else:
b*=1000
```Влияние транзитивно: если а влияет на b и b влияет на c, то a влияет на c.
При влиянии одной переменной на другую маркер влияющей переменной вливается в маркер влияемой.
* слияние маркеров. При вливании маркера a в маркер b входное множество указателей на контекст маркера b заменяется на объединение входных множеств маркеров a и b. Выходное множество заменяется на пересечение. Если выходное множество пустое, сразу происходит ошибка.
* import - использование модулем модуля.
В начале каждого исходника размещается манифест.
1 В этом манифесте перечисляются ВСЕ импорты модуля. То есть если модуль использует numpy, то об этом пишется в манифесте.
```imports numpy```2 перечисляются используемые разрешения.
Если сам модуль читает произвольные файлы, то пишется "use permission filesystem:read-any".```
def readShit(fn):
with open(fn): # проверка контекста производится при вызове open
```Если сам модуль произвольные файлы не читает, какие файлы читаются не контролирует, но одна из его зависимостей это делает и, этот кусок кода будет исполнен в ходе работы модуля, и для нормальной работы данного модуля требуется, чтобы зависимость действительно имела возможность прочитать любые файлы, то пишется
`dependency_name: uses permission filesystem:read-any`.```
from shit import loadPalletesdef a():
pals=loadPalletes()
``````
def loadPalletes():
with open(palettesDir / "palettes.sqlite") as f:
```где palettesDir может быть любой папкой в системе.
Если сам модуль произвольные файлы по своей инициативе не читает, а читает по запросу вызывающего модуля, то пишется
`provides permission filesystem:read-any`.Например,
```
from shit import loadPalletedef a(fileName):
pals=loadPallete(fileName)
``````
def loadPallete(fileName):
with open(fileName) as f:
```
.* проверка привилегий
Привилегии проверяются на этапе компиляции AST в байт-код. Без выполнения. Такая вот питонья ржавчина. Проверка привилегий происходит при вызове функций и при чтении переменных.
* привилегированные функции - функции, при вызове которых проверяются привилегии. Переменная, подаваемая на вход функции, в входном множестве security markerа не должна содержать контекстов, не имеющих этой привилегии.
Возвращаемое значение привилегированной функции имеет security marker, в выходное множество которого является подмножеством объединения входных множеств аргументов.У нас ещё есть время до python 4, так что предлагаю начать разработку системы уже сейчас.
Регаться на баг-трекере не буду, залейте туда текст этого сообщения за меня. Прошу считать текст этого сообщения общественным достоянием.
Насчет бэкдора - согласен.Насчет припарок к питону - нет. Так можно на каждый скрипт лепить сложную систему, которая не защитит в результате ни от чего. Почему не настроить профиль Selinux или Apparmor? Профиль на конкретное приложение, а не на сам питон.
> Насчет припарок к питону - нет. Так можно на каждый скрипт лепить сложную систему, которая не защитит в результате ни от чего.Сама по себе система не защищает. Зато она даёт индикацию, что может скомпромитировать модуль. Имея этот список можно уже **ать мозг разрабу напредмет того "а *ули в манифесте прописано это, ты случаем уху не ел?". Причём благодаря тому, что это энфорсится на уровне языка для вредоносности придётся задекларировать это в манифесте. То есть скрыто бекдор не внедрить, придётся написать в манифесте "мы внедрили бекдор". А проверить манифест проще и надёжнее, чем путём статического анализа выискивать бекдоры.
>Почему не настроить профиль Selinux или Apparmor? Профиль на конкретное приложение, а не на сам питон.
Вообще-то это не новая идея, в академической науке это придумали давно и реализовали в виде экспериментальных языков, как называются не помню. Хотели получить систему, позволяющие писать программы, которые доказуемо безопасны в определённом смысле. Конкретно, они имели в яп систему меток, метили секретные данные метками и доказывали, что данные, помеченные как секретные, не утекут. А потом взлетел ЯП rust, что показывает успешность такого подхода. Я предлагаю скрестить этот подход с модульностью и разрешениями.
After all, we are all consenting adults here.
Оно и видно, что доступ к кошелькам был санкционированным.
Милашка.
Как простыню бреда писать - так пожалуйста, как запостить туда, где она хоть как-то условно была бы уместна - "Регаться на баг-трекере не буду, залейте туда текст этого сообщения за меня".
> Это не уязвимость, а бекдор.Знаешь, если хоть раз в жизни bitmessage увидеть - это таки может быть и уязвимость. Он целиком являет собой кусок наколенной стремной кривизны. Так что это всего лишь вишенка на торте, а вовсе не какое-то там исключение. Протокол непродуманный, костыли навешивали по ходу пьесы и эти костыли больно лупили по практическому использованию. Чего такое удивление очередному мелкому тупняку? Эта штука целиком состоит из "сперва накодим, потом подумаем". Обычное дело для питонистов.
>Чего такое удивление очередному мелкому тупняку?Тупняк это, возможно, мельтдаун. eval же удаленной строки данных - это не тупняк, это бекдор самый натуральный, слепым шеллом называется.
> Тупняк это, возможно, мельтдаун. eval же удаленной строки данных - это не
> тупняк, это бекдор самый натуральный, слепым шеллом называется.Ты все-же посмотри код этого bitmessage, или вообще попробуй его скачать. Что тут не понятного, у автора была клевая идея. Идея даже имела некий пойнт. Но вот програмить автор кажется не умел. Да и вообще, явно подорвался кодить даже не обдумав алгоритм толком и что будет дальше. Ну и взял ЯП попроще, на примере этой "референсной реализации" как раз и поучился програмить, судя по качеству этой штуки. Так что он мог и не знать что это что-то плохое, а кодить проще.
То что untrusted данные приехавшие по сети могут быть ЛЮБЫЕ, а не те что задумано - почему-то часто оказывается откровением для начинающих програмеров. Я не знаю откуда этот тупняк берется, но любители высокоуровневых ЯП, текстовых протоколов и проч этому подвержены выше среднего, у них больше всего проблем с пониманием этого момента.