LINUX.ORG.RU

Атака на пакет arrayref Rust

 , , ,


0

3

Атака на цепочку поставок: вредоносный код в crates.io через пакет arrayref

20 августа 2026 года Команда безопасности Rust (Rust Security Response Team) сообщила об обнаружении вредоносных пакетов в реестре crates.io, связанных с популярной библиотекой arrayref.

Что произошло

20 августа 2026 года в 7:15 UTC команда получила сообщение о том, что пакет proc-macro1 является вредоносным. После проверки выяснилось, что его build-скрипт загружал вредоносное ПО.

Пакет proc-macro1, а также связанные с ним proc-macro-en, aovine, arone, aronenao и tinymember были удалены из реестра.

Дальнейшее расследование показало, что широко используемый пакет arrayref был недавно перевыпущен с добавленной зависимостью от вредоносного proc-macro1, при этом последние версии были помечены как yanked. Команда удалила вредоносную версию и восстановила ранее ошибочно отозванные версии.

Аналогичным образом пострадали другие пакеты того же автора — internment и append-only-vec. По ним были приняты те же меры. Аккаунт автора заблокирован в качестве меры предосторожности. По имеющимся данным, сам автор arrayref не действовал злонамеренно — вероятнее всего, были скомпрометированы его компьютер или учётные данные. Команда пытается связаться с ним.

Что нужно сделать пользователям

Рекомендуется проверить локальные зависимости на предмет использования следующих вредоносных версий, удалённых с crates.io:

  • append-only-vec@0.1.9
  • arrayref@0.3.10
  • internment@0.8.7
  • proc-macro1, proc-macro-en, aovine, arone, aronenao, tinymember (любые версии)

Проверить наличие этих пакетов в локальном кэше можно следующей командой:

find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

Благодарности

Команда Rust поблагодарила исследователей Nextron Systems GmbH за первоначальное обнаружение проблемы и сообщение о ней, а также сотрудников, участвовавших в устранении инцидента.

>>> Источник



Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от vbr

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

mittorn ★★★★★
()
Ответ на: комментарий от sunjob

тогда теряется смысл самого слова «прогресс/наработки/база»…

Можно копипастить нужные куски, адаптируя их потом. Но в целом - да, теряются. Может оно и к лучшему? Кучу домов сегодня строят концептуально так же, как и 2000 лет назад. Привозят кирпичи и кладут стены. Есть, конечно, и другие технологии, но в общем и целом как будто бы в основном всё строят с нуля. А прогресс заключается больше в материалах, расчётах.

в таком случае, мы-бы до сих пор сидели на самопайных «персональных компьютерах» (каждый под свой нос)

Не очень понял аналогию. Например если посмотреть на материнскую плату любого компьютера, прекрасно видно, что она сделана «с нуля». Кто-то сидел и разводил её, каждый резистор и конденсатор сажал на своё место. Есть какие-то референсные дизайны, но это так, пример использования, какая-то начальная точка отсчёта. А CPU в этой аналогии это, например, ОС. Огромный кусок функционала, который мы используем как есть.

имхо - нужен контроль над «кубиками», на базе которых мы создаем «последующие кубики», это однозначно!

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

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

vbr ★★★★★
()
Ответ на: комментарий от vbr

Запихивание загрузчика библиотек в libc было ошибкой.
Ещё там есть проблема глобального поиска символов - символы ищутся без привязки к библиотеке.
Привязка к версиям частично решает эту проблему, но очень окольным путём и загрузка нескольких версий glibc что-нибудь да поломает

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

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

С другой стороны если это исправление безопасности, то откладывать его на 24 часа будто бы тоже не очень хорошо.

vbr ★★★★★
()
Ответ на: комментарий от LightDiver

Есть теория, что эти вот рекомендации про «не надо преждевременной оптимизации» пишут чтобы избавитсья от конкурентов.

Эти рекомендации писались вот прямо совсем не про это. Дай Бог памяти, писал это Мартин в Чистой Архитектуре. И писал он про то, что:

  • Перед тем, как что-то оптимизировать, надо сначала найти узкое место (профайлинг)
  • Перед тем, как оптимизировать функцию, сначала поймите, что она делает. (разбирался случай оптимизации функции ожидания).

Продумывание архитектуры не является преждевременной оптимизацией. Даже необходимость подумать о том, как лучше реализовать конкретную функцию, тоже не является преждевременной оптимизацией. Хотя тут уже на тоненького. Я думаю, Мартин от современного состояния дел сильно бы опечалился.

bbc69
()
Ответ на: комментарий от unC0Rr

Если у тебя в проекте зависимостей (включая вложенные) 100+, то ты будешь доверять ему по-умолчанию. Да даже 20+ вряд ли кто-то будет смотреть, что там в зависимостях.

bbc69
()
Ответ на: комментарий от CanisDirusLeidy

We should forget about small efficiencies, say about 97% of the time

Я бы сказал, что он писал это давно, когда люди вообще об оптимизации думали. Думаю, сейчас совсем другой корень всех бед.

bbc69
()
Ответ на: комментарий от Bad_ptr

Ага, вирусы такие: «Да я не вирус, мне просто прогу пропатчить, чтобы ключи не требовала!». И антивирус такой: «Проходите!»

bbc69
()
Ответ на: комментарий от dynamic_cast

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

Тебя напрягают вопросики, а -> вместо . не напрягают?

WatchCat ★★★★★
()
Ответ на: комментарий от sena

Я на расте не писал, но то что я читал о нём, говорит как раз о заметно большей сложности. И это если забыть о том, что большинство кода уже написано на с/c++

«Мне сосед напел». Ясно-понятно.

WatchCat ★★★★★
()
Ответ на: комментарий от Bad_ptr

А, то есть твой антирус будет точечно работать только для crates.io? А как быть с остальным? NPM? Питон? В целом безопасность линукса? Или под каждую ситуацию свой антивирус, который на серверах?

Хорошо, ИИшка начала проверять креэтсы. Теперь она не пускает твой код, ну вот потому что. Ну не нравится он ей. Например, ты хочешь залить модуль управления хоткеями, а это небезопасно.

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

Теперь она не пускает твой код, ну вот потому что. Ну не нравится он ей.

пишешь в форму обратной связи живому человеку с объяснением ситуации

Bad_ptr ★★★★★
()
Ответ на: комментарий от Bad_ptr

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

bbc69
()
Ответ на: комментарий от bbc69

Тогда какая разница, скачал ты вручную эти зависимости или автоматически? Так и так риск одинаковый.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Никакой. Ровно как и смысла спрашивать про доверие нет.

bbc69
()
Ответ на: комментарий от doomer

Я думаю что и есть. Просто в отсутствии централизованной репы никто про это не знает. В дельфях вот точно было, AIMP так однажды заразили.

peregrine ★★★★★
()
Ответ на: комментарий от sena

Начать сложнее чем на си и на плюсах. Когда начнёшь серьёзный код писать окажется что раст гораздо легче, чем си и плюсы, потому что строже. От раста голова болит на этапе компиляции, у сишки в рантайме, когда память течёт, баги есть, а найти их сложно и приходится вплоть до ассемблера и дампов памяти изучать всё.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от bbc69

Пусть твой Боб Мэрлин подавится уже какой-нибудь своей книжкой, достал дед сей, ей богу

BruteForce ★★★★
()
Ответ на: комментарий от peregrine

Сравнения странные. Сишка это по сути высокоуровневый ассемблер. Она была очень востребована и актуальна во времена, когда оказалось, что Unix можно разрабатывать не на чистом ассемблере и при этом оверхед приемлимый при значительном улучшении читаемости кода и скорости разработки, Для современных сложных программ Сишка подходит плохо, поэтому она и эволюционировала в С++. А вот сравнение Rust с С++ уже очень не в пользу ржавого. Ту самую безопасность памяти легко гарантировать в С++ и много чего ещё.

chikanuc
()
Ответ на: комментарий от peregrine

Rust это попытка создать язык, сравнимый по простоте с С, но без его основного недостатка - отсутствия каких-либо средств контроля памяти. Посыл хороший, но в итоге появился франкенштейн, который по сложности уже догоняет С++ а при этом лишён и половины его возможностей.

chikanuc
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.