The OpenNET Project / Index page

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



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

"Локальная уязвимость в сетевой подсистеме ядра Linux"  +/
Сообщение от opennews (??), 22-Сен-23, 09:18 
В сетевой подсистеме ядра Linux выявлена  уязвимость (CVE-2023-42752), позволяющая через манипуляции с сетевыми сокетами в пространстве пользователя перезаписать содержимое памяти ядра, что потенциально может использоваться для организации выполнение непривилегированным пользователем своего кода на уровне ядра. Уязвимость является локальной и не может быть эксплуатирована удалённо по сети. Включение механизма защиты SMAP (Supervisor Mode Access Prevention) в ядре блокирует проблему...

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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 22-Сен-23, 09:18   +8 +/
Хорошая демонстрация к недавней новости: https://www.opennet.ru/opennews/art.shtml?num=59791 "Модель полного переноса изменений выгодна прежде всего с точки зрения безопасности, так как, при выборочном переносе исправлений не всегда очевидна связь исправления с устранением потенциальных проблем с безопасностью. При полном переносе изменений проблема часто оказывается решена ещё до того, как появляется информация о том, что исправление блокирует уязвимость."

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

C другой стороны, баг вызывающий уязвимость,  бэкпортировали в старые LTS-ветки и т.е.  кто переносят все исправления успешно перенесли к себе и баг с уязвимостью.

Получается палка о двух концах :-)

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #31

2. Сообщение от ryoken (ok), 22-Сен-23, 09:21   –2 +/
А у меня уже 2 недели как 6.5.3 :).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #27, #116

4. Сообщение от Аноним (4), 22-Сен-23, 09:28   +20 +/
Любая палка она о двух концах. Палка о трёх концах это, как минимум, рогатка =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10, #133

5. Сообщение от Пряник (?), 22-Сен-23, 09:30   +1 +/
> Переполнение возникает из-за отсутствия должной проверки получаемых от пользователя параметров

hahaha, classic

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #71, #74

7. Сообщение от Пряник (?), 22-Сен-23, 09:33   +3 +/
Баги тоже нужно бэкпортировать!
Ответить | Правка | Наверх | Cообщить модератору

8. Сообщение от Аноним (8), 22-Сен-23, 09:33   –2 +/
зато почти каждый день новое ядро
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20

9. Сообщение от ComradeDOS (ok), 22-Сен-23, 09:33   +4 +/
Нормальные посоны уже давно на 6.5.4 сидят.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #25, #83, #103

10. Сообщение от Аноним (10), 22-Сен-23, 09:35   +/
Чтобы каждая палка была третьей..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

12. Сообщение от Rev (?), 22-Сен-23, 09:42   +1 +/
> Включение механизма защиты SMAP (Supervisor Mode Access Prevention) в ядре блокирует проблему.

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #53

15. Сообщение от Аноним (15), 22-Сен-23, 09:56   +1 +/
Комитетов и ревьюаеров лишить премии!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #18

16. Сообщение от Аноним (15), 22-Сен-23, 09:57   +/
Коммитера и ревьюверов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

17. Сообщение от Анонит (?), 22-Сен-23, 09:58   –1 +/
4.19 божественен.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35, #132

18. Сообщение от Аноним (20), 22-Сен-23, 10:00   +/
Как лешить нуля?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #21, #29

20. Сообщение от Аноним (20), 22-Сен-23, 10:02   +4 +/
Мерилом работы считаем усталость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #124

21. Сообщение от Аноним (15), 22-Сен-23, 10:05   +/
В минус
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #23

23. Сообщение от Аноним (20), 22-Сен-23, 10:08   +/
Похоже я знаю как сделать шаражку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

24. Сообщение от Аноним (24), 22-Сен-23, 10:20   –2 +/
Господа, а в Gentoo (и возможно в арче) ванильное ядро? А то я убунтоид сижу аж на 20.04 в браузере новости ютуб телеграм всё работает и слоупочу со старым дырявым ядром и хочу стать прогрессивным как вы тут(((
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48, #59, #79, #84, #100, #125

25. Сообщение от Минона (ok), 22-Сен-23, 10:23   +/
На 6.(9)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

27. Сообщение от nlug7 (?), 22-Сен-23, 10:30   +/
нормальные пацаны на 3.10 сидят )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #32

28. Сообщение от Мда (?), 22-Сен-23, 10:39   +/
Ну как так то! Ну классика проверки же:
if (a + b < a)
        /* overflow */
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36, #41, #50

29. Сообщение от Мда (?), 22-Сен-23, 10:43   +2 +/
Что такое 'лешить'?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #75

31. Сообщение от Мда (?), 22-Сен-23, 10:47   +/
Они, видимо, имели в ввиду отсутствие кровавого мерджинга изменений. Нам приходится тащить для особенных клиентов древние версии софта и это то ещё удовольствие патчи мержить по частям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

32. Сообщение от Мда (?), 22-Сен-23, 10:47   +2 +/
Это какие-то ортодоксальные староверы.:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #45

35. Сообщение от Аноним (118), 22-Сен-23, 11:15   +/
Нет, 5.4 и 5.10.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #57, #102

36. Сообщение от Аноним (36), 22-Сен-23, 11:20   +2 +/
>if (a + b < a)

Наивный...
Почитайте, как в Си работает undefined behavior. В вашем случае если оба значения signed integer (не важно какого размера, главное что не unsigned), то signed integer overflow является UB, и в лучшем случае компилятор должен выдать warning когда такое делают, в худшем случае уберёт эту проверку и грубо говоря подставит if (1).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #42, #108

37. Сообщение от Аноним (37), 22-Сен-23, 11:22   +1 +/
Пользуйтесь статическими анализаторами, и Раст будет не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #39, #78, #95, #111, #121

38. Сообщение от Анонин (?), 22-Сен-23, 11:26   +/
Да, пользуйтесь статическими анализаторами!
И тогда вам не только придется фиксить классический баг, но и бекпортить еще в кучу старых веток.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

39. Сообщение от фнон (?), 22-Сен-23, 11:27   +/
но тогда придется переписать почти все ядро, тк там дидами хаков закопано %(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #89

41. Сообщение от 29см (?), 22-Сен-23, 11:29   +/
Компилятор случаем не схлопывает такие проверки с флагами выше -O0 по принципу "сумма беззнаковых всегда больше слагаемого, а знаковое переполнение UB"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #49, #110

42. Сообщение от 29см (?), 22-Сен-23, 11:33   +/
Сильно изменится ситуация с unsigned вне дебага?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #104

45. Сообщение от фнон (?), 22-Сен-23, 11:47   +5 +/
староверы сидят на 2.6.х и 2.4 ))
(относительно) недавно была тема про дроп i386, от там они ныли и возбухали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #120

47. Сообщение от Аноним (48), 22-Сен-23, 11:51   –1 +/
Блин, а где нормальный список уязвимых версий посмотреть? В ветку v5.15 этот коммит походу не был бэкпортирован.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #63

48. Сообщение от Аноним (48), 22-Сен-23, 11:54   +/
20.04 до середины 24го года если авто-обновление настроено и комп перезагружаешь хоть иногда, то можешь не париться, будут фиксы приходить, а эту уязвимость тебе даже не бэкпортировали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #77

49. Сообщение от фнон (?), 22-Сен-23, 11:58   +2 +/
а это может зависить от версии копилятора)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

50. Сообщение от фнон (?), 22-Сен-23, 12:03   –1 +/
эта ситуация опять напомнила, что UB это костыли и зло

известный пример https://godbolt.org/z/9j3Pxz
    if (number > 0) {
        number += 1;
        if (number > 0) {
            std::cout << number << " is a positive number.\n";
        }
        else {
            std::cout << number << " is NOT a positive number.\n";
        }
    }

в зависимости от уровня оптимизации -O0 или -O2 результат получается противоположный(!)

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #52, #93, #113

52. Сообщение от Серб (ok), 22-Сен-23, 12:19   +/
Я так понимаю, что этот UB для того и сделан, что бы можно было оптимизацию производить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #54, #68

53. Сообщение от ivan_erohin (?), 22-Сен-23, 12:23   +/
> механизмы затыкания пальцем уязвимостей

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

54. Сообщение от фнон (?), 22-Сен-23, 12:27   +2 +/
ты это же не серьезно? правда?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #56

56. Сообщение от Серб (ok), 22-Сен-23, 12:37   +/
> если нельзя написать код который "гарантированно и однозначно" сложит 2 инта...

У тебя поведение зависит от архитектуры (железа) и оно однозначно: результат то сложения одинаков.

Вот сравнение да - для его выполнения идет учет UB.
UB дает возможность как угодно оптимизировать

Как хотим так и делаем.

Хочешь повторяемости - не дай оптимизации использовать UB;
Сделай так:

number += 1;

int number1 = number;

if (number1 > 0)
{
}

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #58, #64

57. Сообщение от Анонит (?), 22-Сен-23, 12:41   +1 +/
Игры хуже работает у которых как пояснили есть ограничение кадров в секунду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

58. Сообщение от Анониммм (?), 22-Сен-23, 12:46   +/
Т.е выход из ситуации, просто подстраиваться под так называемый "стандарт"?

> У тебя поведение зависит от архитектуры (железа) и оно однозначно: результат то сложения одинаков.

Я вот это не очень понимаю ¯\_(ツ)_/¯
У меня есть мой код и железо;
Железо и код не поменялись, но компилятор обновил мажорную версию;
Прога которая просто одевала ботинок, теперь отстреливает ногу

Или я просто скомпилил один и тот же код, в дебаге и релизе (что может менять уровень оптимизации).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #60

59. Сообщение от Аноним (59), 22-Сен-23, 13:02   –1 +/
В Gentoo ядра на любой вкус, включая ванильные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #62

60. Сообщение от Серб (ok), 22-Сен-23, 13:06   +/
> Т.е выход из ситуации, просто подстраиваться под так называемый "стандарт"?

Выхода 2:

1. Ты знаешь стандарт и работаешь по нему. Тут тебе по-барабану тонкости работы с железом.
2. Ты знаешь железо и компилятор и работаешь по ним. Так работают в ядре, потому что тонкости работы с железом, тут черезвычайно важны.

Ну и третий. Работай с другим языком. Там будут свои трудности и ограничения, но это уже другая история.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #61

61. Сообщение от Анониммм (?), 22-Сен-23, 13:14   +/
понятно
тогда я наверное предпочту сменить язык)

потому что проверять список UB при написании простейших "a + b" не слишком хочется
вот список УБшек для "стандарта" С99 https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1
всего-то 193 штуки
думаю для 17 и 2х список еще больше

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #66

62. Сообщение от Анонит (?), 22-Сен-23, 13:16   +/
xanmod не очень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #86

63. Сообщение от Анониммм (?), 22-Сен-23, 13:22   +/
а зачем? ты что не любишь сюрпризы?
тебе это дает невереоятную возможность почиатать релиз ноуты, посмотреть код,
возможно даже самостоятельно что-то бекпортнуть и собрать ядро ручками!

просто манна небесная для пользователя линукса!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #65

64. Сообщение от Анонин (?), 22-Сен-23, 13:24   +/
А можно подробнее про "поведение зависит от архитектуры (железа)"?
Для какого железа из такого кода нельзя получить одинаковые результаты?

Т.е. напр. мы хотим получить saturating add, но один проц так не делает по умолчанию, а другой делает.
Что мешает просто для первого заменить маш код нативной суммы на нужное нам поведение во время компиляции?
Тогда на всех платформах будет однозначное поведение, а не вот это вот.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #69

65. Сообщение от Аноним (48), 22-Сен-23, 13:40   +/
Ну я уже порадовался что надо разобраться что есть в `torvalds/linux`, и что есть в `stable/linux`, и освежил в памяти что существует `git tag --contains`. Но видимо что-то не докопал, откуда-то же взялось 5.15 в новости?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

66. Сообщение от Серб (ok), 22-Сен-23, 13:53   +/
> хорошо, что в последннее время все больше людей убеждаются, что "дальше так жить нельзя"
> надеюсь такие подходы уйдут в лету вместе с языком

А вот это вряд ли. Тут или переносимость и возможности оптимизации, тогда UB необходим.
Или все регламентировано, но тогда не переносимости, не возможностей оптимизации.

Переносимость еще можно добавить, используя свой рантайм. За счёт производительности естественно.
Но это если с железом работать не надо, если надо, тогда ОЙ!

Выбирая язык другого типа ты меняешь нишу программирования.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #67

67. Сообщение от Аноним (67), 22-Сен-23, 13:55   +/
> тогда UB необходим.

А давно у нас #ifdef запретили?
Пиши валидный код без UB, просто для каждой платформы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #70, #106

68. Сообщение от Аноним (67), 22-Сен-23, 13:56   +1 +/
А в чем собственно оптимизация?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #73

69. Сообщение от Серб (ok), 22-Сен-23, 13:57   +/
> заменить маш код нативной суммы на нужное нам поведение во время компиляции?

Зачем тогда ориентироваться на железо? Таскай свой рантайм и работай на нём. Тогда всегда всё будет предопределено.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #72, #105

70. Сообщение от Серб (ok), 22-Сен-23, 14:00   +/
>> тогда UB необходим.
> А давно у нас #ifdef запретили?
> Пиши валидный код без UB, просто для каждой платформы.

Вы КО.
Это и есть способ обрабатывать UB.

Вот только есть языки, с жесткой заточкой на безопасность программирования, у них игры с #ifdef становятся неподъемными.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #112

71. Сообщение от Аноним (71), 22-Сен-23, 14:06   +2 +/
Ага, надо переписать на Rust ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #115

72. Сообщение от Анониммм (?), 22-Сен-23, 14:11   +/
возможно это будет лучше чем получение уязвимостей
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #80

73. Сообщение от Серб (ok), 22-Сен-23, 14:14   +/
Тут выхлоп в виде ассемблера не смотрел, но очевидно, перенос сравнения на этап компиляции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #82

74. Сообщение от bOOster (ok), 22-Сен-23, 14:22   +2 +/
И Rust как не странно в этой проблеме не поможет. Тут только мозги человеческие нужны..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

75. Сообщение от Аноним (71), 22-Сен-23, 14:23   +1 +/
Отправить к лешему
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

76. Сообщение от Аноним (78), 22-Сен-23, 14:24   +/
>Уязвимость вызвана изменением, внесённым в ядро 6.2, но данное изменение было бэкпортировано во все LTS-ветки, поэтому уязвимость проявляется и в более ранних выпусках поддерживаемых стабильных веток ядра.

Обожаю такое!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #94

77. Сообщение от bOOster (ok), 22-Сен-23, 14:25   +1 +/
Перезагрузка - после linux обновления - опасное действие, ну по крайней мере в Ubuntu.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #98, #117

78. Сообщение от Аноним (78), 22-Сен-23, 14:27   –1 +/
>Пользуйтесь статическими анализаторами, и Раст будет не нужен.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

79. Сообщение от Аноним (71), 22-Сен-23, 14:30   +1 +/
Чтобы свежее ядро собрать не обязательно быть на Gentoo. Скачать с kernel.org и собрать. Как собрать, статей найдётся предостаточно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

80. Сообщение от Серб (ok), 22-Сен-23, 14:47   +/
> возможно это будет лучше чем получение уязвимостей

Возможно.
Если бы победил, какой-либо рантайм и десятилетиями потом не менялся. Почти как java, в свое время.

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

К обилию плохого качества повторно используемого кода.

А вот тут уже есть варианты относительно "возможно".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

81. Сообщение от Аноним_5 (?), 22-Сен-23, 15:00   +2 +/
Просто какое-то сишное бинго.
буффер + Integer overflow + UB = LCE
Ответить | Правка | Наверх | Cообщить модератору

82. Сообщение от Анониммм (?), 22-Сен-23, 15:00   +/
префразирую классику
те кто разменивают скорость на безопастность, получают и уязвимости, и тратят время на их исправление
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #87

83. Сообщение от ryoken (ok), 22-Сен-23, 15:02   +/
> Нормальные посоны уже давно на 6.5.4 сидят.)

Федороводы? :)

На этой неделе не обновлялся, может уже и приехало в xanmod-оверлей.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

84. Сообщение от ryoken (ok), 22-Сен-23, 15:05   +/
> Господа, а в Gentoo (и возможно в арче) ванильное ядро? А то
> я убунтоид сижу аж на 20.04 в браузере новости ютуб телеграм
> всё работает и слоупочу со старым дырявым ядром и хочу стать
> прогрессивным как вы тут(((

У генты сейчас есть своё бинарное дистроядро, 6.4.16, если eix не врёт. Есть и всякие оверлеи + флаги - у меня например xanmod подключен, оттуда на момент послденего системного обновления приехало 6.5.3.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

86. Сообщение от ryoken (ok), 22-Сен-23, 15:06   +/
> xanmod не очень.

Чем именно? Стоит не гавкается.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #96

87. Сообщение от Серб (ok), 22-Сен-23, 15:10   +/
> префразирую классику
> те кто разменивают скорость на безопастность, получают и уязвимости, и тратят время
> на их исправление

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

Время - время разработки.

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

Ну а как бороться с ошибками?

Тесты, тесты и еще раз тесты. Причём в разном окружении. Что там насчёт CI?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #91

88. Сообщение от Аноним (89), 22-Сен-23, 15:18   +/
>Включение механизма защиты SMAP (Supervisor Mode Access Prevention) в ядре блокирует проблему.

Ну значит можно и не фиксить. Те, у кого камень без поддержки SMAP, сами виноваты и могут идти туда, куда Полонский послал.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #97

89. Сообщение от Аноним (89), 22-Сен-23, 15:23   +/
Вот поэтому раст и не взлетел - мешает работать, уязвимости оставлять!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

91. Сообщение от Анониммм (?), 22-Сен-23, 15:33   +/
неа, время - это не только разработка
это еще время на фикс, на тестирование, на обновление кода на уязвимых машинах
если тебе нужно обновить ядро на серваке тк уязвимость с повышением привилегий - то время простоя, это потерянные деньги

> Ошибки, среди которых могут быть и уязвимости

логические ошибки к ub не относятся, так код будет работать однозначно неправильно
но если посмотреть на CVEшки через которые напр. получается рут - то там по большей часть проблемы с памятью, bout-of-bounds, ase-after-free и тд

например в С++ Dereferencing a NULL pointer это UB

> Что там насчёт CI?

хз, если честно
надеюсь там тесты есть, включая фаззинг, но тесты пишут люди и часто на том же языке

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

93. Сообщение от Совершенно другой аноним (?), 22-Сен-23, 15:58   +/
UB это наследие тех времён, когда на некторых архитектурах байты были 9 бит, а слова - 36. И каждый из производителей железа тащил в свою сторону. Это сейчас, по большому счёту осталось только 2 платформы - x86_64 и ARM. У которых и индейцы совпадают, и float IEEE-шный, но так было не всегда..

Если Вам надо гарантировано обрабатывать переполнение, в случае gcc добавьте -fwrapv. Кроме того, можно воспользоваться __builtin_sadd_overflow()/__builtin_ssub_overflow(). В стандарте С23 эту функциональность стандартизируют в форме ckd_add()/ckd_sub().

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #107, #109

94. Сообщение от Аноним (95), 22-Сен-23, 15:59   +/
Ничего необычного просто результат деградации специалистов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #99

95. Сообщение от Аноним (95), 22-Сен-23, 16:01   +1 +/
> статическими анализаторами

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

96. Сообщение от Анонит (?), 22-Сен-23, 16:16   +/
Тем же,что описал выше. Как по мне так лучше РТ патчи накатить на 4.19
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

97. Сообщение от 1 (??), 22-Сен-23, 16:30   +/
а много ли таких хотя бы более-менее актуальных процов есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

98. Сообщение от Менеджер Антона Алексеевича (?), 22-Сен-23, 16:53   +/
И чем же оно опасно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

99. Сообщение от Менеджер Антона Алексеевича (?), 22-Сен-23, 16:58   +1 +/
Да, при чём эта деградация началась ещё в 1972 году.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

100. Сообщение от anonymous (??), 22-Сен-23, 17:03   +/
В раче есть rt, zen, libre, xanmod и ванильное, на любой вкус, в общем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

101. Сообщение от dannyD (?), 22-Сен-23, 17:07   +/
так всё было понятно,
в репах Gentoo появились ревизии 6.1.53-r1, 6.5.3-r1.

это значит - срочно латали дыру.

вот, теперь выяснили в чём дело.

Ответить | Правка | Наверх | Cообщить модератору

102. Сообщение от dannyD (?), 22-Сен-23, 17:13   +/
>>Нет, 5.4 и 5.10.

прикола ради перепрыгнул с 6.1 на 6.5,
такое впечателение, что с трактора на самолёт.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

103. Сообщение от dannyD (?), 22-Сен-23, 17:18   +/
>>давно

три дня как )))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

104. Сообщение от Аноньимъ (ok), 22-Сен-23, 17:35   –1 +/
В случае беззнакового оно просто начнет считать с нуля, оно как бы не ub, но смысл тот же.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

105. Сообщение от Аноньимъ (ok), 22-Сен-23, 17:46   +/
Рантайм то тут причем?

Переполнение и интовая арифметика банальная и очень болезненная проблема.

Сделать гарантированные функции и функции на прямую дергаюшие железо.

И все будут довольны.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

106. Сообщение от Аноньимъ (ok), 22-Сен-23, 17:47   +/
Для каждой комбинации железа версии и типа компилятора и флагов оптимизации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

107. Сообщение от Аноньимъ (ok), 22-Сен-23, 17:49   +1 +/
> В стандарте С23 эту функциональность стандартизируют в форме ckd_add()/ckd_sub().

Ура! Не прошло и 30 лет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

108. Сообщение от Мда (?), 22-Сен-23, 18:15   +/
"Почитайте, как в Си работает undefined behavior." - после этого дальше можно не читать. Вы не очень понимаете, что такое undefined behavior.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

109. Сообщение от Анониммм (?), 22-Сен-23, 18:17   +/
спасибо, спасибо очень помогло

вот только ядро до сих пор на древнем С11 (и перешли они туда в 22м году!)
причем не на стандартном ISO С, а на богомерзких гнутых расширениях gnu11

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #131

110. Сообщение от Мда (?), 22-Сен-23, 18:17   +1 +/
Теоретически может, но при разработке ядра (для ядра) есть описание по флагам и т.п., что включаем, а что нет. Известен же эпический rant Линуса по поводу какой-то новой на тот момент версии gcc, генерирующий дичь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #126

111. Сообщение от фнон (?), 22-Сен-23, 18:18   +/
ну так ядро ими со всех сторон обмазано? обмазано же?
так чего столько CVEшек ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

112. Сообщение от фнон (?), 22-Сен-23, 18:20   +/
> есть языки, с жесткой заточкой на безопасность программирования,

например? MISRA C? ADA?

поэтому у нас будут UB и код без безопастности)
отличный план, надежный как швейцарские часы!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

113. Сообщение от Мда (?), 22-Сен-23, 18:32   +/
"Я тебя полюбил, я тебя научу" (с)
См. флаг -fwrapv
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #114

114. Сообщение от фнон (?), 22-Сен-23, 18:36   +/
тормозить будет(
хотя да, предлагали
https://bugzilla.kernel.org/show_bug.cgi?id=12597
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

115. Сообщение от Аноним (115), 22-Сен-23, 18:44   +/
Раст не защищает от логических ошибок (такие вещи автоматически можно отслеживать разве что в каких-нибудь языках с зависимыми типами а-ля Idris)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

116. Сообщение от Oe (?), 22-Сен-23, 18:45   +/
День назад поставил 7.8.5, жизнь стала реально лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #118

117. Сообщение от microcoder (ok), 22-Сен-23, 18:46   +1 +/
так не перезагружайся сразу, выжди сутки. В течении суток обычно на Манджаре прилетают хот фиксы, не знаю как в Бубунте
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

118. Сообщение от Аноним (118), 22-Сен-23, 20:38   +/
А волосы шелковистые и не секутся? Поздравляю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

120. Сообщение от Аноним (120), 22-Сен-23, 20:46   +/
А они что-то важное держат на старом селероне или туроне? Не знаю что даже сказать — разве что переходить на MenuetOS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #130

121. Сообщение от Аноним (121), 22-Сен-23, 20:48   +/
гугл, собрав свою статистику по си/плюсовым проектам, заявляет, что использование разных техник программирования, всевозможных анализаторов и фаззинг-тестирования не очень помогает:

"...We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabilities found in old code that are included in the above evaluation. These are important tools, and critically important for our C/C++ code. However, these alone do not account for the large shift in vulnerabilities that we’re seeing, and other projects that have deployed these technologies have not seen a major shift in their vulnerability composition. We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor... "

Отсюда:
"Memory Safe Languages in Android 13"
https://security.googleblog.com/2022/12/memory-safe-language...

гуглу я доверяю в _этом_ вопросе гораздо больше, чем тебе, брат аноним.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #134

124. Сообщение от Аноним (10), 22-Сен-23, 21:26   +/
Это про других же
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

125. Сообщение от коньюктивит (?), 22-Сен-23, 22:15   +/
А я даже не знаю на каком я сижу ядре. Там в "О системе" наверняка написано, но что-то мне лениво туда заходить. Всё работает как всегда. Скучно.. :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

126. Сообщение от 29см (?), 22-Сен-23, 23:25   +/
Вроде было про включенный по дефолту strict aliasing, с его запретом привычного type punning)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

130. Сообщение от Аноним (130), 23-Сен-23, 07:48   +/
Не могут себе позволить апгрейд на железо хотя бы прошлого десятилетия
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

131. Сообщение от Совершенно другой аноним (?), 23-Сен-23, 14:41   +/
> вот только ядро до сих пор на древнем С11 (и перешли они туда в 22м году!)

ну, как-бы, после C11 был C17, в котором ничего нового не добавили, а просто поправили накопившиеся замечания. А в C11, по сравнению с C99, имхо, более-менее полезными были alignas/alignof и анонимные структуры и объединения (которые существовали в виде расширений уже довольно давноЮ по-моему ещё в древнем bcc 3.1 уже были)ю

> причем не на стандартном ISO С, а на богомерзких гнутых расширениях gnu11

ну, как-бы builtin-ы, насколько я помню не зависят от версии языка, а -fwrapv существует уже очень давно, как минимум точно есть в gcc 4.8+.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

132. Сообщение от Аноним (132), 23-Сен-23, 15:45   +/
Считаешь с 2.6.32 уже можно переходить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

133. Сообщение от Заноним (?), 23-Сен-23, 16:35   +/
Первое утверждение верно и для рогаки и для любой другой палки где N-концов > 2. ж)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

134. Сообщение от Аноним (-), 23-Сен-23, 23:01   +/
> ... We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor... "
> гуглу я доверяю в _этом_ вопросе гораздо больше, чем тебе, брат аноним.

Ну, а на чём основано доверие им в *этом* вопросе? -
Может они просто обставляют ситуацию для перетягивания всего что можно в "memory-safe languages"?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121


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

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




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

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