Профиль: Аноним (вход | регистрация) неRU opennet.me  
The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В OpenBSD устранена локальная уявзимость, позволяющая получить права root

16.07.2026 09:54 (MSK)

Проект OpenBSD опубликовал исправление уязвимости (CVE-2026-57589) в ядре, затрагивающей реализацию системных вызовов для работы с семафорами System V (sem). Проблема вызвана обращением к уже освобождённой памяти в функции sys_semget() и может эксплуатироваться для получения прав root непривилегированным локальным пользователем в конфигурации по умолчанию.

В кодовую базу OpenBSD-current исправление было включено 23 мая, но для уже выпущенных релизов патчи опубликованы только сегодня. Ошибка присутствовала в коде 23 года и была выявлена в рамках инициативы Patch the Planet по проверке открытых проектов AI-моделями OpenAI.

Помимо отмеченной проблемы опубликовано несколько исправлений, которые не помечены как устранения уязвимостей, но, судя по описанию, могут быть связаны с безопасностью: недостаточная проверка входных данных в коде IPsec и IPComp; двойное освобождение памяти в сервере NFS; повреждение памяти в коде для работы с блокировками в функциях pinsyscall и kbind.

  1. Главная ссылка к новости (https://www.mail-archive.com/a...)
  2. OpenNews: Релиз OpenBSD 7.9
  3. OpenNews: В OpenBSD переименовали поле в pfsync после ложного AI-отчёта об уязвимости
  4. OpenNews: Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась исправлена не полностью
  5. OpenNews: Удалённая уязвимость в IPv6-стеке OpenBSD
  6. OpenNews: Уязвимость в NFS-сервере FreeBSD и OpenBSD, приводящая к удалённому выполнению кода
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/65867-openbsd
Ключевые слова: openbsd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (16) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:57, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я так понимаю софт на Коболе 60 летней давности еще не охвачен.
    В рекламных целях, на безрыбье и лещ - рыба.
     
     
  • 2.4, Аноним (4), 10:11, 16/07/2026 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Там искать нечего, потому-что писали диды дидов, и это были боги. А боги - безгрешны и ошибок не делают по определению.
     

  • 1.2, Смузихеб забывший пароль (?), 10:04, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Как так академики поживают ?
    Докторскую на устранении этой уязвимости уже кому-то пообещали ?)
     
  • 1.3, psv (??), 10:06, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ошибка внесена в 2023. Но почему нет последовательности "исправления" кода которая к ней привела? В том числе авторов патчей (со ссылками где они еще светились)?
     
     
  • 2.8, Аноним (8), 10:39, 16/07/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Перечитай еще раз. В 2003
     
  • 2.12, Аноним (12), 10:55, 16/07/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    претензии от человека, который прочитать без ошибок не может
     

  • 1.5, ryoken (ok), 10:13, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отпечатков копыт ИИ не найдено?
     
  • 1.7, openssh_user (ok), 10:25, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Странно, что для релизов выпуск исправлений затянулся
     
  • 1.9, Аноним (9), 10:40, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Локальная

    А ещё кто-то локально может подойти к моему компьютеру и стукнуть по нему молотком.

     
     
  • 2.10, Аноним (8), 10:45, 16/07/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Либо попасть через другую дыру под пользователем nobody и стать рутом.
     
  • 2.11, Аноним9000 (?), 10:49, 16/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Путаете локальный доступ и физический
     

  • 1.13, EmmGold (ok), 11:10, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Only  ̶t̶w̶o̶ three remote holes in the default install, in a heck of a long time!
     
     
  • 2.14, Аноним (14), 11:47, 16/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, она не remote, это же локально эксплуатируемая уязвимость.
     

  • 1.15, крокодил мимо.. (?), 11:48, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Проблема вызвана обращением к уже освобождённой памяти в функции sys_semget() и может эксплуатироваться для получения прав root непривилегированным локальным пользователем в конфигурации по умолчанию.

    вариант эксплойта для подтверждения есть?
    судя по:
    https://ftp.openbsd.org/pub/OpenBSD/patches/7.9/common/005_sysv.patch.sig
    не только и не столько sys_semget(), скорее "обычная" безалаберность.. что тоже не оправдание..

     
  • 1.16, Аноним (16), 11:50, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Погодите.
    Это та самая бздя которая мега-защищенная и они всей командой наяривают на бижопашность как стая мартышек?

    Выходит не такая она крутая.

     
  • 1.17, Аноним (17), 11:51, 16/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто знает, насколько эта нейронка права?:

    Уязвимость находится в функции 'semop' (строки 684–705) и представляет собой **гонку с использованием после освобождения (use-after-free)**.

    **Суть проблемы:**

    1. Перед вызовом 'tsleep_nsec()' процесс сохраняет локальный указатель 'semaptr' на структуру набора семафоров. Затем он засыпает, отпуская блокировку семафорной подсистемы.
    2. Пока процесс спит, другой поток/процесс может удалить этот набор семафоров через 'IPC_RMID'. Память, на которую указывает 'semaptr', освобождается ('free' + 'pool_put'), а элемент массива 'sema[semid]' обнуляется.
    3. Если после этого (до пробуждения первого процесса) создаётся *новый* набор семафоров с тем же идентификатором 'semid' (реиспользование индекса), 'sema[semid]' будет указывать уже на новую структуру.
    4. Первый процесс просыпается, перезахватывает блокировку и выполняет проверку:
       '''c
       if (sema[semid] == NULL ||
           semaptr->sem_perm.seq != IPCID_TO_SEQ(SCARG(uap, semid)))
       '''
       При этом 'semaptr' **не обновляется** из 'sema[semid]', а продолжает указывать на уже освобождённую память.
    5. Так как 'sema[semid]' теперь не 'NULL' (новый набор), короткого замыкания по первому условию не происходит, и код читает поле 'sem_perm.seq' из освобождённой памяти — это **use-after-free**.
    6. Если освобождённая память была переиспользована и злоумышленник смог записать туда старый номер последовательности, проверка может пройти, и дальнейшая логика продолжит работать с висячим указателем 'semaptr', что ведёт к контролируемому повреждению памяти ядра и потенциальному повышению привилегий.

    **Где именно в коде:** строки 693–700 — после 'tsleep_nsec' используется 'semaptr' без переприсваивания из 'sema[semid]'. Исправление должно включать сброс 'semaptr = sema[semid]' после пробуждения и соответствующую обработку 'NULL'.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру