Архив метки: Linux

Августовский Linux Patch Wednesday

Добавить комментарий

Августовский Linux Patch Wednesday

Августовский Linux Patch Wednesday. Я припозднился с этим LPW, т.к. улучшал генерацию списков LPW-бюллетеней и работу Vulristics. 🙂 В августе Linux вендоры начали устранять 867 уязвимостей, почти в 2 раза больше, чем в июле. Из них 455 в Linux Kernel. Для одной уязвимости есть признаки эксплуатации вживую (CISA KEV):

🔻 SFB - Chromium (CVE-2025-6558) - эксплуатируемая SFB в Chromium уже четвёртый месяц подряд. 🙄

Для 72 (❗️) уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Можно выделить:

🔸 RCE - WordPress (CVE-2024-31211) - прошлогодняя, но в Debian пофиксили недавно; Kubernetes (CVE-2025-53547), NVIDIA Container Toolkit (CVE-2025-23266), Kafka (CVE-2025-27819)
🔸 Command Injection - Kubernetes (CVE-2024-7646)
🔸 Code Injection - PostgreSQL (CVE-2025-8714/8715), Kafka (CVE-2025-27817)
🔸 Arbitrary File Writing - 7-Zip (CVE-2025-55188)

🗒 Полный отчёт Vulristics

Для MAX вышел официальный клиент под Linux

Добавить комментарий

Для MAX вышел официальный клиент под Linux

Для MAX вышел официальный клиент под Linux. 👍 Доступен в виде deb пакета и AppImage.

Как и предполагалось, пока это не нативное Linux-приложение, а PWA-шка. 😔🙄🙂 Поэтому выглядит ровно как веб-версия, но в отдельном окошке. В списке сессий отображается как "Max WEB". Работает шустро. Но функционально этот Linux/Web-клиент несколько ограничен: например, некоторые старые сообщения я смог удалить только в Android-приложении. 🤷‍♂️

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

"Мессенджер запрашивает не больше, чем любые другие. Цифры показывают наглядно: WhatsApp просит 85 разрешений, Telegram — 71, а MAX — 63".

А то, что код обфусцирован, так никто облегчать жизнь ресёрчерам не обещал. Особенно тем, у кого умыслы злые. 😈 Eсли есть чего, несите на Bug Bounty. 😉

Июльский Linux Patch Wednesday

Добавить комментарий

Июльский Linux Patch Wednesday

Июльский Linux Patch Wednesday. В этот раз 470 уязвимостей, чуть меньше, чем в июне. Из них 291 в Linux Kernel. Для одной уязвимости есть признаки эксплуатации вживую (CISA KEV):

🔻 SFB - Chromium (CVE-2025-6554)

Ещё для 36 (❗️) уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Из них можно выделить:

🔸 RCE - Redis (CVE-2025-32023), pgAdmin (CVE-2024-3116), Git (CVE-2025-48384)
🔸 EoP - Sudo (CVE-2025-32462, CVE-2025-32463)
🔸 PathTrav - Tar (CVE-2025-45582)
🔸 XSS - jQuery (CVE-2012-6708)
🔸 SFB - PHP (CVE-2025-1220)
🔸 DoS - LuaJIT (CVE-2024-25177), Linux Kernel (CVE-2025-38089)
🔸 MemCor - DjVuLibre (CVE-2025-53367)

🗒 Полный отчёт Vulristics

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

Добавить комментарий

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

Основная проблема существующих отечественных ОС в том, что в абсолютном большинстве это всего лишь перелицованные зрелые западные Linux-дистрибутивы. 🤷‍♂️ Ведь задача, которая ставится перед их разработчиками - получить за минимальное время и с минимальными затратами решение с максимальной функциональностью. И заработать на этом. 👛

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

Тогда постепенно можно будет избавляться от наиболее сомнительных зависимостей, переходить на отечественные аналоги и форки. Тем самым формируя по-настоящему отечественные операционные системы. Которых (сюрприз-сюрприз!) сейчас нет. 🌝

Июньский Linux Patch Wednesday

Добавить комментарий

Июньский Linux Patch Wednesday

Июньский Linux Patch Wednesday. В этот раз 598 уязвимостей, почти в 2 раза меньше, чем в мае. Из них 355 в Linux Kernel. Для 3 уязвимостей есть признаки эксплуатации вживую (CISA KEV):

🔻 SFB - Chromium (CVE-2025-2783)
🔻 MemCor - Chromium (CVE-2025-5419)
🔻 CodeInj - Hibernate Validator (CVE-2025-35036). Уязвимость эксплуатируется в атаках на Ivanti Endpoint Manager Mobile (EPMM), отслеживается по CVE-2025-4428.

Ещё для 40 (❗️) уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Из них можно выделить:

🔸 RCE - Roundcube (CVE-2025-49113)
🔸 EoP - libblockdev (CVE-2025-6019)
🔸 DoS - Apache Tomcat (CVE-2025-48988), Apache Commons FileUpload (CVE-2025-48976)
🔸 InfDisc - HotelDruid (CVE-2025-44203)
🔸 DoS - ModSecurity (CVE-2025-47947)

🗒 Полный отчёт Vulristics

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать

Добавить комментарий

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать. Моё мнение относительно правильного детектирования уязвимостей в Linux-дистрибах. 🙂

🔹 В идеале бюллетени безопасности (или публичный трекер) Linux-вендора должны содержать информацию обо всех известных уязвимостях во всех пакетах, доступных в репозитории Linux-вендора. И VM-вендор должен детектировать уязвимости в пакетах ОС исключительно на основе этой информации.

🔹 Если VM-вендор в ходе проверок обнаруживает, что в бюллетенях Linux-вендора описаны не все уязвимости, он должен ему об этом сообщить. ✉️ Если реакции нет, VM-вендор должен реализовать правила детектирования по своей логике. В том числе, "опускаясь до базового дистриба".

🔹 При отсутствии реакции VM-вендор должен сообщить регуляторам (ФСТЭК и Минцифры?) о том, что Linux-вендор пренебрегает своими обязанностями по описанию и устранению уязвимостей. Желательно, чтобы это влияло на присутствие ОС в реестре и наличие у неё сертификата. 😉

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

Добавить комментарий

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

Стоит ли опускаться до базового дистрибутива при детектировании уязвимостей Linux? Возьмём деривативный Linux-дистрибутив. Например, Astra Linux CE, использующий помимо собственных также пакеты Ubuntu и Debian.

Есть 2 подхода к детектированию уязвимостей:

🔹 Используем только информацию об уязвимостях от вендора. Берём бюллетени безопасности вендора, генерим на основе них правила детектирования ("версия пакета X -> уязвимость"). И детектируем, и устраняем уязвимости по рекомендациям вендора.

🔹 Используем информацию об уязвимостях от вендора, но и опускаемся до базового дистрибутива. Т.е. предыдущий вариант плюс смотрим на пакеты, которые похоже были взяты из базового дистриба (Ubuntu, Debian) и используем для их проверки правила детектирования для этого базового дистриба (OVAL-контент Ubuntu, Debian). Продетектируется больше уязвимостей, но вендор, скорее всего, посчитает их фолсами и обновлений не выпустит. 🤷‍♂️

Как считаете, какой подход более правильный? 🤔