OpenNET

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

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

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

Основные рекомендации:

• Запрет учётных записей пользователей с пустыми паролями.

• Отключение входа суперпользователя по SSH (PermitRootLogin=no в /etc/ssh/sshd_config).

• Ограничение доступа к команде su пользователями из группы wheel ("auth required pam_wheel.so use_uid" в /etc/pam.d/su)

• Ограничение списка пользователей, которым разрешено использовать команду sudo.

• Установка корректных прав доступа к файлам с параметрами пользователей (chmod 644 /etc/passwd /etc/group) и хешами паролей (chmod go-rwx /etc/shadow).

• Установка корректных прав доступа к файлам запущенных процессов через выполнение "chmod go-w /путь/к/файлу" для всех исполняемых файлов и библиотек, связанных с запущенными в настоящий момент процессами, с последующей проверкой, что каталог, содержащий данные файлы, а также все родительские каталоги недоступны для записи непривилегированным пользователям.

• Установка корректных прав доступа к исполняемым файлам, вызываемым из cron ("chmod go-w путь_к_файлу"), а также к файлам конфигурации cron /etc/crontab и /etc/cron.* ("chmod go-wx путь").

• Установить корректные права доступа к файлам, выполняемым с помощью sudo ("chown root путь_к_файлу" и "chmod go-w путь_к_файлу").

• Установить корректные права доступа к стартовым скриптам системы ("chmod o-w filename" к каждому файлу в /etc/rc#.d, а также к файлам .service).

• Установить корректные права доступа к исполняемым файлам и библиотекам, расположенным по стандартным путям (/bin, /usr/bin, /lib, /lib64 и т.п.), а также к модулям ядра (/lib/modules/версия-текущего-ядра).

• Установить корректные права доступа к SUID/SGID-приложениям путём проведения аудита всех SUID/SGID-приложений и удаления SUID/SGID-флагов с лишних.

• Установить корректные права доступа к содержимому домашних каталогов пользователей (.bash_history, .history, .sh_history, .bash_profile, .bashrc, .profile, .bash_logout и т.п.).

• Установить корректные права доступа к домашним каталогам пользователей (chmod 700 каталог).

• Ограничить доступ к журналу ядра (sysctl -w kernel.dmesg_restrict=1).

• Блокирование утечки информации об адресном пространстве через /proc/kallsyms (sysctl -w kernel.kptr_restrict=2).

• Инициализировать нулями динамическую память ядра (параметр init_on_alloc=1 при загрузке).

• Запрет слияния кэшей slab-аллокатора ядра (параметр slab_nomerge при загрузке).

• Инициализировать механизм IOMMU (параметры iommu=force, iommu.strict=1 и iommu.passthrough=0 при загрузке).

• Рандомизировать расположение ядерного стека (параметр randomize_kstack_offset=1 при загрузке).

• Включить защиту от аппаратных уязвимостей CPU (параметр mitigations=auto,nosmt при загрузке).

• Включить защиту подсистемы eBPF (sysctl -w net.core.bpf_jit_harden=2).

• Отключить устаревший интерфейс vsyscall (параметр vsyscall=none при загрузке).

• Ограничить доступ к событиям производительности (sysctl -w kernel.perf_event_paranoid=3).

• Отключить монтирование виртуальной файловой системы debugfs (параметр debugfs=no-mount или off при загрузке).

• Отключить системный вызов kexec_load (sysctl -w kernel.kexec_load_disabled=1).

• Ограничить использование user namespaces (sysctl -w user.max_user_namespaces=0).

• Запретить системный вызов bpf для непривилегированных пользователей (sysctl -w kernel.unprivileged_bpf_disabled=1).

• Запретить системный вызов userfaultfd для непривилегированных пользователей (sysctl -w vm.unprivileged_userfaultfd=0).

• Запретить автоматическую загрузку модулей ядра, связанных с TTY Line Discipline (sysctl -w dev.tty.ldisc_autoload=0).

• Отключить технологию TSX (Transactional Synchronization Extensions) (параметр tsx=off при загрузке).

• Настроить минимальны виртуальный адрес, который разрешено использовать для mmap (sysctl -w vm.mmap_min_addr = 4096).

• Включить рандомизацию адресного пространства (sysctl -w kernel.randomize_va_space = 2).

• Запретить подключение к другим процессам с помощью ptrace (sysctl -w kernel.yama.ptrace_scope=3).

• Ограничить небезопасные варианты прохода по символическим ссылкам (sysctl -w fs.protected_symlinks=1).

• Ограничить небезопасные варианты работы с жесткими ссылками (sysctl -w fs.protected_hardlinks=1).

• Включить защиту от непреднамеренной записи в FIFO-объект (sysctl -w fs.protected_fifos=2).

• Включить защиту от непреднамеренной записи в файл (sysctl -w fs.protected_regular=2).

• Запретить создание core dump для исполняемых файлов с флагом suid (sysctl -w fs.suid_dumpable=0).

Бьёрн Страуструп (Bjarne Stroustrup), создатель языка C++, опубликовал возражения против выводов, сделанных в отчёте АНБ, в котором организациям было рекомендовано отойти от использования языков программирования, таких как Си и Си++, перекладывающих управление памятью на разработчика, в пользу языков, таких как C#, Go, Java, Ruby, Rust и Swift, обеспечивающих автоматическое управление памятью или выполняющих проверки безопасной работы с памятью во время компиляции.

По мнению Страуструпа упомянутые в отчёте АНБ безопасные языки на деле не превосходят C++ в важных с его точки зрения применениях. В частности, развиваемые последние годы базовые рекомендации по использованию C++ (C++ Core Guidelines) охватывают методы безопасного программирование и предписывают применение средств, гарантирующих безопасную работу с типами и ресурсами. При этом разработчикам, которым не требуются подобные строгие гарантии безопасности, оставляется возможность продолжения использования старых методов разработки.

Страуструп считает, что хороший статический анализатор, соответствующий рекомендациям C++ Core Guidelines, может обеспечить необходимые гарантии безопасности C++ кода, требуя значительно меньше затрат, чем переход на новые безопасные языки программирования. Например, большинство рекомендаций Core Guidelines уже реализованы в статическом анализаторе и профиле безопасной работы с памятью из состава Microsoft Visual Studio. Часть рекомендаций также учтена в статическом анализаторе Clang tidy.

Объектом критики также стало акцентирование отчёта АНБ только на проблемах работы с памятью, оставляя без внимания многие другие проблемы языков программирования, влияющие на безопасность и надёжность. Страуструп рассматривает безопасность как более широкое понятие, различные грани которого могут быть достигнуты комбинацией стиля написания кода, библиотек и статических анализаторов. Для управления включением правил, обеспечивающих безопасность работы с типами и ресурсами, предлагается использовать аннотации в коде и опции компиляторов.

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

Поддержка Subversion была реализована в GitHub в 2010 году для упрощения постепенной миграции на Git пользователей, привыкших к Subversion и продолжающих использование типовых SVN-инструментов. В 2010 году централизованные системы были ещё широко распространены и полное доминирование Git не было очевидным. В настоящее время ситуация изменилась и Git вошёл в обиход примерно у 94% разработчиков, в то время как популярность Subversion заметно снизилась. В текущем виде, Subversion практически не используется для обращения к GitHub, доля обращений к через данную систему снизилась до 0.02% и присутствует всего около 5000 репозиториев для которых наблюдается хотябы одно SVN-обращение в месяц.