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

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

• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 00:18 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Вы забыли заполнить поле Name, 01:20 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноня, 02:29 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноня, 02:27 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 06:37 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 06:39 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 07:55 , 04-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 12:20 , 04-Окт-23
          • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 16:20 , 04-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 13:57 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним 80_уровня, 08:09 , 04-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 13:57 , 04-Окт-23
          • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,128557, 16:14 , 31-Янв-24
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 18:52 , 05-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 07:00 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,АнонПапка, 08:00 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Пряник, 09:50 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,фнон, 10:02 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Пряник, 10:07 , 04-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 10:53 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 16:21 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Kuromi, 17:12 , 06-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 18:27 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,uis, 12:19 , 06-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 00:19 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 08:04 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,InuYasha, 17:24 , 05-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,фнон, 09:27 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Пряник, 09:51 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Чи, 11:31 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 13:58 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 14:29 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 18:37 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,uis, 12:24 , 06-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 19:42 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонин, 21:14 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,User, 22:21 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 12:54 , 05-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,User, 19:07 , 05-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 22:28 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 12:18 , 05-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 13:05 , 05-Окт-23
          • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 13:26 , 05-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 21:13 , 08-Окт-23
          • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,User, 09:44 , 10-Окт-23
            • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 10:04 , 10-Окт-23
              • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,User, 10:14 , 10-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Kuromi, 17:21 , 06-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,крокодил мимо.., 18:53 , 08-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 00:49 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,morphe, 01:00 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 07:01 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,мяя, 18:42 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 21:52 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 00:58 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,bergentroll, 07:47 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 18:50 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 01:20 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,marten, 01:42 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,СисадминА, 07:00 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,еизвестный, 15:55 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 19:23 , 05-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,cheburnator9000, 01:36 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,ДаНуНафиг, 06:42 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 07:02 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Tron is Whistling, 01:40 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 07:04 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 11:26 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Neon, 14:51 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,eugener, 08:55 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,birdie, 03:27 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,WE, 06:21 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,mos87, 08:05 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 08:22 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 19:42 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонин, 09:31 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 05:36 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 07:39 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 08:23 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 22:34 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,inferrna, 16:13 , 12-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 06:33 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 06:50 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 08:12 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,фнон, 09:25 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 11:12 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Пряник, 09:57 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 21:26 , 08-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 07:18 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 08:13 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 09:13 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 10:42 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,An, 18:00 , 04-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 18:03 , 06-Окт-23
          • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,An, 16:36 , 08-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 09:40 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 10:43 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 10:44 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,ыы, 08:56 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Вы забыли заполнить поле Name, 11:52 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонин, 09:19 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,ыы, 09:23 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,ыы, 09:25 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,фнон, 09:44 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 09:57 , 04-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонин, 10:08 , 04-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 22:40 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Пряник, 10:06 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонин, 09:35 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,ыы, 09:39 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,fuji, 10:27 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Шарп, 10:52 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 11:02 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Neon, 14:55 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонимусс, 11:09 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 11:46 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,фнон, 13:49 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Шарп, 14:47 , 04-Окт-23
        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,фнон, 15:41 , 04-Окт-23
          • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 16:17 , 04-Окт-23
            • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,фнон, 16:33 , 04-Окт-23
          • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Вы забыли заполнить поле Name, 23:31 , 04-Окт-23
            • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонн, 09:41 , 05-Окт-23
              • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Вы забыли заполнить поле Name, 19:31 , 05-Окт-23
                • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонн, 20:15 , 05-Окт-23
                  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Вы забыли заполнить поле Name, 20:18 , 05-Окт-23
                    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонн, 20:30 , 05-Окт-23
                      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Вы забыли заполнить поле Name, 00:49 , 06-Окт-23
                        • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонн, 17:58 , 06-Окт-23
                          • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Вы забыли заполнить поле Name, 23:25 , 06-Окт-23
            • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонн, 09:56 , 05-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,vdb, 14:54 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,фнон, 15:43 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 13:43 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,фнон, 13:58 , 04-Окт-23
      • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,uis, 12:44 , 06-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 15:53 , 05-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,DildoZilla, 17:43 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Анонин, 18:06 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 11:07 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,ИмяХ, 13:50 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 14:06 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 14:30 , 04-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Вы забыли заполнить поле Name, 14:52 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 16:03 , 05-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Вы забыли заполнить поле Name, 16:48 , 05-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Tester, 17:31 , 04-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 17:46 , 04-Окт-23
    • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Tester, 16:43 , 22-Дек-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 02:54 , 05-Окт-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Аноним, 09:25 , 05-Окт-23
  • Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Tester, 16:45 , 22-Дек-23
• Уязвимость в Glibc ld.so, позволяющая получить права root в ...,Werenter, 11:48 , 02-Фев-24

сишники не осилили str.split(sep="=", maxsplit=1)

https://docs.gtk.org/glib/func.strsplit.html

glib это не glibc

Да не просто Сишники, а те самые деды! Эксперты, монстры! Отцы-основатели!

Деды ... хотя всё возможно - акселерация

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

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

Это он. Не сильно на отца-основателя похож.

https://sessionize.com/siddhesh-poyarekar#:~:text=Siddhesh&#...,performance%20for%20over%20a%20decade

>Siddhesh Poyarekar is a toolchain hacker and a Tech Lead at Linaro, managing a team of toolchain wizards.

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

все честно написано: Siddhesh Poyarekar is a toolchain hacker
хакер - вот и сломал тулчейн.

> все честно написано: Siddhesh Poyarekar is a toolchain hacker
> хакер - вот и сломал тулчейн.

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

Так он же индус!

Понаведут смуззеров в глибц...

Он не смуззер, он индус.

Индус - это диагноз. Каким выглядит мир, когда в голове одни танцы?

> Уязвимость вызвана изменением, внесённым в апреле 2021 года и вошедшим в состав выпуска glibc 2.34.

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

А ты не осилил написать glibc.

Кажется это Python, а в С такого нету ))))))) вот и неосилили

Действительно крайне нубская ошибка. Было вроде в каких-то языках или парсерах, но быстро исправляли.

а тут целое ядро и 2 года не могли заметить...
но ведь тысячи глаз!

И статические анализаторы кода. Должны были ещё при коммите заметить сразу.

А разве в ядре есть обязательный стат. анализатор?
Проверка которого была бы необходима для создания PR?

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

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

> а тут целое ядро и 2 года не могли заметить...

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

Как вариант - не заметили потому что отвернулись в сторону. Я не фанат конспирологии, но иногда слишком уж похоже.

Как часто вижу подобные комментарии. Но почему никто не написал ничего на другом языке?

strstr

Это же сколько раз они на одни и те же грабли наступили с переменными окружения в suid-программах?

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

Всё как завещали деды!

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.

AT&T - та ещё корпорация зла. Позлее гугла в свои времена.

ты понимаешь, что если сделать один раз нормально - то больше код трогать не придется
а так еще поколения шышников будут кормиться на исправлении ошибок
(вспоминается анекдот про молодого адвоката, который выиграл семейное дело на первом же заседании)

Вообще концепция suid напрягает.

Ну отказаться от этой концепции видимо уже не получится. Как вариант обмазать все эти суид бинари правилами selinux в обязательно порядке.

SELinux - лишнее звено.

Почему не отказаться? Что из этого нельзя выкинуть? А других гнилых бинарей у меня и нет.

/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

Получится, если будет политическая воля. Более 20 лет шло балабольство о невозможности отказа от GIL. Потом пришёл Micro$oft, нанял ключевых разрабов, и в течение года проблема будет решена, а несогласным придётся утереться. Если найдётся корпорация, которая смажет всё деньгами - проблема мигом будет решена. И suid уберут, и программы, которые нужно будет править, либо поправят, либо на свалку истории отправят.

Эммм... POSIX file capabilities.

Причем каждый раз когда я пишу про SUID на этом форуме всегда найдется парочка долбоящеров, которые будут оборонять эту дрянь и пищать про какой-то там UNIX way!!!

Решается эта проблема так:
1) Реализовать полноценные ACL на уровне ядра, а не тот позорный мусор, который опциональный и не работает как надо.
2) Начинайте принудительно и неотключаемо применять ACL ко всем объектам:
- файлам
- каталогам
- сокетам
- процессам
- потокам
- каналам (pipes)
3) Принудительно включить мандатный контроль, работающий поверх тех же ACL, но позволяющий создавать виртуальные объекты доверия, которые могут стать субъектом политики.
4) Вменять Targeted Policy для всего софта, который дистрибутив считает частью базовой системы пространства пользователя, а остальные 9000 пакетов из репозиториев/PPA, ставить в помойку^W /opt
5) Дать утилиты для работы с этим со всем

Вместо того, чтобы в прямом смысле слова КАЖДАЯ программа работающая с SUID могла поломать вам систему, просто украдите уже в Windows. Или сделайте лучше, только хватит защищать SUID-бэкдоры, которые раскиданы по всяким линуксам.

Причем там ведь даже и патенты все 100 лет как кончились и есть открытые описания стандартов. Microsoft даже пытался это стандартизировать... но  нет.

1) Решается через NT ACL. С натяжкой можно NFSv4 ACL, но лучше сразу взять полнофункциональный вариант
2) Это решает SDDL, который привносит понятие дескриптора безопасности и вменяет DACL и SACL
3) Сделать нужно одну обязательную систему мандатного контроля, а не 2,5 опциональных
4) И политику нужно писать на системы мандатного контроля, а не как в Debian
5) Это самое сложное, потому что нужны не только утилиты настройки, на и пересмотреть целый ряд системных утилит
Просто подумайте о том, какие права нужны утилите ping и что произойдет если не дать её работать через ядро. (вы не увидите ни latency ни jitter не посчитаете в юзерспейсе, там цифры будут на порядок отличаться от реальности)

Если кто-то спросит, скажите Аноним разрешил скоммуниздить у MS.

Прекратите верить в радужных единорогов, фей, барабашек и безопасность Unix с SUID-битами и выключенным мандатным контролем при полном отсутствии ACL, вместо которых в ОС модель прав из 70-х. Я в реальной жизни встречал баранов, которые выключили SELinux, понаставили "chmod 777" и пренебрежительно рассказывают мне о высочайшей безопасности Linux  и про то что Windows на железо им страшно ставить.

P.S. И вот только не надо рассказывать мне сказки про безопасность Windows. У нее все проблемы исторически из-за того что почти все пользователи сидят из-под админских учеток и качают из интернета бекдоры, не понимая что они запускают. Если вы дадите любую Ubuntu на такую же целевую аудиторию с ней будет  еще хуже.

Просто интересно, а если ли хоть какая-то система где все перечисленное реализовано, причем правильно, или хотя бы близко к нему?

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

Осталось ответить на вопрос "ну и вот нахрена это ХОТЬ КОМУ-НИБУДЬ чтоб это самому делать или хотя бы денег за это заплатить"? И можно в путь.

Вопросы по всем перечисленным пунктам многократно поднимались в списках рассылки ядра, были неоднократные попытки реализовать и Rich ACLs и дескрипторы. Практика показывает, что это не вопрос денег, это вопрос принятия патчей.
- Бешенные бараны упираются рогами в землю и не хотят ни применять патчи, ни пользоваться этим, потому что это "как в Windows". Если они узнали бы что разработчики Windows едят еду и пьёт воду, они бы объявили сухую голодовку и сдохли бы в знак протеста.
- Тупые овцы не понимают, зачем вообще всё это нужно, потому что не видели задач вне локалкоста. Они прекрасно живут и так, и УМВР и "ви врёти всё".
- Религиозные ослы верят в единорогов, гномов и в контейнерную изоляцию, через докер от рута, которая что-то от чего-то защищает через пространства имён.
Проблема прежде всего в компетенции...

>[оверквотинг удален]
> - Бешенные бараны упираются рогами в землю и не хотят ни применять
> патчи, ни пользоваться этим, потому что это "как в Windows". Если
> они узнали бы что разработчики Windows едят еду и пьёт воду,
> они бы объявили сухую голодовку и сдохли бы в знак протеста.
> - Тупые овцы не понимают, зачем вообще всё это нужно, потому что
> не видели задач вне локалкоста. Они прекрасно живут и так, и
> УМВР и "ви врёти всё".
> - Религиозные ослы верят в единорогов, гномов и в контейнерную изоляцию, через
> докер от рута, которая что-то от чего-то защищает через пространства имён.
> Проблема прежде всего в компетенции...

Ну, в общем я и говорю - примерно всем пох. Или "не пох" в степени недостаточной чтоб хоть что-то в этом направлении сделать. ЕМНИП, NFSv4 acl слабали санки для солярки - и уже оттуда оно оно кои-8-как доползло и до linux'ов - и то не так, чтобы полностью - самбе было надо, они накостылили поверх чего умели и как могли, остальным как было пох - так и осталось.

> Решается эта проблема так:

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

Во-первых не просто Windows, а именно Windows NT.
Внутри Windows есть огромное количество невменяемого наследия DOS/Windows9x даже в современных версиях, которое мешает ей жить и создаёт тонну дырок в безопасности. Понимаете ли в чем дело... Всё что я писал в своем предыдущем длинном посте не распространяется на legacy-компоненты, и это страшная дыра. Просто вдумайтесь (!!!), Spooler - это legacy-компонент из Win9x. Еще раз прочитайте медленно и ужаснитесь: "Вся подсистема печати Windows - наследие DOS/Windows 9x". И она дырявая, потому что предпечатный рендеринг шрифтов GDI-принтера делается модулем ядра GDI (тот самый win32k.sys с его синими экранами), а пользователи могут при подключении к сетевому принтеру по SMB загрузить и установить драйвер (драйвер, Карл!) с внешнего компьютера в обход проверок от лица пользователя с пониженными привилегиями. А я напоминаю, что всякий RICOH и Kyocera не стесняются в кастомизации рендеринга шрифтов и ставят WDM-драйвер уровня ядра, который подменяет стандартную логику работы GDI конкретно с их железками.
А еще в Windows настолько страшный Virtual Filesystem (VFS-драйвер), что на нем стоит мораторий на любые изменения в коде. Оно еле-еле работает, потому что с одной стороны оно предполагает, что всё должно быть в UCS-2 (даже не в UTF-16), но при этом должна быть обратная совместимость с 8.3 именованием каталогов и файлов и не только в формате ANSI CP-****, а именно в тех самых IBM-кодировка типа CP866 или CP478. VFS Windows работает настолько плохо, что в общем случае для рекурсивного удаления каталога даже через современный PowerShell требуется целый скрипт учитывающий все legacy-штуки, особенно оформленные ReparsePoint-объекты и очень сбоку прикрученные туда ACE/ACL, потому что изначально-то в DOS всего этого не было. И я еще не начал про SMB1, NetBIOS и прочее наследие IBM, которое застряло в Windows NT ради обратной совместимости, не только с Win9x, но и с OS/2. И это лишь пара примеров...
Короче, вам это всё не надо. Вдумайтесь, Microsoft десятилетиями медленно пытается херить эти подсистемы, но там реализация всей этой архитектуры мягко говоря слабоватая. Legacy Windows - это рак, она больна и её десятилетиями лечат вырезая метастазы:
- Разделить службы (демоны) от пользовательских процессов (Windows Vista)
- Администратор больше не равен по правам Системе. LOCAL SYSTEM = root в Windows. (Windows Vista)
- Понизить в правах планировщик задач и сами задачи сделать подконтрольнее (Windows Vista)
- Добавить возможность запускать процессы пользователя с пониженными привилегиями относительно прав самого пользователя (Windows 8)
- Научить подсистему безопасности тому, что служба может быть запущена с привилегиями ниже пользовательских и не иметь возможности ни работать вне пользовательской сессии, ни к другим пользователям не лезть (Windows 10)
Сейчас их безопасники на конференциях в очередной раз поднимают вопросы:
1) Как отобрать у всех админов, чтобы пользователи могли работать без страданий, но при этом в ограниченных сессиях.
2) Пересмотреть реализацию Capabilities в ядре так, чтобы пользователь мог контролировать к каким устройствам запущенное им приложение имеет доступ, а к каким он запретил
3) Как сделать так, чтобы это было не сильно заоверинженирнуто и разработчики этим пользовались, а не пытались обойти.
Поймите, там проблем столько, что иногда проще переписать с нуля. Они же так уже делали, когда переходили на WinNT.

Во-вторых Windows NT это не 100% оригинальная разработка, а вольная интерпретация архитектуры VMS для x86-чипов. И вот поверх этого всего в сочетании с Win32 народилось много всего.
Просто людям (я живьем таких встречал) почему-то кажется, будто есть только UNIX и ему подобные ОС, а Windows она такая единственная протестная, которая из принципа не следует стандартам POSIX и не любит "UNIX way". На самом же деле она написана архитекторами VMS и продолжает развитие другой линейки ОС.
Ну возьмите лучшие практики оттуда и примените себе... Microsoft же всегда так делал. Сетевой стек у них сначала писала IBM, потом Cisco, потом они его у BSD взяли, параллельно доробатывая свой NDIS и WFP. Протокол RDP они лицензировали у Citrix, а Hyper-V это порт Xen на Windows причем опять самими же авторами. Не вижу никакой проблемы.

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

Windows очень старый трехколесный велосипед с отваливающимся рулём, но третье колесо вроде бы не нужно, но без него никуда не едет, поэтому мы приделаем еще 1 колесо, для плавности, главное чтобы сидеть было комфортно.
При этом Linux, это велосипед без руля с квадратными колесами и дилдаком вместо седушки, чтобы при каждом прокручивании педалей пользователь получал специфическое удовольствие. А если ему нужно повернуть, то нужно соскочить, переставить велосипед и только потом ехать в другом направлении (это я про маразм вокруг конфигурирование SELinux и ему подобных решений).
На минуточку, SELinux и его контексты это именно то, что реализуется вместо дескрипторов SDDL. А еще он имеет свою собственную эксклюзивную для него реализацию ACE/ACL на уровне ядра. Но всё это бесполезно, потому что по всей ОС раскиданы SUID-утилиты (модель прав из 70-х годов), которые всё это обходят. Что возвращает нас обратно к теме новости.

Ну не хотите как в Windows, ну не надо, но сделайте лучше и закопайте чертов SUID, иначе это никогда не кончится. Это тот самый пример уязвимости by design.

Suid не обходит selinux.

Он не обходит его на этапе работы с контекстом вызываемой утилиты, в том и только в том случае если есть специально оформленное правило в рамках Targeted Policy. Политика мандатного контроля по умолчанию всегда является таргетированной, она не распространяется на ВСЁ, за исключением единичных случаев, когда в рамках корпоративного использования её вменяют на шаблонизированные рабочие станции и сервера.

Он обходит его на этапе запуска. SELinux позволяет существовать возможности неподконтрольного ему поднятия привилегий даже в объявленном и подконтрольном ему контексте.

Ну то есть у вас дыра в заборе и двери в доме нарастапашку. Грабители вынесли абсолютно всё из дома, но в сарай не попали, сарай закрыт на ключ. Как-то так...

Вот есть отличное видео о том как сейчас работает SELinux: https://www.youtube.com/watch?v=fB2b-lTjCQA

> из принципа не следует стандартам POSIX

Жопslashes, case-нетерпимость, буквы устройств, ФС без DAC и стойкое желание всё это насадить всем другим, POSIX-совместимым ОС, а хоть бы и через железных вендоров (см. UEFI), -- не дадут соврать. Из принципа. Чтобы всё, что напишут "Developers, Developers", работало только в Пинде и нигде больше - без переписывания.

> по всей ОС раскиданы SUID-утилиты

systemd монтирует все разделы (включая автоматические) с nosuid, кроме явно определенных админом в /etc/fstab. См. выхлоп findmnt.
Выносим /usr/{bin,lib} в отдельный раздел (или subvolume на Btrfs). Всё остальное монтируем с nosuid. И всё работает. Ничего не сломалось - невероятно!

А в /usr/ файлы попадают только из пакетного менеджера, не минуя пары глаз сопроводителя.

Утилиты, использующие SUID, в современных системах можно по пальцам двух рук пересчитать. Большинство не нужно пользователю в повседневной работе на предварительно настроенной системе.
Для всего остального (обычно пускаемого из-под root) давно используют man 7 capabilities.

Находим все SUID-файлы: `# find /usr -type f -perm /u=s,g=s -printf '%M\t%H/%P\n' 2>/dev/null`
Блокируем их вызов в программах через AppaArmor/SELinux: "audit deny rwklmx /usr/bin/sudo,"

Или запускаем программы изолированно через bwrap/flatpak, где получаем "no new privs" при попытке вызвать SUID-программу.

Linux capabilities также явно разрешаются через MAC и user namespaces.

>> из принципа не следует стандартам POSIX
> Жопslashes, case-нетерпимость, буквы устройств, ФС без DAC и стойкое желание всё это
> насадить всем другим, POSIX-совместимым ОС, а хоть бы и через железных
> вендоров (см. UEFI), -- не дадут соврать. Из принципа. Чтобы всё,
> что напишут "Developers, Developers", работало только в Пинде и нигде больше
> - без переписывания.

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

Одна только унификация - на вес золота. Много хорошего, за неимением лучшего.

> Одна только унификация - на вес золота. Много хорошего, за неимением лучшего.

Ну вот кушайте posix acl, не обляпайтесь. Ой, а он !внезапно! не часть POSIX. "У" - унификация! "Г"... каквсигда.

"Я в реальной жизни встречал баранов, которые выключили SELinux, понаставили "chmod 777" и пренебрежительно рассказывают мне о высочайшей безопасности Linux  и про то что Windows на железо им страшно ставить. "

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

> Решается эта проблема так:

кмк, необходимо и достаточно внимательно аудировать код утилит, требующих 4000..
например, в базе OpenBSD имеем (с инодами в первом столбце):

2125487 -r-sr-xr-x 2 root bin /sbin/ping*
2125487 -r-sr-xr-x 2 root bin /sbin/ping6*
1762855 -r-sr-xr-x 3 root bin /usr/bin/chfn*
1762855 -r-sr-xr-x 3 root bin /usr/bin/chpass*
1762855 -r-sr-xr-x 3 root bin /usr/bin/chsh*
1762610 -r-sr-xr-x 1 root bin /usr/bin/doas*
1762699 -r-sr-xr-x 1 root bin /usr/bin/passwd*
1762769 -r-sr-xr-x 1 root bin /usr/bin/su*
1814401 -r-sr-xr-x 1 root auth /usr/libexec/auth/login_chpass*
1814402 -r-sr-xr-x 1 root auth /usr/libexec/auth/login_lchpass*
1814404 -r-sr-xr-x 1 root auth /usr/libexec/auth/login_passwd*
1814433 -r-sr-xr-x 1 root bin /usr/libexec/lockspool*
1814455 -r-sr-xr-x 1 root bin /usr/libexec/ssh-keysign*
1840372 -r-sr-xr-x 2 root bin /usr/sbin/traceroute*
1840372 -r-sr-xr-x 2 root bin /usr/sbin/traceroute6*

итого 11 программ, acl не реализован (за ненадобностью.. хех..), пользуем bsdgroups (то самое, лохматое, конца 70-ых)..

ещё один пример - утилита doas, которая появилась "от безысходности", если можно так сказать :))..
другими словами, можно вспомнить профессора Преображенского, объясняющего Борменталю, что порядок должен быть прежде всего в голове..

Васян решил добавить самописный парсер строк.

Зато без всяких cargo!

И чего там в карго нету глибс на безопасТном?

Но Раст базируется на libc.

> Но Раст базируется на libc.

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

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

И почему я не удивлён. А разве переменные окружения не должны очищаться при запуске суидных бинарей как раз на такой случай?

Очевидно нет, если переменная предполагается для чтения.

А есть какие-то иные переменные окружения?

Debian 11 тоже подвержен уязвимости из-за того, что патч из glibc-2.34 был бэкпоритрован в glibc-2.31-12.
https://security-tracker.debian.org/tracker/CVE-2023-4911
Заплатка для Debian 11 уже выпущена

Ubuntu 22.04 - тоже была уязвима, апдейт выпущен

Пушто всякие дебунты это недодистрибутивы, багованые школоподелки. В мире осталось только два нормальных дистрибутива, это Альт и RHEL.

Alt очень хорош. Ядро без нареканий собирают. Завидую. У меня норм только 4.19 получается.(

Slackware отличный.

Как же вы надоели. Не "уязвимость", а заранее заготовленный "бекдор" для спецслужб США.

Срочно переписать на русифицированном Си!
https://opennet.ru/58745-vm

Не рушь мир фанатиков безопастного.

Такого класса дыры нельзя публиковать до устранения.

Всё импортозамещение уже взломано.

Зачем "партнёры" будут ломать своих агентов, внедрившиз бэкдур в госструктуры?

Американские сервера тоже)))

Я вчера обнову на дебиан 12 поставил около 10-ти вечера, а новость опубликована в 22:30. Норм.

Сказать, что я в бешенстве - ничего не сказать.

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

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 утра, потом опсос снимает деньги все со счёта по ошибке, я чуть не остался на работе из-за этого.

Зачем пользователям федоры секюр апдейты? подождал неделю и новый релиз.

make a sign

Геройствования работы до 4 утра, мало того что это покрытие чьего-то про.кола, это напрочь сбитый лайф баланс. Здоровье не купишь не надо так.

> это напрочь сбитый лайф баланс

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

> я в бешенстве

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

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

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

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

Да низкий уровень образования создаёт причудливые логические связи.

Дружище, если что-то писать на делфи, то с высокой степенью вероятности в коде будут глюки вида "объект на форму кинули, но все нужные методы для него создать забыли". Если питонятина, то можно ждать что штука которая запускалась пару версий назад не запустится на текущей. Если сишка - жди проблем с памятью.

>питонятина
>запускалась пару версий назад не запустится на текущей

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

>CVE-2023-4527

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

Весь, ВЕСЬ код в 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.

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

Так ты это молодой, давай переписывай. Критиковать каждый умеет.

а что лучше критиковать или писать вот такой код?

В твой случае лучше молчать

Одно другому не мешает :)

> деды дали в рейтузы

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

Да что ж это такое, а... Этому безобразию настанет когда-нибудь конец или нет???

На Эльбрусах не срабатывает.

А эти Эльбрусы сейчас с тобой в одной комнате, покажи где ты их трогал?

и на столе есть и МЦСТ даёт доступ по ssh, погуглите

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

Зачем? Ты не нужен, сиди и жди халяву дальше.

Ну ок. Тогда смотрим на альтернативы: x86_64, ARM, RISC-V.
А вы и дальше сидите в бункере со своей "прелестью".

А какая версия Glibc там? Небось, ещё 2.2x какая-то.

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

@yukari:~$ lcc -v
lcc:1.26.20:Jun--6-2023:e2k-v4-linux
Thread model: posix
gcc version 9.3.0 compatible.

>Предложенный метод эксплуатации также не работает в RHEL 8 и RHEL 9, хотя данные ветки и подвержены уязвимости (для атаки требуется создание иного эксплоита).

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

Засланый казачок

Ахаха, ой не могу! Это уже которая по счету за этот месяц?
Просто какой-то месяц унижения сишников.

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

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

Все они умеют.. вот как бы вы внедряли бэкдур так чтобы его не заметили?

Тоесть с апреля 2021 по октябрь 2023 все радетели за "обновляемся скорее свежий ядро завезли недорого без смс" - получили бэкдур... Возможно что и кто надо получил...

ты конечно был бы прав, если бы не такие от "подарки"
Например CVE-2021-22555 (https://www.opennet.me/opennews/art.shtml?num=55488)
уязвимости было больше 15 лет (Карл! еще бы годик и у нее наступил возраст согласия! хотя линуксоидов она и так поимела)

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

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

> уязвимости было больше 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 лет...

Ого, впечатляет!
С другой стороны х11 это особый кусок... кода... Создатели которого сказали never more))

Дарю для комплекта CVE-2021-3999. Она старше Windows 95.

Нахождения старых уязвимостей - это хорошо. Но вот повторное наступление на грабли в 2021? Ни в какие ворота.

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

"
- мужики, а спорим я бэкдур внедрю и мне за это ниче не будет?
- Как?
- сделаю вид что опечатался...при подсчетах буфера
- ну давай... на банку пива
"

"Таак, тут какая-то фигня. Надо правильно считать размеры буфера.
Сделаю-ка я это на отшибись, авось будет работать правильно.
Все равно я коммичу в какое-то ядро линукса, денег мне за это не платят. Пусть тысячи глаз перепроверят.

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

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

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

я бы еще добавил "стандартная библиотека" мало того что написана ногами, так еще и бедная как церковная мышь
приходится писать свои варианты, они разного качества (если можно так называть), они не совместимы и тд

Стандартные библиотеки С и С++ еще и написаны больным на голову. Более уродского и неудобного нужно поискать. Логика там рептилоидов, а не людей. Да еще и дико убогие

Фиг с ней с библиотекой.
Это что, единственное место в ядре где сплит нужно делать?
Почему нет каких-то utils или common, в которые будут складываться стандартные методы/алгоритмы, которые нужны повсеместно?

Жалко только Торвальдс не поменял своего мнения о C++, который мог бы ему значительно помочь в разработке ядра.

и чем плюсы лучше?
посмотри сколько cve'шек на плюсах и главное каких
а там то же самое, memory corruption, out-of-bounds и тд

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

> а там то же самое, memory corruption, out-of-bounds и тд

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

Верю!
Но посмотри когда в ядре отказались от с99? (напомню это был 2022)

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

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

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

В 2022 отказались от C89. C99 в ядре никогда не было.

сорян, опечатался
да, речь про C89
оно еще довольно долго обсуждалось тут lore.kernel.org/lkml/20220224062022.GH3943@kadam/T/

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

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

У раста кроме версий, которые выходят раз в 6 недель и являются просто процессом развития языка, еще есть editions. Вот они больше соответствуют версиям С/С++.

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

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

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

> которые выходят раз в 6 недель и являются просто процессом развития языка, еще есть editions. Вот они больше соответствуют версиям С/С++

Какая-то подмена понятий. У современного С++ выходят новые версии стандарта, которые отвечают за эволюционное развитие. У раста раз в 6 недель такое же развитие, добавление новых фич и т.п.

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

Да, давай в каждом модуле будем использовать разные версии. Отличная идея Уолтер, просто офигительная, надежная как швейцарские часы (с)

Нет, это не подмена понятий.

> У современного С++ выходят новые версии стандарта

У плюсов стандарты тоже выходят примерно раз в 3 года. Только потом еще нужно пару лет подождать, пока все фичи стандарта поддержат в компиляторах. Напомню, что модули добавили в С++20... а когда их реально сделали?
Чтобы такая аналогия была хоть как-то близкой к реальности - нужно еще сидеть на бета версиях... или даже на альфах компилятора.

А тут ты фиксируешь предыдущий edition и тебе ничего добавляться не будет. Только фиксы, если будут.

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

А в чем проблема? Крейты атомарны.
Давайте тогда сидеть на древней версии, потому что объективно не состоянии одновременно перевести N-миллионов строк кода на новый стандарт. И обновляться раз в 10-20 лет. Этот план лучше?

С растом ничто не мешает идти по пути нынешнего си в линуксе: фиксируем edition, пишем на нем пока она не устареет совершенно, потом перепрыгиваем через два-три, исправляем пару сотен тысяч deprecations и изменений синтаксиса, и опять заморозить edition на N-лет.
Путь проверен и понятно что он отстой.

Но с растом есть еще другой путь, который описал выше.
Будет ли он лучше... а пока не попробуешь - не узнаешь.
Но в обычном софте вполне уживаются крейты разных edition.

> Но с растом есть еще другой путь, который описал выше.
> Будет ли он лучше... а пока не попробуешь - не узнаешь.
> Но в обычном софте вполне уживаются крейты разных edition.

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

Тебе не нужно по компилятору на каждый edition. Это ж тебе не сишка.
Ты можешь зафиксировать версию компилятора, напр. 1.70.
И им компилить все editionы - и 2015, и 2018, и 2021.

"All Rust compiler versions support any edition that existed prior to that compiler’s release, and they can link crates of any supported editions together. Edition changes only affect the way the compiler initially parses code. Therefore, if you’re using Rust 2015 and one of your dependencies uses Rust 2018, your project will compile and be able to use that dependency."
https://doc.rust-lang.org/book/appendix-05-editions.html

Понимаю, что звучит слишком круто и вызывает недоверие :)

> Понимаю, что звучит слишком круто и вызывает недоверие :)

Нормальным компилятором С++ можно собрать код любого стандарта, даже древнейшего. В монорепоизториях фисируется именно версия стандарта того же С++. Почитай гайды разработки того же chromium.

Но ты не можешь часть сорцов ядра собрать одним стандартом, а часть - другим.
А тут можно.

> Но ты не можешь часть сорцов ядра собрать одним стандартом, а часть
> - другим.
> А тут можно.

Пока что нет ответа на главный вопрос - зачем?

Когда-то в отдаленном будущем у editions тоже будет end of life.
Пока что в документации нет сроков, но это и так понятно, что не разумно тянуть старые версии вечно.
Но в таком случае нужно будет обновлять только неподдерживаемые крейты и только до последней актуальной версии, а не до последней существующей.

В плюсах тащится совместимость с Си, стало быть, все сишные грабли по-прежнему доступны, плюс разложено много новых.

Ну так в названии ++ что зря поставили?
"С++ это С + старые ошибки + новые ошибки" ))

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

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

Хахаха, "хорошо оттестированной реализации", прекрати человек-петроссян!

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

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

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

Матчасть учи, Dirty COW не вв либе был.

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

Кто тебе мешает из карго-мусора отобрать нужные тебе в проекте оттестированные крейты, самому их проверить и оттестировать (ведь исходники СИшных  "хорошо оттестированных" библиотек ты сам лично вычитал и оттестировал, верно? Раз уверен в них?), положить эти крейты в своё локальное хранилище и в проекте натравливать карго на использование локального, протестированного тобой, хранилища? По мере выхода новых версий крейтов или при возникновении необходимости притащить из внешней карго-мусорки что-то новое - повторяешь вышеописанные действия, т.е. перегоняешь проверенное в локальную мусорку. Для сишных "хорошо оттестированных реализаций библиотек" ты ведь заново проверяешь, не сломали ли они что в новых версиях свежими патчами, не всунули ли бэкдора? В чем тогда разница растовых крейтов и сишных библиотек при условии что ты, как "здоровый параноик", в проекте настроишь карго на получение крейтов с локальной проверенной мусорки?

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

Не, речь именно о нем.
А что вам таки не нравится?

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

Капча: 78888 ;)

Почитал диффы... Ошибка настолько тупейшая, что её никак нельзя назвать ошибкой. Таких тупых вообще не допускают коммитить в ядро. Явно намеренно внедренный бекдор, который просуществовал два с половиной года, несмотря на тысячи глаз. А ещё говорят, мол, линукс безопаснее виндовса. Да этих линyкcoидов откровенно взламывают без всяких вирусов, а они всёпродолжают верить в его "безопасность."

> её никак нельзя назвать ошибкой

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

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

Ну что ты будешь делать? Опять каких-то анскильных лалок вместо Настоящих Программистов код писать пустили...

У сишников хотя бы есть софт, в котором можно делать уязвимости...

у растовиков тоже есть - уже немало кода в последних версиях андроида (на декабрь 2022-го 21% всего нового нативного кода, т.е. С/С++/Rust), но вот беда - за несколько лет внесения туда расто-кода в компонентах на нем не было совершено НИ ОДНОЙ ошибки работы с памятью. Так что поправлю, перефразирую - "У сишников хотя бы есть язык, в котором при работе с памятью можно делать уязвимости..." - гордись, у растовиков с этим труднее.

>уже немало кода в последних версиях андроида (на декабрь 2022-го 21% всего нового нативного кода, т.е. С/С++/Rust)

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

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

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

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

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

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

А если бы ее нашли лет через 10?
"кто и зачем" вносил изменения в CVE-2021-22555 15 лет назад?
Или в X11 30+ лет назад заложив одну из наиболее старых CVE-2023-43785?

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

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

> А если бы ее нашли лет через 10?
> "кто и зачем" вносил изменения в CVE-2021-22555 15 лет назад?
> Или в X11 30+ лет назад заложив одну из наиболее старых CVE-2023-43785?
> Ты задаешь вопросы вида "зачем вася попал в аварию, когда превышал скорость
> непристегнутым по встречке? кому было выгодно чтобы вася попал в дтп?"
> Мне было бы лень искать заговор там, где одни и те же
> ошибки делались 5, 10, 15 и 20+ лет назад.
> Максимум сказать "это традиция такая, овнокодить"

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

> Уязвимость в Glibc ld.so

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

> Уязвимость устранена в патче, добавленном 2 октября. Проследить за выпуском обновлений пакетов в дистрибутивах можно на страницах Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, Gentoo, ALT Linux.

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

>> Уязвимость устранена в патче, добавленном 2 октября. Проследить за выпуском обновлений пакетов в дистрибутивах можно на страницах Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, Gentoo, ALT Linux.
> А как там российские "Астра", "Роса" и прочие сбер-линуксы, много лет простоят
> дырявыми, но с сертификатами ФСТЭК? Или таки там был аудит и
> ошибки изначально не было? Но, судя по тому, что у альта
> она таки была, скорее всего, это не ошибка, а бэкдор...

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

У меня ничего не произошло, просто выдало --help