Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в Glibc ld.so, позволяющая получить права root в системе"	+/–
Сообщение от opennews (??), 04-Окт-23, 00:18
Компания Qualys выявила опасную уязвимость (CVE-2023-4911) в компоновщике ld.so, поставляемом в составе системной Си-библиотеки Glibc (GNU libc). Уязвимость позволяет локальному пользователю поднять свои привилегии в системе через указание специально оформленных данных в переменной окружения GLIBC_TUNABLES перед запуском исполняемого файла с флагом suid root, например, /usr/bin/su... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59867
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 04-Окт-23, 00:18	+11 +/–
сишники не осилили str.split(sep="=", maxsplit=1)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #12, #22, #32, #58, #110, #145

3. Сообщение от Аноним (3), 04-Окт-23, 00:19	+7 +/–
Это же сколько раз они на одни и те же грабли наступили с переменными окружения в suid-программах? https://www.opennet.ru/28338 https://www.opennet.ru/28390 https://www.opennet.ru/40667 https://www.opennet.ru/46724 https://www.opennet.ru/47722 https://www.opennet.ru/52012
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34, #52, #59, #115

4. Сообщение от Аноним (4), 04-Окт-23, 00:49	+1 +/–
Васян решил добавить самописный парсер строк.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

5. Сообщение от Аноним (91), 04-Окт-23, 00:58	+/–
И почему я не удивлён. А разве переменные окружения не должны очищаться при запуске суидных бинарей как раз на такой случай?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29

6. Сообщение от morphe (?), 04-Окт-23, 01:00	+15 +/–
Зато без всяких cargo!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #24, #112

7. Сообщение от Вы забыли заполнить поле Name (?), 04-Окт-23, 01:20	–2 +/–
https://docs.gtk.org/glib/func.strsplit.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #13

8. Сообщение от Аноним (8), 04-Окт-23, 01:20	+1 +/–
Debian 11 тоже подвержен уязвимости из-за того, что патч из glibc-2.34 был бэкпоритрован в glibc-2.31-12. https://security-tracker.debian.org/tracker/CVE-2023-4911 Заплатка для Debian 11 уже выпущена
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #23

9. Сообщение от cheburnator9000 (ok), 04-Окт-23, 01:36	+4 +/–
Как же вы надоели. Не "уязвимость", а заранее заготовленный "бекдор" для спецслужб США.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #25

10. Сообщение от Tron is Whistling (?), 04-Окт-23, 01:40	+1 +/–
Такого класса дыры нельзя публиковать до устранения.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #43

11. Сообщение от marten (ok), 04-Окт-23, 01:42	+/–
Ubuntu 22.04 - тоже была уязвима, апдейт выпущен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

12. Сообщение от Аноня (?), 04-Окт-23, 02:27	–11 +/–
Да не просто Сишники, а те самые деды! Эксперты, монстры! Отцы-основатели!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #18, #19, #136

13. Сообщение от Аноня (?), 04-Окт-23, 02:29	+11 +/–
glib это не glibc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

14. Сообщение от birdie (ok), 04-Окт-23, 03:27	–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 утра, потом опсос снимает деньги все со счёта по ошибке, я чуть не остался на работе из-за этого.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #35, #40, #53

15. Сообщение от Аноним (120), 04-Окт-23, 05:36	–1 +/–
> Из-за ошибки в коде разбора строки, указанной в переменной окружения GLIBC_TUNABLES, некорректная комбинация параметров в данной переменной приводит к записи разобранного значения за пределы выделенного буфера. Как же это было предсказуемо если знаешь на каком языке библиотека написана.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

16. Сообщение от WE (?), 04-Окт-23, 06:21	+8 +/–
Зачем пользователям федоры секюр апдейты? подождал неделю и новый релиз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

17. Сообщение от Аноним (17), 04-Окт-23, 06:33	+1 +/–
>CVE-2023-4527 *trollmode* Включи IPv6 и спи спокойно.
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от Аноним (18), 04-Окт-23, 06:37	+10 +/–
Деды ... хотя всё возможно - акселерация > Уязвимость вызвана изменением, внесённым в апреле 2021 года А вам лишь бы ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

19. Сообщение от Аноним (18), 04-Окт-23, 06:39	+7 +/–
Это он. Не сильно на отца-основателя похож. https://sessionize.com/siddhesh-poyarekar#:~:text=Siddhesh&#...,performance%20for%20over%20a%20decade
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #31, #36

20. Сообщение от ДаНуНафиг (?), 04-Окт-23, 06:42	–1 +/–
Срочно переписать на русифицированном Си! https://opennet.ru/58745-vm
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

21. Сообщение от Аноним (21), 04-Окт-23, 06:50	+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. Сесурити специалисты не смогли в размеры буферов. Снова.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #158

22. Сообщение от Аноним (22), 04-Окт-23, 07:00	+2 +/–
А ты не осилил написать glibc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

23. Сообщение от СисадминА (?), 04-Окт-23, 07:00	–3 +/–
Пушто всякие дебунты это недодистрибутивы, багованые школоподелки. В мире осталось только два нормальных дистрибутива, это Альт и RHEL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #100, #138

24. Сообщение от Аноним (22), 04-Окт-23, 07:01	–1 +/–
И чего там в карго нету глибс на безопасТном?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

25. Сообщение от Аноним (22), 04-Окт-23, 07:02	+/–
Не рушь мир фанатиков безопастного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

26. Сообщение от Аноним (22), 04-Окт-23, 07:04	–3 +/–
Всё импортозамещение уже взломано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #77, #94

27. Сообщение от Аноним (27), 04-Окт-23, 07:18	+/–
Да что ж это такое, а... Этому безобразию настанет когда-нибудь конец или нет???
Ответить | Правка | Наверх | Cообщить модератору

28. Сообщение от Аноним (28), 04-Окт-23, 07:39	+2 +/–
Т.е. если в новости не написать на каком, то это автоматом станет для тебя непредсказуемым, а если ещё и физику в школе учить не будешь, то мир вообще будет полон загадок и волшебства
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #41, #121

29. Сообщение от bergentroll (ok), 04-Окт-23, 07:47	+2 +/–
Очевидно нет, если переменная предполагается для чтения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #113

31. Сообщение от Аноним (31), 04-Окт-23, 07:55	+18 +/–
>Siddhesh Poyarekar is a toolchain hacker and a Tech Lead at Linaro, managing a team of toolchain wizards. Волшебник б**
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #81, #85

32. Сообщение от АнонПапка (?), 04-Окт-23, 08:00	+/–
Кажется это Python, а в С такого нету ))))))) вот и неосилили
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

34. Сообщение от Аноним (31), 04-Окт-23, 08:04	+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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #135

35. Сообщение от mos87 (ok), 04-Окт-23, 08:05	+/–
make a sign
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

36. Сообщение от Аноним 80_уровня (ok), 04-Окт-23, 08:09	+/–
Понаведут смуззеров в глибц...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #86

37. Сообщение от Аноним (22), 04-Окт-23, 08:12	+/–
Так ты это молодой, давай переписывай. Критиковать каждый умеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #49, #61

39. Сообщение от Аноним (39), 04-Окт-23, 08:13	+2 +/–
На Эльбрусах не срабатывает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45, #56

40. Сообщение от Аноним (22), 04-Окт-23, 08:22	+6 +/–
Геройствования работы до 4 утра, мало того что это покрытие чьего-то про.кола, это напрочь сбитый лайф баланс. Здоровье не купишь не надо так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #116

41. Сообщение от Аноним (22), 04-Окт-23, 08:23	+2 +/–
Да низкий уровень образования создаёт причудливые логические связи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

43. Сообщение от eugener (ok), 04-Окт-23, 08:55	+/–
Я вчера обнову на дебиан 12 поставил около 10-ти вечера, а новость опубликована в 22:30. Норм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

44. Сообщение от ыы (?), 04-Окт-23, 08:56	+4 +/–
>Предложенный метод эксплуатации также не работает в RHEL 8 и RHEL 9, хотя данные ветки и подвержены уязвимости (для атаки требуется создание иного эксплоита). Емайл автора патча внедрившего "ошибку": Email: <siddhesh AT redhat DOT com> or <siddhesh @ sourceware DOT org>
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80

45. Сообщение от Аноним (45), 04-Окт-23, 09:13	+1 +/–
А эти Эльбрусы сейчас с тобой в одной комнате, покажи где ты их трогал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #68

47. Сообщение от Анонин (?), 04-Окт-23, 09:19	+5 +/–
Ахаха, ой не могу! Это уже которая по счету за этот месяц? Просто какой-то месяц унижения сишников. Хотя тут даже еще веселее. С буфером то все понятно - ну вышли как обычно, ну рут получили. Классика. А вот с самописным парсером параметров вообще жесть. Это насколько убогая должна быть std либа языка, чтобы не уметь в split. И каждый сплит нужно было бы писать свой велосипед, каждый со своими багами разумеется.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48, #50, #54

48. Сообщение от ыы (?), 04-Окт-23, 09:23	+2 +/–
Все они умеют.. вот как бы вы внедряли бэкдур так чтобы его не заметили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

49. Сообщение от фнон (?), 04-Окт-23, 09:25	+/–
а что лучше критиковать или писать вот такой код?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #76

50. Сообщение от ыы (?), 04-Окт-23, 09:25	+/–
Тоесть с апреля 2021 по октябрь 2023 все радетели за "обновляемся скорее свежий ядро завезли недорого без смс" - получили бэкдур... Возможно что и кто надо получил...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #57

52. Сообщение от фнон (?), 04-Окт-23, 09:27	+1 +/–
ты понимаешь, что если сделать один раз нормально - то больше код трогать не придется а так еще поколения шышников будут кормиться на исправлении ошибок (вспоминается анекдот про молодого адвоката, который выиграл семейное дело на первом же заседании)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

53. Сообщение от Анонин (?), 04-Окт-23, 09:31	+2 +/–
> я в бешенстве А зачем тебе возмущаться? Это же лучшая ось написанная на божественном языке! А не какие=то поделки корпорастов-смузихлебов. Расслабься и получай удовольствие))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

54. Сообщение от Анонин (?), 04-Окт-23, 09:35	+1 +/–
Не, ну я конечно понимаю, что намного приятнее думать что это бекдор, а не обычный быдлокод... Но даже если это бекдор, не лучше ли было бы, если бы его было бы существенно сложнее добавлять, а не просто запутаться в ручном подсчете размера буфера?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #55

55. Сообщение от ыы (?), 04-Окт-23, 09:39	+1 +/–
" - мужики, а спорим я бэкдур внедрю и мне за это ниче не будет? - Как? - сделаю вид что опечатался...при подсчетах буфера - ну давай... на банку пива "
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #66

56. Сообщение от Аноним (56), 04-Окт-23, 09:40	+/–
А какая версия Glibc там? Небось, ещё 2.2x какая-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #69

57. Сообщение от фнон (?), 04-Окт-23, 09:44	+4 +/–
ты конечно был бы прав, если бы не такие от "подарки" Например CVE-2021-22555 (https://www.opennet.ru/opennews/art.shtml?num=55488) уязвимости было больше 15 лет (Карл! еще бы годик и у нее наступил возраст согласия! хотя линуксоидов она и так поимела) или Dirty COW (https://www.opennet.ru/opennews/art.shtml?num=45354) у которой есть даже своя страничка в википедии - жила с 2007 (ядро 2.6.22) до 2016, а потом ее закрыли .... а не, не закрыли тк не учли все вектора атаки https://www.opennet.ru/opennews/art.shtml?num=47672 В общем есть два стула: на одном старые CVEшки, которые уже выбирают в какой университет поступать, с рабочими эксплойтами а на другом: новые свежие, тк писаки в ядро за 30 лет так и не смогли научиться "не выходить за пределы буфера"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #60, #63

58. Сообщение от Пряник (?), 04-Окт-23, 09:50	+/–
Действительно крайне нубская ошибка. Было вроде в каких-то языках или парсерах, но быстро исправляли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #62

59. Сообщение от Пряник (?), 04-Окт-23, 09:51	+1 +/–
Вообще концепция suid напрягает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #78

60. Сообщение от Аноним (60), 04-Окт-23, 09:57	+/–
> уязвимости было больше 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 лет...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #65, #122

61. Сообщение от Пряник (?), 04-Окт-23, 09:57	+/–
Одно другому не мешает :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

62. Сообщение от фнон (?), 04-Окт-23, 10:02	+1 +/–
а тут целое ядро и 2 года не могли заметить... но ведь тысячи глаз!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #64, #103, #149

63. Сообщение от Пряник (?), 04-Окт-23, 10:06	+/–
Нахождения старых уязвимостей - это хорошо. Но вот повторное наступление на грабли в 2021? Ни в какие ворота.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

64. Сообщение от Пряник (?), 04-Окт-23, 10:07	+3 +/–
И статические анализаторы кода. Должны были ещё при коммите заметить сразу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #72

65. Сообщение от Анонин (?), 04-Окт-23, 10:08	+/–
Ого, впечатляет! С другой стороны х11 это особый кусок... кода... Создатели которого сказали never more))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

66. Сообщение от fuji (?), 04-Окт-23, 10:27	+/–
"Таак, тут какая-то фигня. Надо правильно считать размеры буфера. Сделаю-ка я это на отшибись, авось будет работать правильно. Все равно я коммичу в какое-то ядро линукса, денег мне за это не платят. Пусть тысячи глаз перепроверят. А если будет ошибка.. То коллеги подумают, что это был бекдор. А раз бекдор - значит у меня есть крыша (АНБ, ФСБ, китайцы). А раз есть крыша - значит все будут молчать в тряпочку."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

68. Сообщение от Аноним (68), 04-Окт-23, 10:42	+3 +/–
и на столе есть и МЦСТ даёт доступ по ssh, погуглите
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #108

69. Сообщение от Аноним (68), 04-Окт-23, 10:43	+/–
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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #70

70. Сообщение от Аноним (68), 04-Окт-23, 10:44	+/–
@yukari:~$ lcc -v lcc:1.26.20:Jun--6-2023:e2k-v4-linux Thread model: posix gcc version 9.3.0 compatible.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

71. Сообщение от Шарп (ok), 04-Окт-23, 10:52	+3 +/–
Закономерный итог. Сам язык си и практики, сложившиеся вокруг него, подталкивают к написанию своих велосипедов. Не могут осилить общие библиотеки по работе со строками. Каждый программист переизобретает заново свою версию, вместо использования общей хорошо протестированной реализации. Но хотя бы Торвальдс понимает проблему и занимается внедрением более безопасного языка в ядро, не обращая внимание на вой с болот.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #73, #75, #79, #82, #106

72. Сообщение от Аноним (72), 04-Окт-23, 10:53	+1 +/–
А разве в ядре есть обязательный стат. анализатор? Проверка которого была бы необходима для создания PR? Оно же все древнее как копролит мамонта, куда исправление можно отправить почтой (хорошо хоть не голубиной)). Видел проекты типа Continuous Kernel Integration (CKI), но насколько понимаю оно не обязательно. Ядру нужен какой-то "диктатор" на пол годика, чтобы заставить всех поставить линтер, стат. анализ и сделать их проверки обязательными)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

73. Сообщение от Аноним (72), 04-Окт-23, 11:02	+2 +/–
я бы еще добавил "стандартная библиотека" мало того что написана ногами, так еще и бедная как церковная мышь приходится писать свои варианты, они разного качества (если можно так называть), они не совместимы и тд
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #97

74. Сообщение от Аноним (77), 04-Окт-23, 11:07	+/–
И где все эти кексперты по экономии места посредством отказа от статического связывания? Поливают результатом своей мозговой деятельности язык реализации, не понимая причины? Капча: 78888 ;)
Ответить | Правка | Наверх | Cообщить модератору

75. Сообщение от Анонимусс (?), 04-Окт-23, 11:09	+/–
Фиг с ней с библиотекой. Это что, единственное место в ядре где сплит нужно делать? Почему нет каких-то utils или common, в которые будут складываться стандартные методы/алгоритмы, которые нужны повсеместно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

76. Сообщение от Аноним (76), 04-Окт-23, 11:12	+1 +/–
В твой случае лучше молчать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

77. Сообщение от Аноним (77), 04-Окт-23, 11:26	+/–
Зачем "партнёры" будут ломать своих агентов, внедрившиз бэкдур в госструктуры?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

78. Сообщение от Чи (?), 04-Окт-23, 11:31	+/–
Ну отказаться от этой концепции видимо уже не получится. Как вариант обмазать все эти суид бинари правилами selinux в обязательно порядке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #88, #91, #111, #146

79. Сообщение от Аноним (79), 04-Окт-23, 11:46	+/–
Жалко только Торвальдс не поменял своего мнения о C++, который мог бы ему значительно помочь в разработке ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #83, #96

80. Сообщение от Вы забыли заполнить поле Name (?), 04-Окт-23, 11:52	+/–
Засланый казачок
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

81. Сообщение от Аноним (81), 04-Окт-23, 12:20	+7 +/–
все честно написано: Siddhesh Poyarekar is a toolchain hacker хакер - вот и сломал тулчейн.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #102

82. Сообщение от Аноним (82), 04-Окт-23, 13:43	–2 +/–
>Не могут осилить общие библиотеки по работе со строками. Каждый программист переизобретает заново свою версию, вместо использования общей хорошо протестированной реализации. А теперь предлагается вместо хорошо оттестированной реализации библиотек тащить в ядро безопасТный cargo-мусор?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #87, #132

83. Сообщение от фнон (?), 04-Окт-23, 13:49	+2 +/–
и чем плюсы лучше? посмотри сколько cve'шек на плюсах и главное каких а там то же самое, memory corruption, out-of-bounds и тд есть примеры гугла, мелкософта - которые пишут сколько проблем у них от с++ старый пост про андроид https://security.googleblog.com/2022/12/memory-safe-language... но проблемы показывает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #93

84. Сообщение от ИмяХ (?), 04-Окт-23, 13:50	–1 +/–
Почитал диффы... Ошибка настолько тупейшая, что её никак нельзя назвать ошибкой. Таких тупых вообще не допускают коммитить в ядро. Явно намеренно внедренный бекдор, который просуществовал два с половиной года, несмотря на тысячи глаз. А ещё говорят, мол, линукс безопаснее виндовса. Да этих линyкcoидов откровенно взламывают без всяких вирусов, а они всёпродолжают верить в его "безопасность."
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #90

85. Сообщение от Аноним (-), 04-Окт-23, 13:57	+/–
Так он же индус!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

86. Сообщение от Аноним (-), 04-Окт-23, 13:57	+/–
Он не смуззер, он индус.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #165

87. Сообщение от фнон (?), 04-Окт-23, 13:58	+1 +/–
Хахаха, "хорошо оттестированной реализации", прекрати человек-петроссян! Посмотри сколько сишного вна нашлось только за последний месяц! Glibc, libvpx, libwebp, целая пачка в последнем хотфиксе ядра. Посмотри сколько лет живут дырени в этих самых "проверенных и хорошо оттестированных" либах Dirty COW, CVE-2021-22555 - это десятки лет. Посмотри какой импакт имеют эти проблемы: heartbleed, куча получений рутов на миллионах девайсов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #147

88. Сообщение от Аноним (-), 04-Окт-23, 13:58	+/–
SELinux - лишнее звено.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

90. Сообщение от Аноним (72), 04-Окт-23, 14:06	+1 +/–
> её никак нельзя назвать ошибкой Ты что обвиняешь святое Сообщество в саботаже? Оно же непогрешимо и все остальные не имеют право его критиковать (а от набигут всякие неадекваты))) Интересно кто апрувнут такой pull?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

91. Сообщение от Аноним (91), 04-Окт-23, 14:29	–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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

92. Сообщение от Аноним (92), 04-Окт-23, 14:30	+/–
Ну что ты будешь делать? Опять каких-то анскильных лалок вместо Настоящих Программистов код писать пустили...
Ответить | Правка | Наверх | Cообщить модератору

93. Сообщение от Шарп (ok), 04-Окт-23, 14:47	+1 +/–
> а там то же самое, memory corruption, out-of-bounds и тд Только если писать в сишном стиле. Современный c++ (11+) обладает множеством средств, чтобы отлавливать ошибки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #98

94. Сообщение от Neon (??), 04-Окт-23, 14:51	+/–
Американские сервера тоже)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

95. Сообщение от Вы забыли заполнить поле Name (?), 04-Окт-23, 14:52	+/–
У сишников хотя бы есть софт, в котором можно делать уязвимости...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #133

96. Сообщение от vdb (?), 04-Окт-23, 14:54	+/–
В плюсах тащится совместимость с Си, стало быть, все сишные грабли по-прежнему доступны, плюс разложено много новых.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #99

97. Сообщение от Neon (??), 04-Окт-23, 14:55	+1 +/–
Стандартные библиотеки С и С++ еще и написаны больным на голову. Более уродского и неудобного нужно поискать. Логика там рептилоидов, а не людей. Да еще и дико убогие
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

98. Сообщение от фнон (?), 04-Окт-23, 15:41	+/–
Верю! Но посмотри когда в ядре отказались от с99? (напомню это был 2022) Просто представь, что c++11 попал в ядро только в 5.18, а до этого был бы C++98 или даже C++03. Сильно это бы помогло? А сколько дидов ныло бы от того что они не понимают с++? Так C11/C17 тоже существуют, вот толку если ядро пишется на некрофильской версии стандарта. Тут реалистичен только подход есть слона по кусочку, переписывая отдельные куски. Но зачем тянуть с++ если (раз уже переписываем) можно взять Раст - все равно придется переучиваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #101, #123

99. Сообщение от фнон (?), 04-Окт-23, 15:43	+/–
Ну так в названии ++ что зря поставили? "С++ это С + старые ошибки + новые ошибки" ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

100. Сообщение от еизвестный (?), 04-Окт-23, 15:55	+/–
Alt очень хорош. Ядро без нареканий собирают. Завидую. У меня норм только 4.19 получается.(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

101. Сообщение от Аноним (21), 04-Окт-23, 16:17	+/–
В 2022 отказались от C89. C99 в ядре никогда не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #104

102. Сообщение от Аноним (102), 04-Окт-23, 16:20	+4 +/–
> все честно написано: Siddhesh Poyarekar is a toolchain hacker > хакер - вот и сломал тулчейн. А разве не хакер? Сломал линухи всей планете и глазом не моргнул. Индусский кот - такой он, вот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

103. Сообщение от Аноним (102), 04-Окт-23, 16:21	+2 +/–
> а тут целое ядро и 2 года не могли заметить... Какое еще ядро, лол. - Какого цвета наш учебник?! - Какой предмет мы сдаем? - Во валит, гад!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

104. Сообщение от фнон (?), 04-Окт-23, 16:33	+/–
сорян, опечатался да, речь про C89 оно еще довольно долго обсуждалось тут lore.kernel.org/lkml/20220224062022.GH3943@kadam/T/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

105. Сообщение от Tester (??), 04-Окт-23, 17:31	+/–
> уязвимость вызвана изменением, внесённым в апреле 2021 года а почему ни кто не думает что это было сделано специально? кто внес изменения? и зачем?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #107

106. Сообщение от DildoZilla (?), 04-Окт-23, 17:43	+/–
Надеюсь, речь не о Расте, который изменяемые в будущем объекты пытается отловить до их появления, т.е. на этапе компиляции?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #109

107. Сообщение от Аноним (72), 04-Окт-23, 17:46	+/–
А если бы ее нашли лет через 10? "кто и зачем" вносил изменения в CVE-2021-22555 15 лет назад? Или в X11 30+ лет назад заложив одну из наиболее старых CVE-2023-43785? Ты задаешь вопросы вида "зачем вася попал в аварию, когда превышал скорость непристегнутым по встречке? кому было выгодно чтобы вася попал в дтп?" Мне было бы лень искать заговор там, где одни и те же ошибки делались 5, 10, 15 и 20+ лет назад. Максимум сказать "это традиция такая, овнокодить"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #163

108. Сообщение от An (??), 04-Окт-23, 18:00	+/–
Сначала нужно, чтобы он появился в продаже по сравнимым с интелом и амд ценам. Потом - чтобы под него были доступны открытая ось и открытый компилятор. Чтобы скачать и собрать из сорцов можно было. Как все это появится - зовите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #152

109. Сообщение от Анонин (?), 04-Окт-23, 18:06	+/–
Не, речь именно о нем. А что вам таки не нравится?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

110. Сообщение от Аноним (110), 04-Окт-23, 18:27	+/–
Как часто вижу подобные комментарии. Но почему никто не написал ничего на другом языке?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

111. Сообщение от Аноним (111), 04-Окт-23, 18:37	+1 +/–
Получится, если будет политическая воля. Более 20 лет шло балабольство о невозможности отказа от GIL. Потом пришёл Micro$oft, нанял ключевых разрабов, и в течение года проблема будет решена, а несогласным придётся утереться. Если найдётся корпорация, которая смажет всё деньгами - проблема мигом будет решена. И suid уберут, и программы, которые нужно будет править, либо поправят, либо на свалку истории отправят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

112. Сообщение от мяя (?), 04-Окт-23, 18:42	+/–
Но Раст базируется на libc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #118

113. Сообщение от Аноним (113), 04-Окт-23, 18:50	+1 +/–
А есть какие-то иные переменные окружения?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

115. Сообщение от Аноним (115), 04-Окт-23, 19:42	+4 +/–
Причем каждый раз когда я пишу про 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 на такую же целевую аудиторию с ней будет  еще хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #117, #119, #120, #150, #156

116. Сообщение от Аноним (116), 04-Окт-23, 19:42	+/–
> это напрочь сбитый лайф баланс В том-то и дело, что нет у него никакого лайфа...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

117. Сообщение от Анонин (?), 04-Окт-23, 21:14	+1 +/–
Просто интересно, а если ли хоть какая-то система где все перечисленное реализовано, причем правильно, или хотя бы близко к нему? И насколько оно юзерфрендли? Потому что за линуксом сидят не только пользователи с отдельным отделом ИБ, но и обычное юзверье, которому все ваши ACL и политики - китайская грамота.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

118. Сообщение от Аноним (118), 04-Окт-23, 21:52	+1 +/–
> Но Раст базируется на libc. Но только в грезах и фантазиях Военов Супротив Раста. man syscalls > System calls are generally not invoked directly, but rather via wrapper functions in glibc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

119. Сообщение от User (??), 04-Окт-23, 22:21	+/–
Осталось ответить на вопрос "ну и вот нахрена это ХОТЬ КОМУ-НИБУДЬ чтоб это самому делать или хотя бы денег за это заплатить"? И можно в путь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #129

120. Сообщение от Аноним (120), 04-Окт-23, 22:28	+/–
> Решается эта проблема так: Получается Windows. Но ведь она давно уже есть, зачем изобретать велосипед?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #128

121. Сообщение от Аноним (120), 04-Окт-23, 22:34	+/–
Дружище, если что-то писать на делфи, то с высокой степенью вероятности в коде будут глюки вида "объект на форму кинули, но все нужные методы для него создать забыли". Если питонятина, то можно ждать что штука которая запускалась пару версий назад не запустится на текущей. Если сишка - жди проблем с памятью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #162

122. Сообщение от Аноним (120), 04-Окт-23, 22:40	+/–
Дарю для комплекта CVE-2021-3999. Она старше Windows 95.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

123. Сообщение от Вы забыли заполнить поле Name (?), 04-Окт-23, 23:31	+/–
> Так C11/C17 тоже существуют, вот толку если ядро пишется на некрофильской версии > стандарта. > можно взять Раст - > все равно придется переучиваться. У раста новая версия как часто выходит? Стоит ли такое тянуть, если проблемы с переходом на новый стандарт С, который выходит раз в 10 лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #126, #127

124. Сообщение от Аноним (124), 05-Окт-23, 02:54	+/–
> Уязвимость в Glibc ld.so Не очень понял почему ошибка именно в ld.so. ld.so задействован же при запуске только динамически линкуемых бинарников или статических тоже?
Ответить | Правка | Наверх | Cообщить модератору

125. Сообщение от Аноним (125), 05-Окт-23, 09:25	+1 +/–
> Уязвимость устранена в патче, добавленном 2 октября. Проследить за выпуском обновлений пакетов в дистрибутивах можно на страницах Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, Gentoo, ALT Linux. А как там российские "Астра", "Роса" и прочие сбер-линуксы, много лет простоят дырявыми, но с сертификатами ФСТЭК? Или таки там был аудит и ошибки изначально не было? Но, судя по тому, что у альта она таки была, скорее всего, это не ошибка, а бэкдор...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #164

126. Сообщение от Анонн (?), 05-Окт-23, 09:41	+2 +/–
У раста кроме версий, которые выходят раз в 6 недель и являются просто процессом развития языка, еще есть editions. Вот они больше соответствуют версиям С/С++. Выходят раз в 3 года - уже есть 2015, 2018, 2021. И переход с 2015 даже на 2021 не такой уж болезненный. Более того, ты можешь совмещать разные editions в одном проекте, т.к. он фиксируется для каждого crate в отдельности. Тебе не нужно сразу бросаться обновлять всё до новой edition, если вдруг ты хочешь в каком-то новом модуле использовать последние фичи языка. Вообще ничего можно не делать, разве что явно прописать старый edition в toml файлах, если не сделал раньше (хотя лучше сразу фиксировать актуальный). Вот дока если интересно: https://doc.rust-lang.org/edition-guide/editions/index.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #139

127. Сообщение от Анонн (?), 05-Окт-23, 09:56	+/–
Когда-то в отдаленном будущем у editions тоже будет end of life. Пока что в документации нет сроков, но это и так понятно, что не разумно тянуть старые версии вечно. Но в таком случае нужно будет обновлять только неподдерживаемые крейты и только до последней актуальной версии, а не до последней существующей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

128. Сообщение от Аноним (115), 05-Окт-23, 12:18	+3 +/–
Во-первых не просто 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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #130, #157

129. Сообщение от Аноним (115), 05-Окт-23, 12:54	+/–
Вопросы по всем перечисленным пунктам многократно поднимались в списках рассылки ядра, были неоднократные попытки реализовать и Rich ACLs и дескрипторы. Практика показывает, что это не вопрос денег, это вопрос принятия патчей. - Бешенные бараны упираются рогами в землю и не хотят ни применять патчи, ни пользоваться этим, потому что это "как в Windows". Если они узнали бы что разработчики Windows едят еду и пьёт воду, они бы объявили сухую голодовку и сдохли бы в знак протеста. - Тупые овцы не понимают, зачем вообще всё это нужно, потому что не видели задач вне локалкоста. Они прекрасно живут и так, и УМВР и "ви врёти всё". - Религиозные ослы верят в единорогов, гномов и в контейнерную изоляцию, через докер от рута, которая что-то от чего-то защищает через пространства имён. Проблема прежде всего в компетенции...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #137

130. Сообщение от Аноним (130), 05-Окт-23, 13:05	+/–
Suid не обходит selinux.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #131

131. Сообщение от Аноним (115), 05-Окт-23, 13:26	+/–
Он не обходит его на этапе работы с контекстом вызываемой утилиты, в том и только в том случае если есть специально оформленное правило в рамках Targeted Policy. Политика мандатного контроля по умолчанию всегда является таргетированной, она не распространяется на ВСЁ, за исключением единичных случаев, когда в рамках корпоративного использования её вменяют на шаблонизированные рабочие станции и сервера. Он обходит его на этапе запуска. SELinux позволяет существовать возможности неподконтрольного ему поднятия привилегий даже в объявленном и подконтрольном ему контексте. Ну то есть у вас дыра в заборе и двери в доме нарастапашку. Грабители вынесли абсолютно всё из дома, но в сарай не попали, сарай закрыт на ключ. Как-то так... Вот есть отличное видео о том как сейчас работает SELinux: https://www.youtube.com/watch?v=fB2b-lTjCQA
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

132. Сообщение от Аноним (132), 05-Окт-23, 15:53	+/–
>  вместо хорошо оттестированной реализации библиотек тащить в ядро безопасТный cargo-мусор? Кто тебе мешает из карго-мусора отобрать нужные тебе в проекте оттестированные крейты, самому их проверить и оттестировать (ведь исходники СИшных  "хорошо оттестированных" библиотек ты сам лично вычитал и оттестировал, верно? Раз уверен в них?), положить эти крейты в своё локальное хранилище и в проекте натравливать карго на использование локального, протестированного тобой, хранилища? По мере выхода новых версий крейтов или при возникновении необходимости притащить из внешней карго-мусорки что-то новое - повторяешь вышеописанные действия, т.е. перегоняешь проверенное в локальную мусорку. Для сишных "хорошо оттестированных реализаций библиотек" ты ведь заново проверяешь, не сломали ли они что в новых версиях свежими патчами, не всунули ли бэкдора? В чем тогда разница растовых крейтов и сишных библиотек при условии что ты, как "здоровый параноик", в проекте настроишь карго на получение крейтов с локальной проверенной мусорки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

133. Сообщение от Аноним (132), 05-Окт-23, 16:03	+/–
у растовиков тоже есть - уже немало кода в последних версиях андроида (на декабрь 2022-го 21% всего нового нативного кода, т.е. С/С++/Rust), но вот беда - за несколько лет внесения туда расто-кода в компонентах на нем не было совершено НИ ОДНОЙ ошибки работы с памятью. Так что поправлю, перефразирую - "У сишников хотя бы есть язык, в котором при работе с памятью можно делать уязвимости..." - гордись, у растовиков с этим труднее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #134

134. Сообщение от Вы забыли заполнить поле Name (?), 05-Окт-23, 16:48	+/–
>уже немало кода в последних версиях андроида (на декабрь 2022-го 21% всего нового нативного кода, т.е. С/С++/Rust) Это наглая манипуляция статистикой: "немало" и 21% на С/С++. Сколько из этого кода раста в процентах? > НИ ОДНОЙ ошибки работы с памятью Сидят 2 ковбоя в салуне. Один другого спрашвивает: - Слушай, а кто это там на лошади гарцует? - Это же Неуловимый Джо. - А его правда никто поймать не может? - Да кому он на*** нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

135. Сообщение от InuYasha (??), 05-Окт-23, 17:24	+/–
AT&T - та ещё корпорация зла. Позлее гугла в свои времена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

136. Сообщение от Аноним (136), 05-Окт-23, 18:52	+2 +/–
> Уязвимость вызвана изменением, внесённым в апреле 2021 года и вошедшим в состав выпуска glibc 2.34. Это не деды, а понабежавшие пионеры-двоечнеки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

137. Сообщение от User (??), 05-Окт-23, 19:07	+/–
>[оверквотинг удален] > - Бешенные бараны упираются рогами в землю и не хотят ни применять > патчи, ни пользоваться этим, потому что это "как в Windows". Если > они узнали бы что разработчики Windows едят еду и пьёт воду, > они бы объявили сухую голодовку и сдохли бы в знак протеста. > - Тупые овцы не понимают, зачем вообще всё это нужно, потому что > не видели задач вне локалкоста. Они прекрасно живут и так, и > УМВР и "ви врёти всё". > - Религиозные ослы верят в единорогов, гномов и в контейнерную изоляцию, через > докер от рута, которая что-то от чего-то защищает через пространства имён. > Проблема прежде всего в компетенции... Ну, в общем я и говорю - примерно всем пох. Или "не пох" в степени недостаточной чтоб хоть что-то в этом направлении сделать. ЕМНИП, NFSv4 acl слабали санки для солярки - и уже оттуда оно оно кои-8-как доползло и до linux'ов - и то не так, чтобы полностью - самбе было надо, они накостылили поверх чего умели и как могли, остальным как было пох - так и осталось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

138. Сообщение от Аноним (130), 05-Окт-23, 19:23	+/–
Slackware отличный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

139. Сообщение от Вы забыли заполнить поле Name (?), 05-Окт-23, 19:31	+/–
> которые выходят раз в 6 недель и являются просто процессом развития языка, еще есть editions. Вот они больше соответствуют версиям С/С++ Какая-то подмена понятий. У современного С++ выходят новые версии стандарта, которые отвечают за эволюционное развитие. У раста раз в 6 недель такое же развитие, добавление новых фич и т.п. > Тебе не нужно сразу бросаться обновлять всё до новой edition, если вдруг ты хочешь в каком-то новом модуле использовать последние фичи языка. Да, давай в каждом модуле будем использовать разные версии. Отличная идея Уолтер, просто офигительная, надежная как швейцарские часы (с)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #140

140. Сообщение от Анонн (?), 05-Окт-23, 20:15	+1 +/–
Нет, это не подмена понятий. > У современного С++ выходят новые версии стандарта У плюсов стандарты тоже выходят примерно раз в 3 года. Только потом еще нужно пару лет подождать, пока все фичи стандарта поддержат в компиляторах. Напомню, что модули добавили в С++20... а когда их реально сделали? Чтобы такая аналогия была хоть как-то близкой к реальности - нужно еще сидеть на бета версиях... или даже на альфах компилятора. А тут ты фиксируешь предыдущий edition и тебе ничего добавляться не будет. Только фиксы, если будут. > Да, давай в каждом модуле будем использовать разные версии. А в чем проблема? Крейты атомарны. Давайте тогда сидеть на древней версии, потому что объективно не состоянии одновременно перевести N-миллионов строк кода на новый стандарт. И обновляться раз в 10-20 лет. Этот план лучше? С растом ничто не мешает идти по пути нынешнего си в линуксе: фиксируем edition, пишем на нем пока она не устареет совершенно, потом перепрыгиваем через два-три, исправляем пару сотен тысяч deprecations и изменений синтаксиса, и опять заморозить edition на N-лет. Путь проверен и понятно что он отстой. Но с растом есть еще другой путь, который описал выше. Будет ли он лучше... а пока не попробуешь - не узнаешь. Но в обычном софте вполне уживаются крейты разных edition.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #141

141. Сообщение от Вы забыли заполнить поле Name (?), 05-Окт-23, 20:18	+/–
> Но с растом есть еще другой путь, который описал выше. > Будет ли он лучше... а пока не попробуешь - не узнаешь. > Но в обычном софте вполне уживаются крейты разных edition. Ядро по факту монорепозиторий. Во всех номральных монорепозиториях жесткая привязка к версиям компиляторов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #142

142. Сообщение от Анонн (?), 05-Окт-23, 20:30	+/–
Тебе не нужно по компилятору на каждый 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 Понимаю, что звучит слишком круто и вызывает недоверие :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #144

144. Сообщение от Вы забыли заполнить поле Name (?), 06-Окт-23, 00:49	+/–
> Понимаю, что звучит слишком круто и вызывает недоверие :) Нормальным компилятором С++ можно собрать код любого стандарта, даже древнейшего. В монорепоизториях фисируется именно версия стандарта того же С++. Почитай гайды разработки того же chromium.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #151

145. Сообщение от uis (??), 06-Окт-23, 12:19	+/–
strstr
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

146. Сообщение от uis (??), 06-Окт-23, 12:24	+/–
Эммм... POSIX file capabilities.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

147. Сообщение от uis (??), 06-Окт-23, 12:44	+/–
Матчасть учи, Dirty COW не вв либе был.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

149. Сообщение от Kuromi (ok), 06-Окт-23, 17:12	+1 +/–
Как вариант - не заметили потому что отвернулись в сторону. Я не фанат конспирологии, но иногда слишком уж похоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

150. Сообщение от Kuromi (ok), 06-Окт-23, 17:21	+/–
"Я в реальной жизни встречал баранов, которые выключили SELinux, понаставили "chmod 777" и пренебрежительно рассказывают мне о высочайшей безопасности Linux  и про то что Windows на железо им страшно ставить. " Ну разумеется. Потому что безопасность и удобство очень редко идут рука об руку и в какой-то момент любой человек может сказать "да к черту, залолбало разбираться почему Х не запускается или Y валится с ошибкой потому что что-то где-то права не такие как надо (по умолчанию или наоборот)." И тогда в ход идут "три топора" (извините, не удержался). Это чаще всего не баранство, а просто "усталось". По той же самой причине народ прется через рельсы (и попадает регулярно под поезд) когда обходной безопасный путь "всего на килотметр-два длиннее".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

151. Сообщение от Анонн (?), 06-Окт-23, 17:58	+/–
Но ты не можешь часть сорцов ядра собрать одним стандартом, а часть - другим. А тут можно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #153

152. Сообщение от Аноним (152), 06-Окт-23, 18:03	+/–
Зачем? Ты не нужен, сиди и жди халяву дальше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #155

153. Сообщение от Вы забыли заполнить поле Name (?), 06-Окт-23, 23:25	+1 +/–
> Но ты не можешь часть сорцов ядра собрать одним стандартом, а часть > - другим. > А тут можно. Пока что нет ответа на главный вопрос - зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

155. Сообщение от An (??), 08-Окт-23, 16:36	+/–
Ну ок. Тогда смотрим на альтернативы: x86_64, ARM, RISC-V. А вы и дальше сидите в бункере со своей "прелестью".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

156. Сообщение от крокодил мимо.. (?), 08-Окт-23, 18:53	+/–
> Решается эта проблема так: кмк, необходимо и достаточно внимательно аудировать код утилит, требующих 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, которая появилась "от безысходности", если можно так сказать :)).. другими словами, можно вспомнить профессора Преображенского, объясняющего Борменталю, что порядок должен быть прежде всего в голове..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

157. Сообщение от Аноним (157), 08-Окт-23, 21:13	+/–
> из принципа не следует стандартам 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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #159

158. Сообщение от Аноним (157), 08-Окт-23, 21:26	+/–
> деды дали в рейтузы Деды на пенсии давно. А в леггинсы дали молодые опеннет-балаболы, сами-то они безрукие, только дедовское пользуют и ругают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

159. Сообщение от User (??), 10-Окт-23, 09:44	+/–
>> из принципа не следует стандартам POSIX > Жопslashes, case-нетерпимость, буквы устройств, ФС без DAC и стойкое желание всё это > насадить всем другим, POSIX-совместимым ОС, а хоть бы и через железных > вендоров (см. UEFI), -- не дадут соврать. Из принципа. Чтобы всё, > что напишут "Developers, Developers", работало только в Пинде и нигде больше > - без переписывания. Нууу... вы так говорите, будто в этом POSIX in our days есть хоть что-то хорошее - это даже не говоря о том, что на "posix compilance" linux "in general" никогда и не закладывался )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #160

160. Сообщение от Аноним (160), 10-Окт-23, 10:04	+/–
Одна только унификация - на вес золота. Много хорошего, за неимением лучшего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #161

161. Сообщение от User (??), 10-Окт-23, 10:14	+/–
> Одна только унификация - на вес золота. Много хорошего, за неимением лучшего. Ну вот кушайте posix acl, не обляпайтесь. Ой, а он !внезапно! не часть POSIX. "У" - унификация! "Г"... каквсигда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

162. Сообщение от inferrna (ok), 12-Окт-23, 16:13	+/–
>питонятина >запускалась пару версий назад не запустится на текущей Не совсем так. Сам питон в минорных версиях ничего не ломает, это скорее из мира php. А вот что ломает питон, ноду, пых и даже хачкель, так это новые версии библиотек, ибо нет нормального версионирования зависимостей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

163. Сообщение от Tester (??), 22-Дек-23, 16:43	+/–
> А если бы ее нашли лет через 10? > "кто и зачем" вносил изменения в CVE-2021-22555 15 лет назад? > Или в X11 30+ лет назад заложив одну из наиболее старых CVE-2023-43785? > Ты задаешь вопросы вида "зачем вася попал в аварию, когда превышал скорость > непристегнутым по встречке? кому было выгодно чтобы вася попал в дтп?" > Мне было бы лень искать заговор там, где одни и те же > ошибки делались 5, 10, 15 и 20+ лет назад. > Максимум сказать "это традиция такая, овнокодить" у тебя может и традиция, у меня это скорей всего сделано специально, и скорей всего тот кто вносил изменения наверно знал что делает. неизвестную уязвимость можно продать если что. либо подождать когда она попадет в нужный дистрибутив. в нужную организацию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

164. Сообщение от Tester (??), 22-Дек-23, 16:45	+/–
>> Уязвимость устранена в патче, добавленном 2 октября. Проследить за выпуском обновлений пакетов в дистрибутивах можно на страницах Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, Gentoo, ALT Linux. > А как там российские "Астра", "Роса" и прочие сбер-линуксы, много лет простоят > дырявыми, но с сертификатами ФСТЭК? Или таки там был аудит и > ошибки изначально не было? Но, судя по тому, что у альта > она таки была, скорее всего, это не ошибка, а бэкдор... а разве аудита в RedHat небыло? Там и людей протирающих щтаны поболее будет...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

165. Сообщение от 128557 (?), 31-Янв-24, 16:14	+/–
Индус - это диагноз. Каким выглядит мир, когда в голове одни танцы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

166. Сообщение от Werenter (ok), 02-Фев-24, 11:48	+/–
У меня ничего не произошло, просто выдало --help
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема