LINUX.ORG.RU

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

 , , ,


0

5

Атака на цепочку поставок: вредоносный код в 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)
Ответ на: комментарий от 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)
Ответ на: комментарий от peregrine

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

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

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

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

Уф, что так резко? Нормальная книжка и вещи там нормальные написаны.

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

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

Я думаю, что скоро всё ядро Linux перепишут на Rust'е. Я только за. Rust рулит!

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

Подходимость цепепе для 2026 крайне сомнительна, на мой взгляд.

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

Кучу домов сегодня строят концептуально так же, как и 2000 лет назад.
в основном всё строят с нуля.

как раз наоборот, дома строят опираясь на глубинные знания/опыт/наработки.
геодезия/ветер/вода/земля/сопромат итд итп
это и есть те самые «кубики».
вы представляете сколько бы стоила постройка дома с нуля?!

А прогресс заключается больше в материалах, расчётах.

тут ноборот - больше регресс (разработки/расчет/научные подход - а по факту все «рассыпается»)

... на материнскую плату любого компьютера, прекрасно видно, что она сделана «с нуля».

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

вариант, когда будет какая-то серьёзная организация, которая будет заниматься поддержкой

к этому я и пинал мумслию. но тут опять - упираемся в туже самую стену.

1. простое опен-сообщество не вытянет таких масштабов. практика показывает максимум - это библиотеку/тулкит, вроде GTK/QT (но и сами видите, во что такой опенсор превращается, когда в него вцепляются корпорации)
1е следствие: «наша» организация будет из корпорастов (как минимум управляться/принадлежать)
2е следствие: мнение «большинства» будет игнорироваться а продвигаться будет соотв. «повесточка» (systemd, pulse, wayland)
3е следствие: опенсорс останется с тем, с чем останется. самые сильные будут тянуть свои библиотеки/тулкиты (Ardour, lsp-plugins etc) - и это максимум

и «все это» опять-таки прийдет к тому-же к чему мы уже приехали (линукс/линус/ядро/софт...)

если не понятен корень мымсли:
- истинная свобода/опенсорса возможна только в гаражах/небольших масштабах
- как только «продукт» приобретает форму/ценность - приходит «бабло/корпорации» и мы приплыли

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

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

В свою очередь когда ошибки становятся частью возвращаемого типа,

Тогда мы получаем монады (функции с расширеным типом вывода)

их просто невозможно пропустить на этапе написания кода. В плюсах кстати тоже это поняли т.к. завезли expected.

Люди не спервого раза (как минимум по тому что они вводились с c++17−23) поняли что монада optional/expected − это так то довольно круто, и если в сишке появится do-нотация то будет ещё круче

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

Да, но нет. Если рассмотреть функцию guard

std::optional<void> guard(bool toggle) {
if (toggle) return;
else return nullopt;
}

то окажется что возвращаемое значение guard не важно.

guard нужен чтобы прерывать цепочку .and_then()/.transform()

tnray ★
()
Последнее исправление: tnray (всего исправлений: 1)

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

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

Любой тип, по тому что std::expected<T, E> — шаблон.

Например std::optional<const char*, unsigned short> соотвествует или значению-строкой, или ошибкой-числом

tnray ★
()

Rust просто идеально зашёл на AI-эпоху:

a) длинный и нудный синтаксис? нейронка сама сгенерирует, только логику пиши b) если скомпилировалось - то работать будет точно, memory-safe же c) если работает, и логика нормальная - то ошибок меньше будет чем на C/C++ и скорость быстрее чем на всём, у чего garbage collector

то есть получаем просто идеальный набор для нейро-слоппинга: пока не сделаешь нормально - всё равно не скомпилируется, а если уже скомпилировалось - то будет работать лучше сеньёрского кода на плюсах

Чисто «в нужное время в нужном месте»

И считай делаешь низкоуровневый, быстрый и без ошибок код с простотой как на если на JS клепать какие-нибудь там менюшки, почему Rust дико зашёл в webdev тусовке, на него очень часто с JS прыгают. Все плюсы плюсов и даже больше (опять-таки, memory-safe), при этом в AI-эпоху на Rust разрабатывать просто нереально просто.

А касательно самой новости - ну что поделать, нет у opensource тусовки ресурсов, что бы настолько внимательно всё проверять. Но, я думаю, выводы сделаны, Rust-тусовка, в целом, крайне адекватная, и будут приняты меры, как такое предотвратить в дальнейшем. Может будет введена более строгая инспекция пакетов, ценой более медленного обновления, в Linux-же все подобные вопросы давно решены, как-то найдут выход и здесь.

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

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

У раста наверняка есть плюсы, но таковые есть у любого ЯП. Но как Ява на заменяет Си, так и Раст его не заменит.

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

Да никто не собирается C/C++ заменять. Тут суть не в этом. Суть в том, что компилятор не даёт писать тебе код с ошибками выделения памяти. То есть можно прийти из любого языка со сборщиком мусора - и простыми словами, не напрягаясь, сразу писать код работающий на скорости C/C++, при этом без ошибок выделения памяти. При этом тебе не нужно этим голову забивать, достаточно выучить borrow checker, и ты сразу уже на уровне сеньора с огромным опытом пишешь. Из минусов только длинный синтаксис, что в эпоху AI и не минус. Да и правильно настроенная IDE эту «проблему» (хотя это скорее не проблема, а особенность) тоже решает. Отсюда просто взрывная популярность языка в webdev тусовке, и много где ещё.

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

Много чего. Начиная с того что далеко не каждый код пишется для ОС со страничной памятью.

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

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

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

соотвествует или значению-строкой, или ошибкой-числом

ой, как такой код будет прикольно читать и сопровождать тому, кто его не писал :)).

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

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

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

Это зависит от того насколько читающий вкурил патерн монады или (аппликативного) функтора, если вкурил, то скорее поймёт чем нет

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

От memory leaks защищать тебя никто не обещал, это в документации языка прямо прописано: «Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust».

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

Что бы в Rust была хорошая жизнь - часто советуют использовать Neovim. Вот с недавнего обсуждения на реддите, «I use neovim with lazyvim and the rust extra, works like a charm». Пока не пробовал, но очень часто слышу подобные мнения про Neovim, на ютубе на много где, все его советуют. Классические IDE не очень для Rust с его особенностями предназначены, даже к RustRover от JetBrains есть претензии. Neovim это уже стандарт для комфортной разработки на Rust.

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