Несколько недавно обнаруженных уязвимостей:...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=60185

• Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 14:29 , 27-Ноя-23
• Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 14:32 , 27-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 14:38 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 14:42 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 14:42 , 27-Ноя-23
      • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,нах., 18:04 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 18:26 , 27-Ноя-23
      • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,твой анестезиолог, 18:58 , 27-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Рычаг, 15:10 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 15:12 , 27-Ноя-23
      • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Рычаг, 15:19 , 27-Ноя-23
        • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Рычаг, 15:27 , 27-Ноя-23
        • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,all_glory_to_the_hypnotoad, 16:41 , 27-Ноя-23
          • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Рычаг, 17:15 , 27-Ноя-23
            • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Рычаг, 17:18 , 27-Ноя-23
          • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 22:47 , 27-Ноя-23
          • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 23:14 , 27-Ноя-23
      • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 17:31 , 27-Ноя-23
        • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 18:02 , 27-Ноя-23
          • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,нах., 18:05 , 27-Ноя-23
          • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Рычаг, 18:08 , 27-Ноя-23
            • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 23:06 , 27-Ноя-23
        • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 19:36 , 27-Ноя-23
          • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 19:51 , 27-Ноя-23
            • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:04 , 27-Ноя-23
            • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:06 , 27-Ноя-23
              • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 23:09 , 27-Ноя-23
                • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:23 , 27-Ноя-23
                • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:25 , 27-Ноя-23
                • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:37 , 27-Ноя-23
              • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 13:45 , 28-Ноя-23
            • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:38 , 27-Ноя-23
          • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Рычаг, 21:19 , 27-Ноя-23
            • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:05 , 27-Ноя-23
            • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:26 , 27-Ноя-23
              • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 12:57 , 28-Ноя-23
                • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 21:06 , 28-Ноя-23
                  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 21:06 , 28-Ноя-23
      • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 22:46 , 27-Ноя-23
        • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:49 , 27-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Liin, 15:57 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 18:28 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 23:51 , 27-Ноя-23
• Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Tron is Whistling, 14:44 , 27-Ноя-23
• Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Анонин, 14:53 , 27-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Anonist, 15:10 , 27-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 21:45 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 22:49 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,bOOster, 08:19 , 28-Ноя-23
• Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 14:57 , 27-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,32, 18:20 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноньимъ, 18:50 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 19:22 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,хамоним, 20:50 , 27-Ноя-23
• Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 15:22 , 27-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Денис Попов, 15:34 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 15:46 , 27-Ноя-23
      • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Серб, 13:31 , 28-Ноя-23
        • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 15:42 , 28-Ноя-23
          • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Серб, 16:37 , 28-Ноя-23
• Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,YetAnotherOnanym, 21:28 , 27-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 21:47 , 27-Ноя-23
    • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 22:51 , 27-Ноя-23
• Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 23:43 , 27-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 16:07 , 28-Ноя-23
• Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,Аноним, 12:13 , 28-Ноя-23
  • Уязвимости в Perl, ownCloud, GStreamer и Zephyr RTOS,ыы, 20:17 , 28-Ноя-23

> переменных окружения, которые могут содержать пароль администратора, лицензионный ключ и учётные данные для подключения к почтовому серверу

И так тихонько докеры обошли в изложении...

Вообще таскать чувствительную информацию в env могли придумать только смузихлёбы.

90% современных погромистов это смузихлебы. Либо живи с этим, либо меняй род деятельности.

Ну, меня всегда забавляют вот эти вот новости, что у них там что-то поломалось из-за того, что они котлету прямо тараканам в мусорницу положили.

(честно говоря этому "CVE" стоило бы поставить WONTFIX, потому что нет там уязвимости, разве что в идиотских сетапах)

> разве что в идиотских сетапах

т.е. всех более-менее реальных применениях.

ну ок.

90% любых работников плохо делают свою работу, лол.

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

Ну а по фактам-то есть что сказать? Или только как дедушка выругаться «пук-среньк, смузихлёбы»?

А по фактам - когда в ENV лежат ключи и пароль - это повод взять метлу таки.

Если лежат, то да, а если только передавать, то просто ещё один способ передать значение извне в программу. Прочитал, сделал unsetenv и ходи довольный.

Хм, наверно, если даже и лежат, то тоже ничего страшного. Вот раскрывать переменные окружения куда-то налево это косяк. Всё равно что файл с секретами катнуть в ответ на какой-нибудь запрос.

Ну да ... если бутерброд упал на пол и его успели поднять менее, чем за 5 сек, то считается чистым и можно жрать. Сделать unsetenv примерно как надеть на голову пакет и считать что ты спрятался от окружающих. ENV много где прикапывается, а unsetenv логическая операция, она не удаляет данные из памяти и другие копии ENV-ов. В общем случае корректно передавать секреты через пайпы, а не вот так.

>она не удаляет данные из памяти

А что имеется в виду? Что управление памятью слишком сложно, чтобы считать, что после unsetenv всё пропало? Если на таком уровне рассматривать, то полностью безопасных способов передать секрет не окажется — секрет же всё равно в памяти оказывается, как ни крути.

>не удаляет другие копии ENV-ов

Тут спорить не с чем, разве что вот так возразить: это является проблемой не всегда. Если не отпочковывать новые процессы до setenv, то и не утечёт в другие env-ы.

>передавать секреты через пайпы

Так-то да, но ведь и передающему их нужно взять откуда-то…

Вообще, влезая в разговор про env, я скорее имел в виду, что передавать через окружение не страшнее, чем читать из файла. Да, менее удобно; да, какая-нибудь библиотека может в лог всё окружение «задебажить», но в общем, можно сказать, это такой специфический файл с адресацией.

>Если не отпочковывать новые процессы до setenv

до UNsetenv, UNsetenv.

> Сделать unsetenv примерно как надеть на голову пакет и считать что ты спрятался от окружающих.

Примерно как сделать exec() после fork() и думать, что это дофига безопасно.

> В общем случае корректно передавать секреты через пайпы, а не вот так.

А кто будет их в пайп оправлять? Админ лично? Или какая-то прога, которая возьмёт их из файла или окружения? (Ба-дум-тссс!)

А где ж они должны лежать, дорогой ты мой?

В коде, как принято)

в гитхабе и гитляпе, для надежности.

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

    int getRandomNumber()
    {
      return 4; // chosen by fair dice roll
                // guaranteed to be random
    }

Биндмаунты делать давно разучились?
etcd тоже отменили?
Ясно-понятно.

Ох уж эти «ветераны» «системного» «администрирования». А в etcd ты как попадёшь? На доверии, с нужного айпишника, надеюсь? Или у тебя там один самоподписанный сертификат на все контейнеры со временем жизни в 10 лет? Ясно-понятно.

> Биндмаунты

КЛБ!

Вы главное продолжайте хранить пароли в окружении, не стирая таковое до форка.

Что мешает тебе создать инстанс etcd, доступный только с конкретного контейнера?

Недостаточная степень юникс-ветеранства (этот не вполне изящный термин был введен в повествование, чтобы не использовать неполиткорректное слово, начинающееся на "долбое" и заканчивающийся на "изма").

Поди ещё и вся аппликуха в коньтеноре от рута работает?

Но я уже на эту тему выше отписал.
Отметить NOTABUG и WONTFIX и закрыть.
Чужие кривые руки у себя исправлять - так себе затея.

И вообще, способов передать волатильные параметры - 1000+1, но смузихлёбы как всегда выбрали самый удолбищный, который ещё и между процессами наследуется.

Как говорится, есть два стула. На одном придуманная сорок лет назад юникс-дедами система переменных окружения. На другом отдельный инстанс distributed reliable key-value store written in Go доступный только с конкретного контейнера, поднятый для того чтобы приложение почитало из него конфиг и пароли. На какой стул сам сядешь, а на какой смузихлёба посадишь?

Поверь, если у тебя пароли и ключи лежат в ENV - даже один самоподписанный сертификат будет лучше.

И этот человек ещё что-то про смузихлёбов говорил, хех

> И этот человек ещё что-то про смузихлёбов говорил, хех

Да и перед exec можете новое окружение не создавать - всё нормально.

Интересно, что этим господам мешало запустить внутри коньтенора сервис с очищенным от внешних параметров env?

То, что ему эти параметры НУЖНЫ?

А переложить параметры в файлы конфигурации до запуска религия не позволяет?
Или в смузи-мирке так модно волатильные данные отдавать всем дочерним процессам, пока какой-нибудь не протечёт?

// s/волатильные/сенситивные/

> А по фактам - когда в ENV лежат ключи и пароль - это повод взять метлу таки.

Может, начать с того, что если приложение запускается - это уже повод взять метлу?

(Потому что если оно запустилось, то в его памяти хоть что-то интересное, да найдётся)

И вот тут начинается замечательная проблема.
Форкнул ты какой-нибудь ffmpeg для обработки. ENV туда благополучно унаследовался.
Весь этот твой ключ от S3 (который часто один, что не лучше самоподписного сертификата) ему не нужен, и он его не использует.
Но если там найдётся CVE с утечкой памяти процесса в результат - ну, ты понял.

Да вобщем ничего страшного в использовании паролей в env нет, только если эту инфу не раскрывают наружу всем, кому ни попадя, как ребята с GetPhpInfo.php, который явно для дебага использовался и по какой-то причине был включен в прод. Хотя, конечно, лишнего в env тоже быть не должно. И если от пароля mysql там толку снаружи не будет, то от пароля админа - может пострадать админка. Разумно надо к этому подходить, взвешивать риски.

Если у злоумышленника есть доступ в env то где бы ты не хранил ключи у него по любому уже есть доступ.

А кто сказал, что env может утечь только через phpinfo?
Любая дыра с утечкой данных из памяти процесса во внешней 3rd-party тулзе - и привет.
Это при том, что самому процессу твой env вообще может быть не нужен, но поскольку его не почистили - он туда и унаследовался.

Мораль?
Чистить env надо после принятия параметров, чистить.

Лал, оказывается это мелкософт снова обломал все барбершопы.

vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php

> запись за пределы выделенного буфера
> Use-After-Free + переполнение буфера
> и еще почти 25 переполнений буфера с RCE

"C. C newer changes"

Такое ощущение, что на Zephyr просто натравили какой-то анализатор и сразу попер высококачественный код лучших в мире погромистов.

ChatGPT любой код превратит в божественный если правильно уметь задавать промпты.

> "C. C newer changes"

А этот пацак всё время говорит на языках, продолжения которых не знает!

Он прав. The newer C gets, the more dangerous it becomes.

Абсолютно в тему :)

На сайте зефирки
"A proven RTOS ecosystem, by developers, for developers" (про юзеров они ничего не говорят) )
"strives to deliver the best-in-class RTOS"

а на деле фиксы вида
    if (params->ssid_length > WIFI_SSID_MAX_LEN) {
или ошибки Signed to unsigned conversion errors and buffer overflow
но если одного буфера мало, можно переполнить два Two buffer overflow vulnerabilities in Zephyr USB code

Итак дырявые WiFi стек, стек Bluetooth, USB-стек, файловой системе, очередной вайфай eS-WiFi и шина CANbus.
Такое впечатление, что у них нет ни одной подсистемы без дыреней /_о

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

> В общем типи-кал С

Да когда вы уже создадите свой проц который будет питон чистый исполнять или яву, и свалите с этой планеты в свою нарнию

Явовскип так-то были.

В си процы вообще довольно отвратительная штука. Они числа дробят быстро да. А код общего назначения у них черещ костыли работает.

Интел конечно сильно старался десятки лет...

А не слишком это сложное решение, вместо того чтобы ПРОСТО проверять входные данные?
Или вы считаете что дыряшечники настолько безнадежны, что проще свой проц запилить, чем этих необучаемых заставить?

Именно из-за Си шников которые любили использовать каки типа
(*(struct foo *)NULL) = x
ARM для Cortex-M прямо в железо вхардкодила поведение, что на это говоно кидается безусловный и немедленный HardFault
Вот как приходится бороться с криворукостью убогих!

Возможно еще через 5 лет придется добавлять обязательную неотключаемую проверку границ массива, прям в процессор.
Ибо языку почти полтос, ядру больше 30ки, а уязвимости вида "шел сишник по массиву, взял и сделал out-of-bounds" живут и процветают до сих пор.

Открывает сайтик Zephyr:

> Build secure [..] devices with Zephyr®
> Developed with security in mind.
> Employs an in-depth security development lifecycle

А в реальности:

> 25 уязвимостей, большинство из которых потенциально могут привести к выполнению кода атакующего

Понты дороже денег. Знаменитая сишечная секьюрность.

>Понты дороже денег. Знаменитая сишечная секьюрность.

Не бойся, остальные языки безопасные. А упоминание Perl в первом абзаце тебе примерещилось.

"Уязвимость перла" почему-то находится в файле regcomp.c
Запутались с индексах, с кем бывает.

Там не в индексах запутались, а в признаках типа кодировки.

UTF-8, с его переменным размером символа, требует некоторой возни с указателями.

> UTF-8, с его переменным размером символа, требует некоторой возни с указателями.

Еще раз. Там проблема с их собственными хаками работы с utf8.

Когда в начале строки пишется признак того, что строка в utf8. Иногда дважды.

> злоумышленник может разместить свой cmd.exe в каталог C:\ProgramData и поднять свои привилегии, если администратор запустит Perl-скрипт из этого каталога

Если админ запускает файлы из каталога с такими разрешениями, то специфичная для перла последовательность поиска исполняемых файлов как-то уже мало на что влияет.

Когда проломят череп, лишая тебя кошелька и мобилы ты знай — это не преступники плохие, просто ты ходил не там и не в то время.

Ну, если ты пришёл ночью в фавелы, то дальнейшая последовательность действий действительно ни на что не влияет :)

Вот и прекрасно, обнаружили - пофиксили, теперь ПО на божественной Сишечке стало только лучше. Не бывает багов только у тех языков, на которых ничего не пишут ))

> ПО на божественной Сишечке стало только лучше

Дыры его только украшают :)

>Уязвимости в Perl

Помнится мне, что раньше на конференциях, в докладах, посвящённых уязвимостям в самом языке Perl, докладчик любил вставлять слайд, на котором было написано:
PERL IS DEAD, DON'T USE PERL.

и где этот докладчик теперь? а perl жив :)