Уязвимости в Linux и FreeBSD, позволяющие получить root-доступ в системе

Ad hominem? Слив засчитан.

Сам-то много кода на сях написал, чтобы мнение иметь, теоритик диванный? Где твой вклад можно посмотреть? Давай сюда ссылку на свой гитхаб.

Вот тут можешь про его код почитать, выше и ниже по ветке с этим комментарием: Mergiraf -- новый движок разрешения конфликтов в коде (комментарий)

А, так это очередной великий лоровский сишник (тм). Спасибо, поржал %)

Слив засчитан.

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

И самый печальный вариант, если у тебя законченное высшее есть, тогда у меня возникает дилемма:

если ты вдруг считаешься в обществе дееспособным интеллектом, то надо признать интеллектом и текущий ИИ (ввиду того, что вы не отличимы по глубине мышления), чего я не могу сделать… Соответственно, в этом случае я надеюсь, что ты просто недееспособен, или придется все-таки признать, что интеллект - не обязательный атрибут для человека, и его может просто не быть…

ЗЫ В принципе, я знаю, что ты все написанное мной воспримешь как попытку оскорбления, но я даже не пытался оскорбить, просто даю адекватную обратную связь, чтоб не способствовать той беде, что заправляет у тебя в сознании…

https://www.opennet.ru/opennews/art.shtml?num=61819

...

Кроме того, можно отметить уход Уэдсона Алмейда Фильо (Wedson Almeida Filho) с поста сопровождающего проект Rust for Linux, занимающийся внедрением в ядро Linux средств для разработки на языке Rust.

...

В ответ на намерение Алмейда создать обвязку над написанными на языке Си интерфейсами файловых систем для их использования в коде на языке Rust, Тед Цо указал на то, что подобная обвязка неминуемо приведёт к проблемам, так как любое изменение Си-интерфейсов и проведение рефакторинга потребует изменения обвязки для Rust и он не хочет брать на себя лишней ответственности за исправление возникающих проблем в коде на Rust и отслеживании состояния Rust-обвязки. Код на Си постоянно развивается и если его изменение нарушит работу обвязки для Rust, это приведёт к нарушению работы и всех завязанных на эту обвязку файловых систем.

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

...

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

NB: Я почему-то был уверен, что эта новость была тут на ЛОР, но не нашёл.

поэтому я и спросил про образование

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

Типичное лоровское нечто. В игнор.

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

Выше нет моего кода, я ж сказал, что оскорбишься…

ЗЫ увидел, это тебе ябида набрехала (оно в игноре 300 лет уже у меня), мы там спорили о скорости выполнения кода (и да там был касяк, и я честно покаялся, т.к. просто на автомате накидал хоть что-то, чтоб проверить скорость работы, ибо эти фокусники начали хвастаться скоростью раста и обкакались), прочитай там все, чтобы знать на чье мнение полагаешься, обращай внимание на ники, т.к. некоторых на лоре больше нет…

ЗЫЗЫ в свое оправдание скажу, что они на меня толпой насели, я был в аффекте))))

Я, правда, до сих пор не могу понять, как новость про ядра ОС, написанных на сях скатилась в холивар о rust, на котором ещё ни одного работающего ядра нет и пока что не предвидится.

Мне вот всё-равно, что за язык там используется, код на этих языках только на уровне читателя понимаю и правки могу только косметические вносить. Ну и в случае с C спец-утилитами пользоваться для анализа. Мне важно, чтобы ОС работала. Понятное дело, что такие вещи, как ядро за пару лет не пишутся. Но и понятно, что когда проект вырастает до таких размеров, в нём неизбежно будут ошибки. Тут выше был уже один комментатор, который говорил что rust безопасен, потому что там нет CVS(что ложь, они есть). И ему резонно ответили, что когда на rust будут такие же проекты с таким же объёмом кода, тогда и можно будет говорить. Я вот смотрел код RustDesk(самый большой проект на rust, с которым мне приходилось сталкиваться), так там в исходниках 243 rs-файла и в 82 упоминается ' unsafe ' и не по одному разу. И упоминается как раз именно в работе с сетью в том числе, например. А меня именно это больше всего интересовало в коде данного проекта.

И, кстати, он и там поддакивал одному «ценителю стандартов», который сам же сел в лужу на volatile из стандарта и подпевал с собой потянул, а потом и на скорости раста тоже они в лужу сели… Вот он и запомнил срам свой))))) Толпой в лужу, ахаххх))))

Такие себе у тебя советчики, ахах)))))

ЗЫ они С-шний код в g++ компилируют, если что, со словами «а какая разница», ахахахаха)))

ЗЫЗЫЗЫ Этот твой дружаня вместе с товарищами, кстати, тоже пропустили эту ошибку, они ее софтом нашли, а ткнуть в строку не могли, говорили «где-то»))))))

Ахахахах)))))))))

Так что можешь смело игнорить, я теперь знаю, что вас тут трое таких осталось)))))

Тут выше был уже один комментатор, который говорил что rust безопасен, потому что там нет CVS(что ложь, они есть).

Враньё. Прежде чем выдавать свои выдумки за мои слова, внимательно прочитай, что я в действительности написал. Я не говорил, что на расте нет CVE (да, именно так, а не CVS). Я сказал, что CVE, которые здесь (и в массе) обнаруживаются в сишном коде, в основном вызваны ошибками памяти. Раст защищает от ошибок памяти, и только от них. От ошибок в логике не защищает ничего, кроме языков с математической верификацией.

там в исходниках 243 rs-файла и в 82 упоминается ’ unsafe ’ и не по одному разу.

Что это за метрика, в которой сравнивается количество файлов с количеством блоков? Это что-то сродни теплого с мягким? Посчитай, сколько строк значащего кода находится внутри unsafe, и снаружи них, и посчитай соотношение.

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

Кто-нибудь, заставьте их написать 1668 эксплоита, и чтоб они работали не в границах «коня в вакууме»…

И чтобы на ведроиде тоже работало и давало рут с неограниченным доступом.

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

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

Посчитай, сколько строк значащего кода находится внутри unsafe, и снаружи них, и посчитай соотношение.

Это сложно посчитать, потому что внутри unsafe вызываются функции, объявленные в других местах. Это нужно полноценный статический анализатор писать. И я даже не знаю, как.

Т.е. есть две строки внутри unsafe

    unsafe {
        let _lock = VIRTUAL_INPUT_MTX.lock();
        VIRTUAL_INPUT_STATE = VirtualInputState::new();
    }  

Это я сейчас первый попавшийся пример нашёл. Там такого много.

И ладно бы там вызывался код только из этого же проекта. А ведь внутри unsafe часто вызывается код из сторонних библиотек. Как их анализировать? Тут уже количество строк растёт как снежный ком.

Причём для некоторых сторонних библиотек прямо в документации написано, что надо вызывать в unsafe. Например, CloseHandle.

                unsafe {
                    hbb_common::allow_err!(CloseHandle(HANDLE(token as _)));
                };

Я не говорил, что на расте нет CVE (да, именно так, а не CVS)

Извиняюсь, опечатался.

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

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

Т.е. есть две строки внутри unsafe

Это не так работает.

Unsafe ограничен блоком, и позвляет тебе выполнять небезопасные операции и/или вызывать unsafe-функции, которые явно объявлены таким образом. В остальных случаях контекст unsafe-блока не распространяется на реализацию вызываемых функций.

И это не зависит от языка.

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

Раст делает чуть больше: он проверяет корректность обращения с памятью, и некорректный код просто не скомпилируется. Я не понимаю, почему система типов воспринимается как что-то нормальное, а управление памятью - уже нет. Причем, никакой магии в расте нет - просто набор правил и детерминистические алгоритмы анализа.

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

Если в ядре не будет ошибок - то как тогда предполагается возвращать себе полный контроль над своим собственным девайсом?

Если в ядре не будет ошибок - то как тогда предполагается возвращать себе полный контроль над своим собственным девайсом?

Неправильно ты, Дядя Фёдор, с системой борешься. Ты ее обмануть пытаешься, а надо просто голосовать рублем и перестать покупать залоченные говнодевайсы.

А потом ещё код внутри unsafe вызывает сишный код из системы, который выполняется на ансейф хардвари, тотальный зашквар уже, выбрасываем раст за ненужностью.

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

«Управление памятью» это слишком общие слова. Конкретика такая: двусвязный список на ассемблере занимает несколько строк, на Си - несколько строк (даже меньше чем первое), на расте - огромную простыню. «Система типов» на Си нигде не приводит к увеличению количества кода в 10 раз, с пропорциональным снижением его читабельности, она наоборот помогает писать короче и понятнее. С растовской же «системой памяти» всё ровно наоборот.

Неправильно ты, Дядя Фёдор, с системой борешься. Ты ее обмануть пытаешься, а надо просто голосовать рублем и перестать покупать залоченные говнодевайсы.

А я их и не покупаю. Пользуюсь Nokia N9. Жду вот хотя бы один реально работающий локальный эксплойт для линуксового ядра который позволит мне спокойно купить произвольный ведроидный телефон и без всяких там разлочек и прочего дебильного говна вернуть себе полный контроль над ним.

И что-то ни одного такого эксплойта пока я ни разу не видел.

Так что все эти CVE можно засунуть их обнаружителям туда, где им самое место.

struct VirtualInputState {
    virtual_input: VirtualInput,
    capslock_down: bool,
}

#[cfg(target_os = "macos")]
impl VirtualInputState {
    fn new() -> Option<Self> {
        VirtualInput::new(
            CGEventSourceStateID::CombinedSessionState,
            CGEventTapLocation::Session,
        )
        .map(|virtual_input| Self {
            virtual_input,
            capslock_down: false,
        })  
        .ok()
    }

    #    fn simulate(&self, event_type: &EventType) -> ResultType<()> {
        Ok(self.virtual_input.simulate(&event_type)?)
    }
}
#[cfg(target_os = "macos")]
static mut VIRTUAL_INPUT_MTX: Mutex<()> = Mutex::new(());
#[cfg(target_os = "macos")]
static mut VIRTUAL_INPUT_STATE: Option<VirtualInputState> = None;

Я не вижу здесь, чтобы VirtualInputState был как-то по особенно объявлен. Но при этом он вызывается внутри unsafe.

на расте - огромную простыню

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

она наоборот помогает писать короче и понятнее

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

вернуть себе полный контроль над ним

Не выйдет, там в железе ещё всякая гадость скорее всего до которой из софта не дотянуться.

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

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

А открой почти любой кусок ядра - и там черт голову сломит.

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

Ты меня не понял. Когда код вызывается в unsafe, этот unsafe действует только на то, что ты видишь перед собой. Внутри VirtualInputState контекст unsafe не действует, он влияет только на сам вызов - т.е. на то, что передалось функциям, а не на сами функции.

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

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

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

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

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

И да. Иногда и строгая типизация не нужна, достаточно неявного приведения типов. Разумеется, тут тоже надо подходить с умом. Но для многих утилит это приемлемо.

что не работает или работает плохо

Что конкретно не работает или работает плохо? Ты привел пример с unsafe, и я объяснил, что ты неправильно понимал, как он работает. Вроде, одним мифом должно быть меньше. Что еще не так?

под громкими лозунгами «Вот сейчас заживём»

Эти лозунги придумывают не те, кто делает раст, а те, кто зачем-то топит против него. Вон, ты сверху наврал, будто я говорил, что на расте нет CVE. Но ведь я не говорил. А лозунг был: сконструированный тобой же, и тобой же опровергнутый. Очень удобно. У растовиков цель одна: исправить ошибки памяти, из которых состоят уязвимости процентов эдак на 70. Это убирание огромного вороха проблем, и оно действительно работает.

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

И снова: что конкретно работает хуже?

Иногда и строгая типизация не нужна, достаточно неявного приведения типов

Бред. За последние 20 лет уже выяснилось, что нестрогая и/или слабая типизация приводит к огромному количеству проблем. Поэтому типизация в новых языках (не только в расте) сильная и явная. Просто потому что хитрые касты нужны в исключительных случаях, а в основной массе проверками должен заниматься компилятор. Это позволяет разгрузить мозги программиста, чтобы он продумывал логику, а не жонглировал с указателями.

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

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

Но речь вообще не об этом.

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

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

И ни один не работает на ведроиде.

Такого просто не может быть. Уже 100500 эксплойтов якобы работающих на линуксовом ядре с помощью т.н. «ИИ» «нашли», и ни одного, который работал бы на ведроиде.

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

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

Если CVE локального повышения привилегий для линуксового ядра не позволяет получить рута на ведроиде при прочих равных - то это однозначно фейковый CVE.

Меня не волнует чей-то сервер

«После нас - хоть потоп».

Если эксплойт работает на линуксовоч ядре, значит он обязан работать и на ведроиде.

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

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

Зачем же и кому тогда нужна вся эта шумная PR-кампания?

ЗЫ: И ведь что опять интересно - все эти очень особые версии ядра или очень специфические модули почему-то всегда отсутствуют на ведроиде. Как так? Это что, специально кто-то отбирает именно такие ядра и модули?

двусвязный список на ассемблере занимает несколько строк

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

на Си - несколько строк (даже меньше чем первое)

И сотни ватт-часов.

расте - огромную простыню

С которой у тебя никогда не останется висящий указатель, заботу об этом на себя берёт компилятор и рантайм.

«Система типов» на Си нигде не приводит к увеличению количества кода в 10 раз

Вон тут новость на главной про LLVM 23: добавлены функции stdc_leading_zeros_{uc,us,ui,ul,ull}. Сиди и сам матчи тип функции с типом аргумента, который хочешь передать. Система, понимаешь, типов, идрить её налево!

У тебя только два варианта эксплоитов? «Подходит для рутования говнофона» и «не существенно»?

Обращение к static mut требует unsafe, т.к. у компилятора нет информации, есть ли доступ к статику из разных точек исполнения или потоков.

Ну, не то, чтобы не понял. Просто я подумал, что ты говоришь про случай unsafe fn VirtualInputState(...) { ... }. Ну ок.

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

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

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

ЗЫ: БиЗАПасНАсть меня не интересует вообще.

А адрес этой функции передаётся аргументом. И является некорректным. Компилятор такое пропустит

– Ага! - сказали мужики и отправились валить лес двуручными пилами.

Вон, ты сверху наврал, будто я говорил, что на расте нет CVE. Но ведь я не говорил.

Не наврал, так показалось из контекста. Ещё раз извини, ошибся.

что конкретно работает хуже?

Библиотека bcrypt в питоне после переписывания на rust и принудительного удаления сишной реализации первое время падала при большом количестве параллельно вызванных методов дешифровки или выдавал неверный результат. И вроде бы как проблема была как раз в неправильной работе с памятью. Не знаю, кто был виноват, rust или python, но сишная реализия продолжала работать. Поэтому мне пришлось замаскировать обновления библиотеки и её зависимостей(а их дофига) и постоянно чекать, починили или нет. Сейчас попытался найти багрепорт, связанный с этим, но что-то не получилось. Но это то, с что мне серьёзно мешало в работе. Ну и я тут уже упоминал про потенциальные проблемы в ядре, о которых писал Теодор Тсо. Это просто первое, что мне приходит на память.

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

Я пишу по большей части на интерпретируемых языках(perl, python) и там нет необходимости жонглировать с указателями. Там можно работать с динамической типизацией, не объявляя явно тип в коде, он будет определяться на этапе выполнения автоматически. Очень часто это удобно. Хотя я прекрасно понимаю потенциальные риски и удобство явного объявления в коде. К чему меня приучил golang.

Ты сравни объем кода, который нужно проверять на ошибки памяти мозгами: две строки или тридцать? Код внутри VirtualInputState проверяется компилятором, код внутри unsafe - человеком. Это отличается от сишки, где весь код проверяется человеком.

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

Библиотека bcrypt в питоне после переписывания на rust

Это хороший пример, потому что я тоже столкнулся с проблемами с питоновым bcrypt. Правда, в моем случае это был сломанный API до несовместимости с эталонной реализацией, потому что мейнтейнер посчитал, что надо кидать исключение при обрезании строки, и сломал этим херову гору кода. О том, что надо заранее объявлять ломающие изменения, мейнейнер не слышал, и на мой вопрос о том, почему он не сделал, DeprecationWarning, тоже не ответил.

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

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

И да, ставллю я его из бинаря на Gentoo, так как собирать llvm, clang и потом rust ради одной библиотеки мне лень. Но это уже гентупроблемы. Хорошо, хоть мантейнеры это понимают и поставляют rust-bin в репах.

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

А я сразу написал, что все вопросы почти всегда к программистам вне зависимости от языка. ;)

Про проверки памяти можешь не повторять, я тебя понял.

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

Они уж есть. Из того, чем я постоянно пользуюсь - RustDesk и Zed. Причем второй - совершенно великолепный редактор, гораздо лучше убогого поделия на электроне под названием VS Code.

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