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)
Ответ на: комментарий от BruteForce

Почему ты у себя в голове что-то выдумаешь, а потом вешаешь это в качестве ярлыка на оппонента, там более, на казалось бы, приличном техническом форуме? Заходишь в гугл, пишешь: «what IDE is best for Rust», читаешь все обсуждения на профильных ресурсах. Там явно видно, что Neovim преобладает с большим отрывом, и про него самые позитивные отзывы. Открываешь ютуб, вбиваешь тот же запрос. Смотришь видео. Не знаешь английский? Твои проблемы! До свидания!

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

what IDE is best for Rust

Visual Studio Code (VS Code) paired with the rust-analyzer extension

С чем я в принципе согласен. Чуть хуже neovim (зато опенсорс).

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

если бы вы хоть раз вбивали свой же запрос в гугл то вы бы знали что для rust есть только 1 ide - rustrover, остальное - редакторы кода с прикрученным rust-analyzer

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

Грань между редакторами и IDE сильно размыта, особенно для таких языков как rust или golang. Как раньше были мобильники, были смартфоны, были КПК, а теперь разницы нет.

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

Какого выступления? Твоя БЯМ, ответы которой ты выдаёшь за свои, галлюцинирует.

Это цитата отсюда: https://lore.kernel.org/linux-media/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/

Может меня подводит мой английский, но где здесь буквально сказано «не нравится код сгенерированный ИИ - валите из разработки Linux»?

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

А он условно открытый. Лицензию почитай. Кодиум свободен. А у сборки от МС только если сам собирать будешь.

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

То есть ты предлагаешь твоим уверенным заявлениям верить на слово, а отказ в предоставлении пруфа объясняется не твоей уязвлённостью что я от тебя что-то «требую», а тем, что пруфа предоставить ты не можешь?

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

Первой ссылкой по такому запросу выдает юзерзс.растланг, где первый ответ даёт такую ссылку (ы!): https://rust-for-c-programmers.com/ch3/3_4_code_editors_and_ide_support.html

Где неовим на… 6-м месте.

3.4.6 Other Environments

Rust development is also well-supported in many other editors and IDEs:

    Neovim/Vim: Highly configurable terminal editors with excellent Rust support through plugins (rust-analyzer via LSP clients like nvim-lspconfig or coc.nvim).
BruteForce ★★★★★
()
Ответ на: комментарий от yatazet

У IDE традиционно 2 вещи хороши перед редакторами: дебаггер и GUI формошлёпство. Остальное скорее вредит или ситуативно (системы сборки там, всё равно ручкми на cmake или встроенную в ЯП систему переписывать приходится в реальных проектах). Дебаггеры стали бессмысленными после появления конкуренции между LLDB и GDB. А формошлёпства на расте нет. Тот же CodeLLDB не сильно уступает отладчику в RustRover.

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

Я из мира языков со сборщиком мусора.

Да, для меня и для всех нас, Rust - это просто подарок и нечто великолепное.

Э-эээээээээ…

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

Если у вас так хорошо с этим пониманием, то почему 90% патчей для всего, что написано на C/C++ - это исправление ошибок памяти?

Во-первых, почему у тебя в логике дыры? Хорошо с пониманием у хороших программистов, у плохих - плохо. Баги (и с памятью, и не с памятью) создают в основном вторые. Вторых очень много, да. Но это никаким боком не недостаток Си, даже скорее наоборот: видишь проект где постоянно исправляют баги с памятью - сразу знаешь что его пишут идиоты и лучше найти ему альтернативу где такого не происходит. Но это работает только с Си-подобными языками. Когда видишь проект на расте, допустим, и его пишут идиоты, то багов с памятью они не сделают - а значит теперь их (идиотов) сложнее заблаговременно распознать. То есть раст помогает идиотам маскировать свой идиотизм, а Си помогает быстрее их выявлять.

А ещё почему ты ложную информацию пытаешься вбросить? Никаких «90%» там нет.

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

Чел, для всех, кто плотно освоил ИИ и Rust, прогеры ковыряющиеся с сигфолтами на C/C++ выглядят как бедолаги. Примерно, как люди отказывающиеся переходить с ассемблера на си, в своё время. Мы вышли на новый уровень абстракции без потерь в производительности и вариативности. Глобальная индустрия с каждым днём всё плотнее и плотнее переходит на эти рельсы. Тут либо ты прыгаешь на поезд - либо остаёшься в прошлом.

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

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

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

Это ты нашел соответствие со словом «валите», что с остальными?

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

Можно. Хорошо, что ты придумал как (пусть и только для популярных открытых реп), ничего не сделал ИРЛ и с невероятной точностью предсказал результаты своего упражнения!

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

Ты опять пытаешься подменять тезисы? Не юли.

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

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

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

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

1) Ошибки возникают даже у создателей компиляторов и ядра Linux. Человеческий мозг не предназначен для отслеживания десятков тысяч пересекающихся времён жизней объектов. ИИ здесь - лишь костыль, который находит очевидное, но не более того.

2) В Rust нельзя «писать без понимания». Компилятор Rust заставляет программиста понять как устроена память жестче чем Си. В Си вы можете написать

return &local;
, и это скомпилируется (с предупреждением), но упадет в рантайме. В Rust это не скомпилируется вообще. Чтобы это починить, вам придется изучить основы. Rust - это учебник по управлению памятью, встроенный в компилятор.

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

20 часов свободного времени

+

не 20 часов осваивать, его пару дней настраивать и к нему недели две привыкать

20 часов не вкуривание IDE?
спасибо, что предупредили, а то я подумывал глянуть эту «типа, чудо» IDE (не-не, я так не умею курить...) :о)

neovim/slackbuild
зависимости (как-то многовато)

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

По сылке 404, но я верю.

20 часов не вкуривание IDE?

Да, на минимально освоение вим-хоткеев (в моём случае усложнилось тем, что у меня КолемакДХ, частично пришлось изобретать свои), на вкуривание как ставить-настраивать дополнения, какие они вообзе есть и какие из популярных нужны. Я мигрировал с вскода в три шага: 0. Неовим в вскоде, 1. це/цепепе в неовиме, остальное в неовиме в вскоде, 2. Всё в неовиме.

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

8.5 лет назад я на 7 лет выпал из мира клавиатур, а до того работал в вскод, иногда кьюткреатор для некотрого цепепе, а до того был емаксером. Не уверен до конца, стоит ли переход с емакс на неовим свеч, но в целом я доволен.

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

А что, люди, пишущие на c++, прямо вот постоянно ковыряются с сегфолтами?

Если честно, мой опыт говорит, что сегфолты - это исчезающе малый процент проблем. Сложная, плохо продуманная и плохо реализованная логика, локи (дэд-, но чаще и хуже - лайв-). Да хоть затрешенная память от того, что постоянно выделяется-уничтожается миллион разнообразных объектов… Вот это, да, насущные проблемы для живого проекта. А вот так, чтобы он по сегфолту сваливался постоянно…

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

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

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

А что, люди, пишущие на c++, прямо вот постоянно ковыряются с сегфолтами?

Не постоянно, но зато иногда долго и красиво.

С горящими глазами помню сделал priority queue из лямбд. Лямбда получала изменяемый контекст, в котором также был этот queue.

auto event = ctx.queue.front(); event.process(ctx); ctx.queue.pop_front().

Из-за того, что во время process в очередь добавлялись новые ивенты — на вершину в частности — активный и удаляемый объекты на трехсотой итерации отличались, а лямбда после первого прохождения была freed. И где-то чуть дальше в будущем я получал use-after-free.

Ну и соответственно о необходимости auto & event = ctx.queue.pop_front(); акадЭмики догадались лишь два стандарта спустя.

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

Недоумеваю от таких заявлений про сложность разработки на расте. Что в нем сложного? Для проф разработчика там все очевидно, концепции понятные, синтаксис неплох. Ты точно программист?

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

Откуда ты знаешь какое исключение выбросит? Особенно когда юзаешь чужую либу. Что если перехватишь одно, а стрельнет другое? В расте глянул на сигнатуру и понятно что вернется, проматчил и живешь спокойно.

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

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

Другое дело, что без ИИ я вообще бы к фронту не подошёл.

Но, что удивительно, на креативные мысли подталкивает.

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

Можешь добавить немного конкретики? В чем сложность раста, что тебе в нем непонятно? Каких возможностей С++ тебе в нем не хватает?

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

Судя по обилию CVE в сишном мире, хороших программистов среди вас, сишников, исчезающе мало. Или ты такой уникальный, непризнанный гений?

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

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

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

сразу писать код работающий на скорости C/C++, при этом без ошибок выделения памяти. При этом тебе не нужно этим голову забивать, достаточно выучить borrow checker

Так если я правильно понял, в том чтобы правильно обращаться с borrow checker и при этом добиться того что тебе нужно и есть главная трудность. То есть на наскоку за пару дней раст не выучишь, даже имея бэкграунд с/с++.

В то же время в с++ можно этим голову себе не забивать и пользоваться умными указателями, которые покрывают 99% случаев.

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

нет, это не большинство

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

Если у вас так хорошо с этим пониманием, то почему 90% патчей для всего, что написано на C/C++ - это исправление ошибок памяти?

неправда это.

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

А что на это говорят люди, которые считают что раст ничего не усложняет?

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

Когда начнёшь серьёзный код писать окажется что раст гораздо легче, чем си и плюсы

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

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

проблемы с памятью составляют лишь небольшую часть возможных проблем с безопасностью.

Угу. Эта небольшая часть примерно равна 70%

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

А что такое по-твоему «серьёзный код»?

А это когда каждый простой на час в твоём софте начинается от миллиона долларов убытков (если это сервер, то сервера, а если десктоп, то когда через суд засудить могут, ну или когда самолёт упадёт/АЭС бахнет/на заводе дорогущий станок сломается/работа сорвётся). Я понимаю, что большинство тут либо вообще не из IT, либо имеют сайт своей чебуречной, где всех убытков 2000 рублей в месяц, если он целый месяц будет недоступен (и да, такое можно заменить на группу в вк).

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.