Hacker News Digest

Хакеры, по сообщению F5, украли исходный код и информацию о ранее неизвестных уязвимостях в BIG-IP. Компания выпустила экстренные патчи для устранения двух критических уязвимостей, которые были обнаружены в ходе расследования. Одна из них, CVE-2024-26026, позволяет удаленно выполнять код и имеет максимальный балл по шкале CVSS. Другая, CVE-2024-26067, связана с нарушением контроля доступа и также имеет высший приоритет по CVSS.

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

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

• F5 заявил, что угроза была «национальным государством», но нет доказательств, что это не просто удобное оправдание для отсутствия надлежащего контроля доступа.
• Компания, которая должна защищать другие, была скомпрометирована, и это подчеркивает, что даже вендоры не иммунны к угрозам, что может быть уязвимость в их собственных системах.
• Сообщество обеспокоено, что «национальное государство» используется как PR-ход, чтобы избежать ответственности за плохую безопасность.
• Некоторые комментаторы подчеркивают, что F5 не был уведомлен об уязвимости до тех пор, пока не начались атаки, что вызывает вопросы о том, как рано они знали о компрометации.
• Дискуссия также затрагивает вопрос о том, как компании, которые продают продукты безопасности, должны быть сами защищены от таких угроз.

Краткий пересказ

30 сентября 2025 года бывший сотрудник Ruby Central Андре Арко сообщил, что у него остался доступ к продакшен-среде RubyGems.org. Почти одновременно блогер Джоэл Дрейпер опубликовал скриншоты, подтверждающие это. Внутреннее расследование показало, что 19 сентября неизвестный злоумышленник сменил пароль root-аккаунта AWS и в течение 11 дней имел возможность администрировать инфраструктуру. В результате Ruby Central отозвала все устаревшие ключи доступа, включила MFA для всех живых аккаунтов и перевела проект на изолированный AWS-аккаунт под единоличным контролем Ruby Central.

• Ruby Central обвиняет бывшего мейнтейнера Andre Arko в том, что он, будучи уволенным, сохранил доступ к корневой учетной записи AWS и изменил пароль, что фактически блокирует организацию от доступа к собственной инфраструктуре.
• Сообщение Ruby Central подчеркивает, что не было никаких доказательств компрометации, но не упоминает о том, что не было никаких доказательств и того, что доступа не было.
• Сообщение Ruby Central не упоминает о том, что они не отозвали доступа к корневой учетной записи, не изменили пароль и не отключили MFA, что, как утверждает Arko, оставляет сервис уязвимым для "незаконного доступа и потенциального утечки данных".
• Arko утверждает, что он не имел доступа к логам доступа, и что Ruby Central не предоставила никаких доказательств того, что кто-то еще имел доступ к этим логам.
• Обсуждение также затрагивает вопрос о том, каким образом Ruby Central может гарантировать, что никакие PII не была скомпрометирована, если они не могут доказать, что никто не имел доступа к логам доступа.

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

Сейчас многие local-приложения полагаются на «безопасность через неясность» — например, доступ к документу Automerge по ID, что рискованно при утечке. Keyhive совмещает самосертификацию, мощь облачных решений и контроль пользователя, позволяя гибко управлять правами (чтение/запись) и отзывать доступ, отслеживая историю изменений даже в офлайн-режиме. Это важно для сценариев вроде планирования событий или юридических документов, где ошибки в доступе критичны.

• Обсуждение статьи о протоколе BeeKEM (децентрализованный аналог TreeKEM из MLS) для использования в распределенном чат-приложении.
• Несколько пользователей отметили необычный и отвлекающий дизайн сайта с публикацией (наклонная карточка, подчеркивания).
• Высказано положительное мнение о работе исследовательской группы Ink and Switch и их альтернативном подходе к разработке ПО.
• Предложено рассмотреть использование CRDT поверх протокола Nostr как уже готового решения с похожими свойствами.
• Запрос к автору предложения разъяснить техническую реализацию использования Nostr для аудитории, не знакомой с этим протоколом.

• Обсуждается концепция "смертельной троицы" в безопасности ИИ: доступ к недоверенным данным, доступ к ценным секретам и возможность связи с внешним миром.
• Предлагаемые меры защиты включают сегментацию доступа (например, подход CaMeL с раздельными доверенной и недоверенной моделями), RBAC и существующие практики безопасности.
• Подчёркивается фундаментальная проблема: LLM не различают инструкции и данные, что аналогично уязвимости in-band signaling и делает полную защиту сложной.
• Отмечается напряжённость между безопасностью и функциональностью: изоляция ограничивает возможности систем, а спрос на мощные AI-агенты велик.
• Проводятся параллели с инженерией и критикуется подход "больше данных решит проблему", вместо которого требуется инженерное мышление и строгий контроль доступа.

• Логотип Multics

• Домой

  • История »
    • Возможности
    • Мифы
    • Project MAC
    • Даты
    • Глоссарий
    • Проект истории
    • Последний сайт
  • Люди »
    • Истории
    • Фотографии
    • Юмор
    • Памятные вещи
  • Библиотека »
    • Статьи и доклады
    • Технические статьи
    • Документы разработки
    • Исходники
    • Симулятор
  • Сайты »
    • Хронология площадок
    • AFDSC (Пентагон, Вашингтон)
    • ASEA (Вестерос, Швеция)
    • Avon (Бристоль, Англия)
    • Bell Canada (2 площадки)
    • CISL (Кембридж, Массачусетс)
    • CNO (Миннеаполис, Миннесота)
    • DND-H (Галифакс, Канада)
    • DOCKMASTER (АНБ, Мэриленд)
    • FORD (Детройт, Мичиган)
    • GM (Детройт, Мичиган)
    • Майнц (Германия)
    • MIT (Кембридж, Массачусетс)
    • NWGS (ВМС США, 4 площадки)
    • OU (Рочестер, Мичиган)
    • PRHA (Сан-Хуан, Пуэрто-Рико)
    • RADC (Рим, Нью-Йорк)
    • RAE (Фарнборо, Англия)
    • STC (Лондон, Англия)
    • System-M (Финикс, Аризона)
    • Systeme X (Лувесьен, Франция)
    • UC/ACTC (Калгари, Канада)
    • USGS (3 площадки)
    • USL (Лафайет, Луизиана)
    • VPI (Блэксберг, Вирджиния)
  • О сайте »
    • Изменения
    • Новости
    • Ссылки
    • Галерея
    • Карта сайта

• Поиск

• Меню: История: Возможности | Мифы | Project MAC | Даты

• Участники обсуждают влияние Multics на современную вычислительную технику: от безопасности и архитектуры до наследия в текущих проектах (например, STOP, происходящий от SCOMP/STOP).
• Делятся воспоминаниями об использовании Multics в британских университетах в 80-х: система считалась быстрой, апгрейды памяти были ощутимыми, доступ через терминалы и JANET, позитивный опыт работы.
• Мнения расходятся: одни критикуют «всеобъемлющесть» дизайна и сложность (в контраст к UNIX), другие подчёркивают сильные стороны Multics — кольца защиты, строгие политики доступа (MAC/ACL), сегментную память и отсутствие переполнений буфера.
• Отмечают ограниченную портируемость Multics к немногим мэйнфреймам, несмотря на теоретическую переносимость.
• Ссылаются на полезные ресурсы: мифы о Multics, оценка безопасности B2, страницы по безопасности данных (AIM/MAC), «Три вопроса» для анализа багов, меморабилии, хронологии и список недавних изменений.
• Обсуждают спад активности оригинальных установок (последние закрытия около 2000 г.), эмулятор DPS8M и печальные новости об уходе участников проекта.
• Несколько комментаторов переосмыслили роль UNIX после знакомства с историей Multics и более ранними идеями (Xerox PARC), видя в Multics самостоятельную и богатую идеями систему, а не только «предтечу UNIX».