The OpenNET Project / Index page

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

Уязвимость в Glibc ld.so, позволяющая получить права root в большинстве дистрибутивов Linux

03.10.2023 22:30

Компания Qualys выявила опасную уязвимость (CVE-2023-4911) в компоновщике ld.so, поставляемом в составе системной Си-библиотеки Glibc (GNU libc). Уязвимость, которой присвоено кодовое имя "Looney Tunables", позволяет локальному пользователю поднять свои привилегии в системе через указание специально оформленных данных в переменной окружения GLIBC_TUNABLES перед запуском исполняемого файла с флагом suid root, например, /usr/bin/su.

Возможность успешной эксплуатации уязвимости продемонстрирована в Fedora 37 и 38, Ubuntu 22.04 и 23.04, Debian 11, 12 и 13. Предполагается, что уязвимость проявляется и в любых других дистрибутивах, использующих Glibc. Дистрибутивы на базе системной Си-библиотеки Musl, такие как Alpine Linux, проблеме не подвержены. Уязвимость устранена в патче, добавленном 2 октября. Проследить за выпуском обновлений пакетов в дистрибутивах можно на страницах Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, Gentoo, ALT Linux.

Уязвимость вызвана изменением, внесённым в апреле 2021 года и вошедшим в состав выпуска glibc 2.34. Из-за ошибки в коде разбора строки, указанной в переменной окружения GLIBC_TUNABLES, некорректная комбинация параметров в данной переменной приводит к записи разобранного значения за пределы выделенного буфера. Проблема проявляется когда вместо штатных последовательностей "name=val", параметры заданы в форме c двойным присвоением "name=name=val". В этом случае присвоение обрабатывается дважды, вначале как "name=name=val", а потом как "name=val". Из-за подобной двойной обработки образуется результат "name=name=val:name=val", размер которого превышает размер буфера tunestr.

Исследователями подготовлен стабильно работающий эксплоит, который позволяет получить права root при применении практически с любой программой с флагом suid root. Исключение составляют утилита sudo (меняет значение ELF RUNPATH), утилиты chage и passwd в Fedora (защищены отдельными правилами SELinux) и утилита snap-confine в Ubuntu (защищена отдельными правилами AppArmor). Предложенный метод эксплуатации также не работает в RHEL 8 и RHEL 9, хотя данные ветки и подвержены уязвимости (для атаки требуется создание иного эксплоита). Код эксплоита будет опубликован позднее после повсеместного устранения уязвимости. Проверить подверженность своей системы уязвимости можно ниже указанной командой, которая в случае наличия проблемы завершится крахом:


   env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" "Z=`printf '%08192x' 1`" /usr/bin/su --help

Отдельно отмечается устранение в Glibc ещё двух уязвимостей:

  • CVE-2023-4806 - обращение к уже освобождённой области памяти (use-after-free) в функции getaddrinfo(), проявляющееся когда NSS-плагин реализует только call-back-вызовы "_gethostbyname2_r" и "_getcanonname_r", но не поддерживает вызов "_gethostbyname3_r". Для эксплуатации уязвимости DNS-сервер должен вернуть для запрошенного хоста большое число адресов IPv6 и IPv4, что приведёт к краху процесса, вызвавшего функцию getaddrinfo для семейства AF_INET6 при выставлении флагов AI_CANONNAME, AI_ALL и AI_V4MAPPED.
  • CVE-2023-5156 (затрагивает только версии с первоначальным исправлением CVE-2023-4806) - утечка содержимого памяти при вызове функции getaddrinfo для семейства адресов AF_INET6 с выставленными флагами AI_CANONNAME, AI_ALL и AI_V4MAPPED.

Дополнение: Доступны рабочие прототипы эксплоитов, созданные не связанными с Qualys исследователями: Первый протестирован в Ubuntu 22.04.3, второй - в Ubuntu 22.10.

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Уязвимость в Glibc, позволяющая поднять привилегии в системе
  3. OpenNews: Уязвимость в Glibc ld.so, позволяющая поднять свои привилегии в системе
  4. OpenNews: Удалённо эксплуатируемая уязвимость в Glibc, охватывающая большинство сетевых приложений в Linux
  5. OpenNews: Критическая уязвимость в Glibc, которая может привести к удалённому выполнению кода в Linux
  6. OpenNews: Критическая уязвимость в bash, которая может привести к удалённому запуску команд
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59867-glibc
Ключевые слова: glibc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (153) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 00:18, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    сишники не осилили str.split(sep="=", maxsplit=1)
     
     
  • 2.7, Вы забыли заполнить поле Name (?), 01:20, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    https://docs.gtk.org/glib/func.strsplit.html
     
     
  • 3.13, Аноня (?), 02:29, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +11 +/
    glib это не glibc
     
  • 2.12, Аноня (?), 02:27, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • –11 +/
    Да не просто Сишники, а те самые деды! Эксперты, монстры! Отцы-основатели!
     
     
  • 3.18, Аноним (18), 06:37, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Деды ... хотя всё возможно - акселерация

    > Уязвимость вызвана изменением, внесённым в апреле 2021 года

    А вам лишь бы ...

     
  • 3.19, Аноним (18), 06:39, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Это он. Не сильно на отца-основателя похож.

    https://sessionize.com/siddhesh-poyarekar#:~:text=Siddhesh%20Poyarekar�

     
     
  • 4.31, Аноним (31), 07:55, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +18 +/
    >Siddhesh Poyarekar is a toolchain hacker and a Tech Lead at Linaro, managing a team of toolchain wizards.

    Волшебник б**

     
     
  • 5.81, Аноним (81), 12:20, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +7 +/
    все честно написано: Siddhesh Poyarekar is a toolchain hacker
    хакер - вот и сломал тулчейн.
     
     
  • 6.102, Аноним (102), 16:20, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > все честно написано: Siddhesh Poyarekar is a toolchain hacker
    > хакер - вот и сломал тулчейн.

    А разве не хакер? Сломал линухи всей планете и глазом не моргнул. Индусский кот - такой он, вот.

     
  • 5.85, Аноним (-), 13:57, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так он же индус!
     
  • 4.36, Аноним 80_уровня (ok), 08:09, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Понаведут смуззеров в глибц...
     
     
  • 5.86, Аноним (-), 13:57, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Он не смуззер, он индус.
     
     
  • 6.165, 128557 (?), 16:14, 31/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Индус - это диагноз. Каким выглядит мир, когда в голове одни танцы?
     
  • 3.136, Аноним (136), 18:52, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Уязвимость вызвана изменением, внесённым в апреле 2021 года и вошедшим в состав выпуска glibc 2.34.

    Это не деды, а понабежавшие пионеры-двоечнеки.

     
  • 2.22, Аноним (22), 07:00, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А ты не осилил написать glibc.
     
  • 2.32, АнонПапка (?), 08:00, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Кажется это Python, а в С такого нету ))))))) вот и неосилили
     
  • 2.58, Пряник (?), 09:50, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Действительно крайне нубская ошибка. Было вроде в каких-то языках или парсерах, но быстро исправляли.
     
     
  • 3.62, фнон (?), 10:02, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а тут целое ядро и 2 года не могли заметить...
    но ведь тысячи глаз!
     
     
  • 4.64, Пряник (?), 10:07, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И статические анализаторы кода. Должны были ещё при коммите заметить сразу.
     
     
  • 5.72, Аноним (72), 10:53, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А разве в ядре есть обязательный стат. анализатор?
    Проверка которого была бы необходима для создания PR?

    Оно же все древнее как копролит мамонта, куда исправление можно отправить почтой (хорошо хоть не голубиной)).
    Видел проекты типа Continuous Kernel Integration (CKI), но насколько понимаю оно не обязательно.

    Ядру нужен какой-то "диктатор" на пол годика, чтобы заставить всех поставить линтер, стат. анализ и сделать их проверки обязательными)

     
  • 4.103, Аноним (102), 16:21, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а тут целое ядро и 2 года не могли заметить...

    Какое еще ядро, лол.
    - Какого цвета наш учебник?!
    - Какой предмет мы сдаем?
    - Во валит, гад!

     
  • 4.149, Kuromi (ok), 17:12, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как вариант - не заметили потому что отвернулись в сторону. Я не фанат конспирологии, но иногда слишком уж похоже.
     
  • 2.110, Аноним (110), 18:27, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Как часто вижу подобные комментарии. Но почему никто не написал ничего на другом языке?
     
  • 2.145, uis (??), 12:19, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    strstr
     

  • 1.3, Аноним (3), 00:19, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Это же сколько раз они на одни и те же грабли наступили с переменными окружения в suid-программах?

    https://www.opennet.dev/28338
    https://www.opennet.dev/28390
    https://www.opennet.dev/40667
    https://www.opennet.dev/46724
    https://www.opennet.dev/47722
    https://www.opennet.dev/52012

     
     
  • 2.34, Аноним (31), 08:04, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Всё как завещали деды!

    https://web.mit.edu/~simsong/www/ugh.pdf

    The Unix concept called SUID, or setuid, raises as many security problems
    as the superuser concept does. SUID is a built-in security hole that provides
    a way for regular users to run commands that require special privileges to
    operate.
    <...>
    AT&T was so pleased with the SUID concept that it patented it. The intent
    was that SUID would simplify operating system design by obviating the
    need for a monolithic subsystem responsible for all aspects of system secu-
    rity. Experience has shown that most of Unix's security flaws come from
    SUID programs.

     
     
  • 3.135, InuYasha (??), 17:24, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    AT&T - та ещё корпорация зла. Позлее гугла в свои времена.
     
  • 2.52, фнон (?), 09:27, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ты понимаешь, что если сделать один раз нормально - то больше код трогать не придется
    а так еще поколения шышников будут кормиться на исправлении ошибок
    (вспоминается анекдот про молодого адвоката, который выиграл семейное дело на первом же заседании)
     
  • 2.59, Пряник (?), 09:51, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще концепция suid напрягает.
     
     
  • 3.78, Чи (?), 11:31, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну отказаться от этой концепции видимо уже не получится. Как вариант обмазать все эти суид бинари правилами selinux в обязательно порядке.
     
     
  • 4.88, Аноним (-), 13:58, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    SELinux - лишнее звено.
     
  • 4.91, Аноним (91), 14:29, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Почему не отказаться? Что из этого нельзя выкинуть? А других гнилых бинарей у меня и нет.

    /bin/su
    /bin/passwd
    /usr/bin/crontab
    /usr/bin/cgexec
    /usr/bin/newuidmap
    /usr/bin/chsh
    /usr/bin/pkexec
    /usr/bin/newgrp
    /usr/bin/gpasswd
    /usr/bin/nvidia-modprobe
    /usr/bin/ping
    /usr/bin/expiry
    /usr/bin/chage
    /usr/bin/newgidmap
    /usr/bin/chfn

     
  • 4.111, Аноним (111), 18:37, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Получится, если будет политическая воля. Более 20 лет шло балабольство о невозможности отказа от GIL. Потом пришёл Micro$oft, нанял ключевых разрабов, и в течение года проблема будет решена, а несогласным придётся утереться. Если найдётся корпорация, которая смажет всё деньгами - проблема мигом будет решена. И suid уберут, и программы, которые нужно будет править, либо поправят, либо на свалку истории отправят.
     
  • 4.146, uis (??), 12:24, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Эммм... POSIX file capabilities.
     
  • 2.115, Аноним (115), 19:42, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Причем каждый раз когда я пишу про SUID на этом форуме всегда найдется парочка д... большой текст свёрнут, показать
     
     
  • 3.117, Анонин (?), 21:14, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто интересно, а если ли хоть какая-то система где все перечисленное реализовано, причем правильно, или хотя бы близко к нему?

    И насколько оно юзерфрендли? Потому что за линуксом сидят не только пользователи с отдельным отделом ИБ, но и обычное юзверье, которому все ваши ACL и политики - китайская грамота.

     
  • 3.119, User (??), 22:21, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Осталось ответить на вопрос "ну и вот нахрена это ХОТЬ КОМУ-НИБУДЬ чтоб это самому делать или хотя бы денег за это заплатить"? И можно в путь.
     
     
  • 4.129, Аноним (115), 12:54, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вопросы по всем перечисленным пунктам многократно поднимались в списках рассылки... большой текст свёрнут, показать
     
     
  • 5.137, User (??), 19:07, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Ну, в общем я и говорю - примерно всем пох Или не пох ... большой текст свёрнут, показать
     
  • 3.120, Аноним (120), 22:28, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Решается эта проблема так:

    Получается Windows. Но ведь она давно уже есть, зачем изобретать велосипед?

     
     
  • 4.128, Аноним (115), 12:18, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Во-первых не просто Windows, а именно Windows NT Внутри Windows есть огромное к... большой текст свёрнут, показать
     
     
  • 5.130, Аноним (130), 13:05, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Suid не обходит selinux.
     
     
  • 6.131, Аноним (115), 13:26, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Он не обходит его на этапе работы с контекстом вызываемой утилиты, в том и тольк... большой текст свёрнут, показать
     
  • 5.157, Аноним (157), 21:13, 08/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Жопslashes, case-нетерпимость, буквы устройств, ФС без DAC и стойкое желание всё... большой текст свёрнут, показать
     
     
  • 6.159, User (??), 09:44, 10/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> из принципа не следует стандартам POSIX
    > Жопslashes, case-нетерпимость, буквы устройств, ФС без DAC и стойкое желание всё это
    > насадить всем другим, POSIX-совместимым ОС, а хоть бы и через железных
    > вендоров (см. UEFI), -- не дадут соврать. Из принципа. Чтобы всё,
    > что напишут "Developers, Developers", работало только в Пинде и нигде больше
    > - без переписывания.

    Нууу... вы так говорите, будто в этом POSIX in our days есть хоть что-то хорошее - это даже не говоря о том, что на "posix compilance" linux "in general" никогда и не закладывался )

     
     
  • 7.160, Аноним (160), 10:04, 10/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Одна только унификация - на вес золота. Много хорошего, за неимением лучшего.
     
     
  • 8.161, User (??), 10:14, 10/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот кушайте posix acl, не обляпайтесь Ой, а он внезапно не часть POSIX У... текст свёрнут, показать
     
  • 3.150, Kuromi (ok), 17:21, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    "Я в реальной жизни встречал баранов, которые выключили SELinux, понаставили "chmod 777" и пренебрежительно рассказывают мне о высочайшей безопасности Linux  и про то что Windows на железо им страшно ставить. "

    Ну разумеется. Потому что безопасность и удобство очень редко идут рука об руку и в какой-то момент любой человек может сказать "да к черту, залолбало разбираться почему Х не запускается или Y валится с ошибкой потому что что-то где-то права не такие как надо (по умолчанию или наоборот)." И тогда в ход идут "три топора" (извините, не удержался). Это чаще всего не баранство, а просто "усталось". По той же самой причине народ прется через рельсы (и попадает регулярно под поезд) когда обходной безопасный путь "всего на килотметр-два длиннее".

     
  • 3.156, крокодил мимо.. (?), 18:53, 08/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    кмк, необходимо и достаточно внимательно аудировать код утилит, требующих 4000 ... большой текст свёрнут, показать
     

     ....большая нить свёрнута, показать (24)

  • 1.4, Аноним (4), 00:49, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Васян решил добавить самописный парсер строк.
     
     
  • 2.6, morphe (?), 01:00, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Зато без всяких cargo!
     
     
  • 3.24, Аноним (22), 07:01, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И чего там в карго нету глибс на безопасТном?
     
  • 3.112, мяя (?), 18:42, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но Раст базируется на libc.
     
     
  • 4.118, Аноним (118), 21:52, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но Раст базируется на libc.

    Но только в грезах и фантазиях Военов Супротив Раста.

    man syscalls
    > System calls are generally not invoked directly, but rather via wrapper functions in glibc

     

  • 1.5, Аноним (91), 00:58, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И почему я не удивлён. А разве переменные окружения не должны очищаться при запуске суидных бинарей как раз на такой случай?
     
     
  • 2.29, bergentroll (ok), 07:47, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Очевидно нет, если переменная предполагается для чтения.
     
     
  • 3.113, Аноним (113), 18:50, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А есть какие-то иные переменные окружения?
     

  • 1.8, Аноним (8), 01:20, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Debian 11 тоже подвержен уязвимости из-за того, что патч из glibc-2.34 был бэкпоритрован в glibc-2.31-12.
    https://security-tracker.debian.org/tracker/CVE-2023-4911
    Заплатка для Debian 11 уже выпущена
     
     
  • 2.11, marten (ok), 01:42, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ubuntu 22.04 - тоже была уязвима, апдейт выпущен
     
  • 2.23, СисадминА (?), 07:00, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Пушто всякие дебунты это недодистрибутивы, багованые школоподелки. В мире осталось только два нормальных дистрибутива, это Альт и RHEL.
     
     
  • 3.100, еизвестный (?), 15:55, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Alt очень хорош. Ядро без нареканий собирают. Завидую. У меня норм только 4.19 получается.(
     
  • 3.138, Аноним (130), 19:23, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Slackware отличный.
     

  • 1.9, cheburnator9000 (ok), 01:36, 04/10/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +4 +/
     

     ....ответы скрыты (2)

  • 1.10, Tron is Whistling (?), 01:40, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Такого класса дыры нельзя публиковать до устранения.
     
     
  • 2.26, Аноним (22), 07:04, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Всё импортозамещение уже взломано.
     
     
  • 3.77, Аноним (77), 11:26, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем "партнёры" будут ломать своих агентов, внедрившиз бэкдур в госструктуры?
     
  • 3.94, Neon (??), 14:51, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Американские сервера тоже)))
     
  • 2.43, eugener (ok), 08:55, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я вчера обнову на дебиан 12 поставил около 10-ти вечера, а новость опубликована в 22:30. Норм.
     

  • 1.14, birdie (ok), 03:27, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Сказать, что я в бешенстве - ничего не сказать.

    За один месяц:

    Remote: webp, vpx

    Local root: glibc - и оно ещё даже не пофикшено и это не всё!

    CVE-2023-4806: When an NSS plugin only implements the _gethostbyname2_r and _getcanonname_r callbacks, getaddrinfo could use memory that was freed during buffer resizing, potentially causing a crash or read or write to arbitrary memory.

    CVE-2023-4527: If the system is configured in no-aaaa mode via /etc/resolv.conf, getaddrinfo is called for the AF_UNSPEC address family, and a DNS response is received over TCP that is larger than 2048 bytes, getaddrinfo may potentially disclose stack contents via the returned address data, or crash.

    Пользователям Fedora:

    sudo dnf upgrade --enablerepo=updates-testing glibc

    Спать, скоро солнце встанет, ну и день поганый. Работал до 4 утра, потом опсос снимает деньги все со счёта по ошибке, я чуть не остался на работе из-за этого.

     
     
  • 2.16, WE (?), 06:21, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Зачем пользователям федоры секюр апдейты? подождал неделю и новый релиз.
     
  • 2.35, mos87 (ok), 08:05, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    make a sign
     
  • 2.40, Аноним (22), 08:22, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Геройствования работы до 4 утра, мало того что это покрытие чьего-то про.кола, это напрочь сбитый лайф баланс. Здоровье не купишь не надо так.
     
     
  • 3.116, Аноним (116), 19:42, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > это напрочь сбитый лайф баланс

    В том-то и дело, что нет у него никакого лайфа...

     
  • 2.53, Анонин (?), 09:31, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > я в бешенстве

    А зачем тебе возмущаться? Это же лучшая ось написанная на божественном языке!
    А не какие=то поделки корпорастов-смузихлебов.
    Расслабься и получай удовольствие))

     

  • 1.15, Аноним (120), 05:36, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Из-за ошибки в коде разбора строки, указанной в переменной окружения GLIBC_TUNABLES, некорректная комбинация параметров в данной переменной приводит к записи разобранного значения за пределы выделенного буфера.

    Как же это было предсказуемо если знаешь на каком языке библиотека написана.

     
     
  • 2.28, Аноним (28), 07:39, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Т.е. если в новости не написать на каком, то это автоматом станет для тебя непредсказуемым, а если ещё и физику в школе учить не будешь, то мир вообще будет полон загадок и волшебства
     
     
  • 3.41, Аноним (22), 08:23, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да низкий уровень образования создаёт причудливые логические связи.
     
  • 3.121, Аноним (120), 22:34, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Дружище, если что-то писать на делфи, то с высокой степенью вероятности в коде будут глюки вида "объект на форму кинули, но все нужные методы для него создать забыли". Если питонятина, то можно ждать что штука которая запускалась пару версий назад не запустится на текущей. Если сишка - жди проблем с памятью.
     
     
  • 4.162, inferrna (ok), 16:13, 12/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >питонятина
    >запускалась пару версий назад не запустится на текущей

    Не совсем так. Сам питон в минорных версиях ничего не ломает, это скорее из мира php. А вот что ломает питон, ноду, пых и даже хачкель, так это новые версии библиотек, ибо нет нормального версионирования зависимостей.

     

  • 1.17, Аноним (17), 06:33, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >CVE-2023-4527

    *trollmode* Включи IPv6 и спи спокойно.

     
  • 1.21, Аноним (21), 06:50, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Весь, ВЕСЬ код в dl-tunables.c написан в стиле "дедовское сишное буллшит-бинго", с неявными  предположениями о размере буферов, переиспользованием переменных, интами для индексации массивов и хранения длины строк.

    С таким стилем кодирования, чудо что деды дали в рейтузы только сейчас.

    >Siddhesh is one of the maintainers of the GNU C Library and contributes to various Open Source toolchain projects. At Red Hat his focus is primarily on toolchain security.

    Сесурити специалисты не смогли в размеры буферов. Снова.

     
     
  • 2.37, Аноним (22), 08:12, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так ты это молодой, давай переписывай. Критиковать каждый умеет.
     
     
  • 3.49, фнон (?), 09:25, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    а что лучше критиковать или писать вот такой код?
     
     
  • 4.76, Аноним (76), 11:12, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В твой случае лучше молчать
     
  • 3.61, Пряник (?), 09:57, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Одно другому не мешает :)
     
  • 2.158, Аноним (157), 21:26, 08/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > деды дали в рейтузы

    Деды на пенсии давно. А в леггинсы дали молодые опеннет-балаболы, сами-то они безрукие, только дедовское пользуют и ругают.

     

  • 1.27, Аноним (27), 07:18, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да что ж это такое, а... Этому безобразию настанет когда-нибудь конец или нет???
     
  • 1.39, Аноним (39), 08:13, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    На Эльбрусах не срабатывает.
     
     
  • 2.45, Аноним (45), 09:13, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А эти Эльбрусы сейчас с тобой в одной комнате, покажи где ты их трогал?
     
     
  • 3.68, Аноним (68), 10:42, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    и на столе есть и МЦСТ даёт доступ по ssh, погуглите
     
     
  • 4.108, An (??), 18:00, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Сначала нужно, чтобы он появился в продаже по сравнимым с интелом и амд ценам.
    Потом - чтобы под него были доступны открытая ось и открытый компилятор. Чтобы скачать и собрать из сорцов можно было.
    Как все это появится - зовите.
     
     
  • 5.152, Аноним (152), 18:03, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем? Ты не нужен, сиди и жди халяву дальше.
     
     
  • 6.155, An (??), 16:36, 08/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ок. Тогда смотрим на альтернативы: x86_64, ARM, RISC-V.
    А вы и дальше сидите в бункере со своей "прелестью".
     
  • 2.56, Аноним (56), 09:40, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А какая версия Glibc там? Небось, ещё 2.2x какая-то.
     
     
  • 3.69, Аноним (68), 10:43, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    yukari:~$ ls -l /lib/*libc*
    -rwxr-xr-x 1 root root 5265800 июн  7 21:24 /lib/libc-2.29.so
    -rwxr-xr-x 1 root root  108128 июн  7 21:24 /lib/libcrypt-2.29.so
    lrwxrwxrwx 1 root root      16 июн  7 21:24 /lib/libcrypt.so.1 -> libcrypt-2.29.so
    lrwxrwxrwx 1 root root      12 июн  7 21:24 /lib/libc.so.6 -> libc-2.29.so
     
     
  • 4.70, Аноним (68), 10:44, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    @yukari:~$ lcc -v
    lcc:1.26.20:Jun--6-2023:e2k-v4-linux
    Thread model: posix
    gcc version 9.3.0 compatible.
     

  • 1.44, ыы (?), 08:56, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    >Предложенный метод эксплуатации также не работает в RHEL 8 и RHEL 9, хотя данные ветки и подвержены уязвимости (для атаки требуется создание иного эксплоита).

    Емайл автора патча внедрившего "ошибку":
    Email: <siddhesh AT redhat DOT com> or <siddhesh @ sourceware DOT org>

     
     
  • 2.80, Вы забыли заполнить поле Name (?), 11:52, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Засланый казачок
     

  • 1.47, Анонин (?), 09:19, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Ахаха, ой не могу! Это уже которая по счету за этот месяц?
    Просто какой-то месяц унижения сишников.

    Хотя тут даже еще веселее.
    С буфером то все понятно - ну вышли как обычно, ну рут получили. Классика.

    А вот с самописным парсером параметров вообще жесть.
    Это насколько убогая должна быть std либа языка, чтобы не уметь в split.
    И каждый сплит нужно было бы писать свой велосипед, каждый со своими багами разумеется.

     
     
  • 2.48, ыы (?), 09:23, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Все они умеют.. вот как бы вы внедряли бэкдур так чтобы его не заметили?
     
  • 2.50, ыы (?), 09:25, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тоесть с апреля 2021 по октябрь 2023 все радетели за "обновляемся скорее свежий ядро завезли недорого без смс" - получили бэкдур... Возможно что и кто надо получил...
     
     
  • 3.57, фнон (?), 09:44, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    ты конечно был бы прав, если бы не такие от "подарки"
    Например CVE-2021-22555 (https://www.opennet.dev/opennews/art.shtml?num=55488)
    уязвимости было больше 15 лет (Карл! еще бы годик и у нее наступил возраст согласия! хотя линуксоидов она и так поимела)

    или Dirty COW (https://www.opennet.dev/opennews/art.shtml?num=45354) у которой есть даже своя страничка в википедии - жила с 2007 (ядро 2.6.22) до 2016, а потом ее закрыли ....
    а не, не закрыли тк не учли все вектора атаки
    https://www.opennet.dev/opennews/art.shtml?num=47672

    В общем есть два стула:
    на одном старые CVEшки, которые уже выбирают в какой университет поступать, с рабочими эксплойтами
    а на другом: новые свежие, тк писаки в ядро за 30 лет так и не смогли научиться "не выходить за пределы буфера"

     
     
  • 4.60, Аноним (60), 09:57, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > уязвимости было больше 15 лет (Карл! еще бы годик и у нее наступил возраст согласия! хотя линуксоидов она и так поимела)

    Тем временем:
    Made public today was CVE-2023-43785 as an out-of-bounds memory access within the libX11 code that has been around since 1996. A second libX11 flaw is stack exhaustion from infinite recursion within the PutSubImage() function of libX11... This vulnerability has been around since X11R2 in February of 1988.
    Обнаруженная только сейчас уязвимость, которая так то еще живой СССР видела, молодая, всего 35 лет...

     
     
  • 5.65, Анонин (?), 10:08, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ого, впечатляет!
    С другой стороны х11 это особый кусок... кода... Создатели которого сказали never more))
     
  • 5.122, Аноним (120), 22:40, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Дарю для комплекта CVE-2021-3999. Она старше Windows 95.
     
  • 4.63, Пряник (?), 10:06, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нахождения старых уязвимостей - это хорошо. Но вот повторное наступление на грабли в 2021? Ни в какие ворота.
     
  • 2.54, Анонин (?), 09:35, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, ну я конечно понимаю, что намного приятнее думать что это бекдор, а не обычный быдлокод...
    Но даже если это бекдор, не лучше ли было бы, если бы его было бы существенно сложнее добавлять, а не просто запутаться в ручном подсчете размера буфера?
     
     
  • 3.55, ыы (?), 09:39, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "
    - мужики, а спорим я бэкдур внедрю и мне за это ниче не будет?
    - Как?
    - сделаю вид что опечатался...при подсчетах буфера
    - ну давай... на банку пива
    "
     
     
  • 4.66, fuji (?), 10:27, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    "Таак, тут какая-то фигня. Надо правильно считать размеры буфера.
    Сделаю-ка я это на отшибись, авось будет работать правильно.
    Все равно я коммичу в какое-то ядро линукса, денег мне за это не платят. Пусть тысячи глаз перепроверят.

    А если будет ошибка.. То коллеги подумают, что это был бекдор.
    А раз бекдор - значит у меня есть крыша (АНБ, ФСБ, китайцы).
    А раз есть крыша - значит все будут молчать в тряпочку."

     

  • 1.71, Шарп (ok), 10:52, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Закономерный итог. Сам язык си и практики, сложившиеся вокруг него, подталкивают к написанию своих велосипедов. Не могут осилить общие библиотеки по работе со строками. Каждый программист переизобретает заново свою версию, вместо использования общей хорошо протестированной реализации.

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

     
     
  • 2.73, Аноним (72), 11:02, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    я бы еще добавил "стандартная библиотека" мало того что написана ногами, так еще и бедная как церковная мышь
    приходится писать свои варианты, они разного качества (если можно так называть), они не совместимы и тд
     
     
  • 3.97, Neon (??), 14:55, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Стандартные библиотеки С и С++ еще и написаны больным на голову. Более уродского и неудобного нужно поискать. Логика там рептилоидов, а не людей. Да еще и дико убогие
     
  • 2.75, Анонимусс (?), 11:09, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Фиг с ней с библиотекой.
    Это что, единственное место в ядре где сплит нужно делать?
    Почему нет каких-то utils или common, в которые будут складываться стандартные методы/алгоритмы, которые нужны повсеместно?
     
  • 2.79, Аноним (79), 11:46, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Жалко только Торвальдс не поменял своего мнения о C++, который мог бы ему значительно помочь в разработке ядра.
     
     
  • 3.83, фнон (?), 13:49, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    и чем плюсы лучше?
    посмотри сколько cve'шек на плюсах и главное каких
    а там то же самое, memory corruption, out-of-bounds и тд

    есть примеры гугла, мелкософта - которые пишут сколько проблем у них от с++
    старый пост про андроид https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.ht
    но проблемы показывает

     
     
  • 4.93, Шарп (ok), 14:47, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а там то же самое, memory corruption, out-of-bounds и тд

    Только если писать в сишном стиле. Современный c++ (11+) обладает множеством средств, чтобы отлавливать ошибки.

     
     
  • 5.98, фнон (?), 15:41, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Верю!
    Но посмотри когда в ядре отказались от с99? (напомню это был 2022)

    Просто представь, что c++11 попал в ядро только в 5.18, а до этого был бы C++98 или даже C++03. Сильно это бы помогло?
    А сколько дидов ныло бы от того что они не понимают с++?

    Так C11/C17 тоже существуют, вот толку если ядро пишется на некрофильской версии стандарта.

    Тут реалистичен только подход есть слона по кусочку, переписывая отдельные куски.
    Но зачем тянуть с++ если (раз уже переписываем) можно взять Раст - все равно придется переучиваться.

     
     
  • 6.101, Аноним (21), 16:17, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В 2022 отказались от C89. C99 в ядре никогда не было.
     
     
  • 7.104, фнон (?), 16:33, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    сорян, опечатался
    да, речь про C89
    оно еще довольно долго обсуждалось тут lore.kernel.org/lkml/20220224062022.GH3943@kadam/T/
     
  • 6.123, Вы забыли заполнить поле Name (?), 23:31, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Так C11/C17 тоже существуют, вот толку если ядро пишется на некрофильской версии
    > стандарта.
    > можно взять Раст -
    > все равно придется переучиваться.

    У раста новая версия как часто выходит? Стоит ли такое тянуть, если проблемы с переходом на новый стандарт С, который выходит раз в 10 лет.

     
     
  • 7.126, Анонн (?), 09:41, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У раста кроме версий, которые выходят раз в 6 недель и являются просто процессом развития языка, еще есть editions. Вот они больше соответствуют версиям С/С++.

    Выходят раз в 3 года - уже есть 2015, 2018, 2021. И переход с 2015 даже на 2021 не такой уж болезненный.
    Более того, ты можешь совмещать разные editions в одном проекте, т.к. он фиксируется для каждого crate в отдельности.

    Тебе не нужно сразу бросаться обновлять всё до новой edition, если вдруг ты хочешь в каком-то новом модуле использовать последние фичи языка. Вообще ничего можно не делать, разве что явно прописать старый edition в toml файлах, если не сделал раньше (хотя лучше сразу фиксировать актуальный).

    Вот дока если интересно: https://doc.rust-lang.org/edition-guide/editions/index.html

     
     
  • 8.139, Вы забыли заполнить поле Name (?), 19:31, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Какая-то подмена понятий У современного С выходят новые версии стандарта, кот... текст свёрнут, показать
     
     
  • 9.140, Анонн (?), 20:15, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, это не подмена понятий У плюсов стандарты тоже выходят примерно раз в 3 го... текст свёрнут, показать
     
     
  • 10.141, Вы забыли заполнить поле Name (?), 20:18, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ядро по факту монорепозиторий Во всех номральных монорепозиториях жесткая привя... текст свёрнут, показать
     
     
  • 11.142, Анонн (?), 20:30, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе не нужно по компилятору на каждый edition Это ж тебе не сишка Ты можешь ... текст свёрнут, показать
     
     
  • 12.144, Вы забыли заполнить поле Name (?), 00:49, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нормальным компилятором С можно собрать код любого стандарта, даже древнейшего... текст свёрнут, показать
     
     
  • 13.151, Анонн (?), 17:58, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но ты не можешь часть сорцов ядра собрать одним стандартом, а часть - другим А ... текст свёрнут, показать
     
     
  • 14.153, Вы забыли заполнить поле Name (?), 23:25, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пока что нет ответа на главный вопрос - зачем ... текст свёрнут, показать
     
  • 7.127, Анонн (?), 09:56, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Когда-то в отдаленном будущем у editions тоже будет end of life.
    Пока что в документации нет сроков, но это и так понятно, что не разумно тянуть старые версии вечно.
    Но в таком случае нужно будет обновлять только неподдерживаемые крейты и только до последней актуальной версии, а не до последней существующей.
     
  • 3.96, vdb (?), 14:54, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В плюсах тащится совместимость с Си, стало быть, все сишные грабли по-прежнему доступны, плюс разложено много новых.
     
     
  • 4.99, фнон (?), 15:43, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так в названии ++ что зря поставили?
    "С++ это С + старые ошибки + новые ошибки" ))
     
  • 2.82, Аноним (82), 13:43, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Не могут осилить общие библиотеки по работе со строками. Каждый программист переизобретает заново свою версию, вместо использования общей хорошо протестированной реализации.

    А теперь предлагается вместо хорошо оттестированной реализации библиотек тащить в ядро безопасТный cargo-мусор?

     
     
  • 3.87, фнон (?), 13:58, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хахаха, "хорошо оттестированной реализации", прекрати человек-петроссян!

    Посмотри сколько сишного вна нашлось только за последний месяц!
    Glibc, libvpx, libwebp, целая пачка в последнем хотфиксе ядра.

    Посмотри сколько лет живут дырени в этих самых "проверенных и хорошо оттестированных" либах
    Dirty COW, CVE-2021-22555 - это десятки лет.

    Посмотри какой импакт имеют эти проблемы: heartbleed, куча получений рутов на миллионах девайсов.

     
     
  • 4.147, uis (??), 12:44, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Матчасть учи, Dirty COW не вв либе был.
     
  • 3.132, Аноним (132), 15:53, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Кто тебе мешает из карго-мусора отобрать нужные тебе в проекте оттестированные к... большой текст свёрнут, показать
     
  • 2.106, DildoZilla (?), 17:43, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Надеюсь, речь не о Расте, который изменяемые в будущем объекты пытается отловить до их появления, т.е. на этапе компиляции?
     
     
  • 3.109, Анонин (?), 18:06, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не, речь именно о нем.
    А что вам таки не нравится?
     

     ....большая нить свёрнута, показать (27)

  • 1.74, Аноним (77), 11:07, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И где все эти кексперты по экономии места посредством отказа от статического связывания? Поливают результатом своей мозговой деятельности язык реализации, не понимая причины?

    Капча: 78888 ;)

     
  • 1.84, ИмяХ (?), 13:50, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Почитал диффы... Ошибка настолько тупейшая, что её никак нельзя назвать ошибкой. Таких тупых вообще не допускают коммитить в ядро. Явно намеренно внедренный бекдор, который просуществовал два с половиной года, несмотря на тысячи глаз. А ещё говорят, мол, линукс безопаснее виндовса. Да этих линyкcoидов откровенно взламывают без всяких вирусов, а они всёпродолжают верить в его "безопасность."
     
     
  • 2.90, Аноним (72), 14:06, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > её никак нельзя назвать ошибкой

    Ты что обвиняешь святое Сообщество в саботаже?
    Оно же непогрешимо и все остальные не имеют право его критиковать (а от набигут всякие неадекваты)))

    Интересно кто апрувнут такой pull?

     

  • 1.92, Аноним (92), 14:30, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну что ты будешь делать? Опять каких-то анскильных лалок вместо Настоящих Программистов код писать пустили...
     
  • 1.95, Вы забыли заполнить поле Name (?), 14:52, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У сишников хотя бы есть софт, в котором можно делать уязвимости...
     
     
  • 2.133, Аноним (132), 16:03, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    у растовиков тоже есть - уже немало кода в последних версиях андроида (на декабрь 2022-го 21% всего нового нативного кода, т.е. С/С++/Rust), но вот беда - за несколько лет внесения туда расто-кода в компонентах на нем не было совершено НИ ОДНОЙ ошибки работы с памятью. Так что поправлю, перефразирую - "У сишников хотя бы есть язык, в котором при работе с памятью можно делать уязвимости..." - гордись, у растовиков с этим труднее.
     
     
  • 3.134, Вы забыли заполнить поле Name (?), 16:48, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >уже немало кода в последних версиях андроида (на декабрь 2022-го 21% всего нового нативного кода, т.е. С/С++/Rust)

    Это наглая манипуляция статистикой: "немало" и 21% на С/С++. Сколько из этого кода раста в процентах?

    > НИ ОДНОЙ ошибки работы с памятью

    Сидят 2 ковбоя в салуне. Один другого спрашвивает:

    - Слушай, а кто это там на лошади гарцует?
    - Это же Неуловимый Джо.
    - А его правда никто поймать не может?
    - Да кому он на*** нужен.

     

  • 1.105, Tester (??), 17:31, 04/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > уязвимость вызвана изменением, внесённым в апреле 2021 года

    а почему ни кто не думает что это было сделано специально? кто внес изменения? и зачем?

     
     
  • 2.107, Аноним (72), 17:46, 04/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А если бы ее нашли лет через 10?
    "кто и зачем" вносил изменения в CVE-2021-22555 15 лет назад?
    Или в X11 30+ лет назад заложив одну из наиболее старых CVE-2023-43785?

    Ты задаешь вопросы вида "зачем вася попал в аварию, когда превышал скорость непристегнутым по встречке? кому было выгодно чтобы вася попал в дтп?"

    Мне было бы лень искать заговор там, где одни и те же ошибки делались 5, 10, 15 и 20+ лет назад.
    Максимум сказать "это традиция такая, овнокодить"

     
     
  • 3.163, Tester (??), 16:43, 22/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А если бы ее нашли лет через 10?
    > "кто и зачем" вносил изменения в CVE-2021-22555 15 лет назад?
    > Или в X11 30+ лет назад заложив одну из наиболее старых CVE-2023-43785?
    > Ты задаешь вопросы вида "зачем вася попал в аварию, когда превышал скорость
    > непристегнутым по встречке? кому было выгодно чтобы вася попал в дтп?"
    > Мне было бы лень искать заговор там, где одни и те же
    > ошибки делались 5, 10, 15 и 20+ лет назад.
    > Максимум сказать "это традиция такая, овнокодить"

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

     

  • 1.124, Аноним (124), 02:54, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Уязвимость в Glibc ld.so

    Не очень понял почему ошибка именно в ld.so.
    ld.so задействован же при запуске только динамически линкуемых бинарников или статических тоже?

     
  • 1.125, Аноним (125), 09:25, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Уязвимость устранена в патче, добавленном 2 октября. Проследить за выпуском обновлений пакетов в дистрибутивах можно на страницах Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, Gentoo, ALT Linux.

    А как там российские "Астра", "Роса" и прочие сбер-линуксы, много лет простоят дырявыми, но с сертификатами ФСТЭК? Или таки там был аудит и ошибки изначально не было? Но, судя по тому, что у альта она таки была, скорее всего, это не ошибка, а бэкдор...

     
     
  • 2.164, Tester (??), 16:45, 22/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> Уязвимость устранена в патче, добавленном 2 октября. Проследить за выпуском обновлений пакетов в дистрибутивах можно на страницах Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, Gentoo, ALT Linux.
    > А как там российские "Астра", "Роса" и прочие сбер-линуксы, много лет простоят
    > дырявыми, но с сертификатами ФСТЭК? Или таки там был аудит и
    > ошибки изначально не было? Но, судя по тому, что у альта
    > она таки была, скорее всего, это не ошибка, а бэкдор...

    а разве аудита в RedHat небыло? Там и людей протирающих щтаны поболее будет...

     

  • 1.166, Werenter (ok), 11:48, 02/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня ничего не произошло, просто выдало --help
     

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



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

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