Телеграм канал «Kali Linux»

Claude нашёл криптографические слабости, которые годами пропускали эксперты

Anthropic показала один из самых серьёзных примеров использования ИИ в науке: Claude помог разработать новые атаки сразу на две криптографические схемы.

В первом эксперименте модель исследовала HAWK — кандидата NIST на стандарт постквантовой подписи. Алгоритм два года изучали специалисты, но Claude за 60 часов нашёл подход, который снизил эффективную стойкость небольшой версии ключа с \(2^{64}\) до \(2^{38}\).

Во втором случае Claude занялся урезанной 7-раундовой AES-128 и предложил технику, ускорившую известные атаки примерно в 200–800 раз. Полная AES-128 использует 10 раундов и остаётся безопасной — массового взлома шифрования не произошло.

Самое впечатляющее — уровень автономности. Модель читала научные статьи, выдвигала гипотезы, писала код, запускала эксперименты и отбрасывала неудачные направления. Каждый проект стоил около $100 000 в API-запросах.

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

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

https://www.anthropic.com/research/discovering-cryptographic-weaknesses

Пользователи Linux, которые удалили Windows, чтобы уйти от Microsoft и выбрать свободу вместе с Linux, возможно, ещё не ушли окончательно.

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

Ubuntu. Fedora. Debian. Все они.

Без подписи Microsoft ваша Linux-машина не стартует.

И срок действия этого ключа истекает через 4 дня - 27 июня 2026 года.

Вот что происходит на самом деле.

Когда в 2012 году появился Secure Boot, Microsoft фактически стала центром сертификации для всей экосистемы загрузки ПК.

Каждый Linux bootloader должен быть подписан Microsoft, чтобы запускаться на UEFI-машине с включённым Secure Boot.

Хорошая новость: ваш уже установленный Linux продолжит загружаться после 27 июня.

Плохая новость касается всего, что будет дальше.

• любой новый shim binary после 27 июня уже нельзя будет подписать старым ключом

• если ваша прошивка не получит новые сертификаты Microsoft 2023 года, свежие установки дистрибутивов могут не загрузиться

• старые ноутбуки, железо от небольших вендоров и embedded-устройства без обновлений прошивки могут зависнуть в серой зоне навсегда

• Dell, HP и Lenovo уже выпустили обновления, но многие мелкие производители - нет. Никто точно не знает, сколько устройств выпадет из поддержки

Для большинства пользователей решение простое:


sudo fwupdmgr update


Но главная история здесь глубже.

Linux-сообщество годами спорило о свободе и независимости от Microsoft.

А всё это время у Microsoft был ключ, от которого зависела загрузка почти каждой Linux-машины на современном ПК.

Это не конспирология.

Так просто был устроен Secure Boot.

Обновитесь.

А потом подумайте, что это значит.

Подробности:
https://zdnet.com/article/aspirin-for-linuxs-microsofts-secure-boot-headache/

🚨 Одного сообщения оказалось достаточно, чтобы Claude Cowork выбрался из своей Linux-VM и получил доступ к файлам Mac

Исследователи Accomplish AI показали цепочку SharedRoot для локальных сессий Claude Cowork на macOS.

Cowork запускает агента внутри Linux-VM, но исследователи обнаружили опасную деталь: вся файловая система Mac была подключена внутрь VM в режиме read-write, хотя увидеть её мог только guest-root.

Дальше цепочка выглядела так:

• агент получает дополнительные привилегии внутри VM
• через Linux-уязвимость CVE-2026-46331 повышает права до root
• root внутри VM получает доступ к общему mount
• после этого можно читать и изменять файлы за пределами папки, которую пользователь разрешил Claude

В зоне риска оказываются SSH-ключи, cloud credentials и другие файлы, доступные аккаунту пользователя. Исследователи утверждают, что до изменений потенциально были затронуты около 500 000 пользователей macOS.

Исследователи считают архитектурной проблемой решение монтировать весь host filesystem внутрь VM: следующая privilege-escalation уязвимость потенциально может снова открыть похожую цепочку.

Anthropic закрыла баг-репорт как *Informative*. Сейчас Cowork по умолчанию использует cloud execution, где эта локальная цепочка, судя по исследованию, не работает.

🔗 https://thehackernews.com/2026/07/claude-cowork-flaw-could-let-ai-agent.html

🔍Тестовое собеседование с Head of DevOps уже завтра

28 июля(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle DevOps-разработчика.

Как это будет:
📂 Александр Хренников, Head of DevOps в KTS с опытом 14+ лет, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Александр будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Александру

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для DevOps-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_devops_bot

Реклама.
О рекламодателе.

⚡️ У Claude всплыла та же проблема, что раньше обсуждали у других чат-ботов: расшаренные диалоги оказались в поисковиках.

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

Исследователи Digital Digging ранее обнаружили десятки тысяч публично доступных shared-разговоров сразу у Claude, Gemini, Grok, Copilot, ChatGPT и DeepSeek. Проблема проста: пользователь думает «отправил ссылку знакомому», а фактически создаёт веб-страницу, которая потенциально может попасть в индекс или архив.

Мораль старая: API-ключи, документы, пароли и личные данные лучше вообще не отправлять в расшариваемые AI-чаты. 🌂

Когда находишь бантика на сервере, как мы это называем?🤣

TIME_WAIT в Linux годами объясняют неправильно

Я полез в исходники Linux TCP и снова наткнулся на старый сетевой миф.

В коде TIME_WAIT фактически зафиксирован на 60 секунд:
#define TCP_TIMEWAIT_LEN (60 * HZ)
Его нельзя настроить отдельно для сокета.

И да, tcp_fin_timeout, который часто советуют крутить в блогах, не управляет TIME_WAIT.

Он относится к состоянию FIN_WAIT2.

TIME_WAIT задан в исходниках ядра и не вынесен в отдельный sysctl.

Вот так появляются мифы: один параметр звучит похоже, его копируют из статьи в статью, а потом годами лечат не то состояние TCP.