The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Уязвимость в runc, позволяющая выбраться из контейнеров Docker и Kubernetes, opennews (ok), 03-Фев-24, (0) [смотреть все]

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


6. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +10 +/–
Сообщение от Аноним (2), 03-Фев-24, 13:27 
Дак и Си никогда не причём, это все процессор и контроллер памяти
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  –3 +/–
Сообщение от Аноним (13), 03-Фев-24, 14:11 
Это да. Если компиляторы сишки будут бить разработчика десятком киловольт при любой попытке использовать указатели или динамически аллоцировать память — сишка станет безопасным языком.
Ответить | Правка | Наверх | Cообщить модератору

31. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +7 +/–
Сообщение от Аноним (31), 03-Фев-24, 15:50 
Без динамического выделения памяти вообще жизнь станет совсем тяжёлой. Даже Pascal может в динамические массивы.
Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  –2 +/–
Сообщение от Аноним (13), 03-Фев-24, 17:49 
Любителей Turbo Pascal можно пересадить на Turbo Basic. Такой же синий экран, но куда более безопасный язык.
Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (71), 03-Фев-24, 22:08 
Почему именно Турбо вспомнил? Есть вполне живой Free, который, наверное, в Linux даже более востребован, чем Windows.
Ответить | Правка | Наверх | Cообщить модератору

87. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от _kp (ok), 04-Фев-24, 05:23 
При всей нелюбви к Паскалю, таки использую, для небольших приложений, типа загрузкиков и конфигураторов устройств, ибо Лазарус собирает нативные приложения под Mac,Win,Linux с минимумом усилий.
Еще забавно, что студент вообще без знания Паскаля может на нем что нибудь написать полезное с минимумом подсказок.
Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (91), 04-Фев-24, 07:40 
> Любителей Turbo Pascal можно пересадить на Turbo Basic. Такой же синий экран,
> но куда более безопасный язык.

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

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

112. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (13), 04-Фев-24, 14:48 
Единственный безопасный метод запуска программ на небезопасных языках — не запускать эти программы.
Ответить | Правка | Наверх | Cообщить модератору

232. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (-), 06-Фев-24, 13:52 
> Единственный безопасный метод запуска программ на небезопасных языках — не запускать
> эти программы.

Ну я и предложил - не включать его. Решает в том числе и эту проблему, начиная прямо с boot ROM и UEFI. И кстати проверьте что сетевой шнур - отключен от розетки! Иначе какая-нибудь пакость типа ME - все равно пролезет ведь. Только полное отключение питания, только хардкор.

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

67. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Bottle (?), 03-Фев-24, 21:53 
Кстати такое можно неиронически устроить - с помощью системы сборки Cmake, подключая некий файл "forbidden.h" с переопределёнными функциями к любому другому. Тем самым можно запретить небезопасные функции и писать как на Расте, не переписывая код на Раст.
https://iq.opengenus.org/ban-use-of-c-functions/
https://stackoverflow.com/questions/32773283/cmake-include-h...
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

86. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Ivan_83 (ok), 04-Фев-24, 03:15 
Тут несколько аспектов.

1. Есть масса простых утилит, где не важно что и как, важно чтобы оно просто отработало на тех полутора примерах для которых написано.

2. Есть всякие анализаторы которые делают примерно тоже - возмущаются по делу и просто так на эти функции.

3. Та реализация что представлена генерит 3 строки на каждое вхождение, это не удобно.

В целом я согласен что srtcpy() и прочие функции для работы со строками без указания размера буфера не безопасны и не должны использоватся в современном коде.
Выкидывать strncpy() - глупо.
Но лично я бы предпочёл чтобы в компиляторы добавили варнинг про это, вместо этого туда нынче засунули самый бесполезный в мире варнинг -Wunsafe-buffer-usage чтобы подчеркнуть неисправимую неполноценность С и подтолкнуть к С++ и гнили.

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

95. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от нах. (?), 04-Фев-24, 10:10 
ну вот кстати я слабо понимаю пользу от strn*

Зачем нам огрызок строки и что с ним делать если была нужна вся строка? Это вот уже плохие данные и чреваты уязвимостью дальше.
В большинстве реальных ситуаций с копированием строк ты сначала меряешь, потом выделяешь под копию место, не влезло - плюешься ошибкой, потом туда копируешь уже точно зная длину. И ошибки происходят потому что просто неправильно померяли - результат ты радостно запихнешь и в функцию с n.

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

При этом strcpy и memcpy эффективны, ложатся в одну команду процессора, а вот варианты с n - нет, в процессоре не бывает комплексных проверок.

P.S.
#define BUF *buf
%s/strcpy(buf,string)/strncpy(BUF,string,sizeof(BUF))/g
Сасамба. 1998й год.

Уровень людей считающих что функции с n модно-надежно-безопастно. Сейчас такие программируют на безопастных йезычках примерно так же вот.

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

100. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (2), 04-Фев-24, 12:54 
> И ошибки происходят потому что просто неправильно померяли - результат ты радостно запихнешь и в функцию с n.

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

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

104. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от нах. (?), 04-Фев-24, 14:32 
И как это вот оно так получается-то, что без конца при этом попадают мимо?

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

И, повторяю для полных дол..ов - что будем делать если даже правильно все посчитали, нигде не ошиблись - но оно - вот?


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

132. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Ivan_83 (ok), 04-Фев-24, 23:01 
Вы всегда можете пропатчить/заменить strncpy() на нечто будет вызывать abort() (аварийно завершать процесс), если вам это так надо :)

Вот такой макрос помогает понять когда функция сфейлилалась:
#define IS_SNPRINTF_FAIL(__rc, __buf_size)                \
    (0 > (__rc) || (__buf_size) <= (size_t)(__rc))
Но всё равно есть куча применений где пофик что оно могло сфейлится, или понятно сразу что сфейлится там просто не возможно, потому даже strcpy() часто безопасно применять.

> При этом strcpy и memcpy эффективны, ложатся в одну команду процессора

Вы считаете это смешно?
Даже на z80 memcpy() требовал более 1 инструкции, тк нужно было в регистры записать аргументы.
А для х86 эффективные реализации memcpy() довольно развесистые, с переходом на SIMD где это имеет смысл.

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

134. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от нах. (?), 04-Фев-24, 23:29 
> Вы всегда можете пропатчить/заменить strncpy() на нечто будет вызывать abort() (аварийно
> завершать процесс), если вам это так надо

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

> или понятно сразу что сфейлится там просто не возможно, потому даже strcpy() часто безопасно
> применять.

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

> А для х86 эффективные реализации memcpy() довольно развесистые, с переходом на SIMD где это
> имеет смысл.

и им лишняя проверка тоже совершенно никчему.
Потому что jnz БЕЗ отдельной операции сравнения у нас есть наверное в любой архитектуре, кроме совсем уж странных, а "jnz но если еще и вон там образовался нолик то не" как-то не просматривается.

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

137. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Ivan_83 (ok), 05-Фев-24, 02:30 
У меня лично работа со строками обычно идёт как работа с буферами сырых данных (те указатель + размер, нуль никто не ищет), а всякие strncpy() почти не используются, snprinf() юзаются вон с тем макросом, обычно чтобы нагенерить ответ.


> а вот применение где "и таааак сойдет" мне вообразить довольно сложно, что бы это могло бы быть?

Иногда и на С пишут какие то проги типа как на Shell Script нечто, для того чтобы сделать простую работу или проверить что оно работает.
https://github.com/rozhuk-im/sec-omc-coder
Упадёт такое - да и пофиг, нужно оно раз в году для одного файла.
Или я как то писал удалятор временных файлов под венду, и кидал в автозагрузку. По сути это легко можно было заменить на .cmd файл или .sh под не вендой, но мне тогда в голову как то не пришла такая идея и я написал на С :)

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

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

238. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (-), 06-Фев-24, 19:16 
> https://github.com/rozhuk-im/sec-omc-coder
> Упадёт такое - да и пофиг, нужно оно раз в году для одного файла.

Вопрос: что сие за штука? Что за omc и самсунги? Такое описание как будто все знают о чем это. Самсунг производит что угодно - от аккумуляторов до морских кораблей, это хардварная версия Гугла.

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

151. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от ng (ok), 05-Фев-24, 11:10 
> srtcpy() и прочие функции для работы со строками без указания размера буфера не безопасны и не должны использоватся в современном коде.

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

Бетонный отбойник гарантированно исключает выезд на встречную полосу.

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

Добро пожаловать в безопасный, дивный мир. ;-)

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

172. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (172), 05-Фев-24, 14:55 
>Бетонный отбойник гарантированно исключает выезд на встречную полосу.

В бетонном отбойнике нет unsafe. И вылет на встречную он не гарантирует.

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

202. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от ng (ok), 05-Фев-24, 18:02 
В точку!

Безопасность движения - это, сначала, мастерство водителей, а разметка дорог потом.

Надёжность программ - это, сначала, мастерство программистов, и "безопасный" ЯП потом.

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

203. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (-), 05-Фев-24, 19:27 
>>Бетонный отбойник гарантированно исключает выезд на встречную полосу.
> В бетонном отбойнике нет unsafe. И вылет на встречную он не гарантирует.

Ну вот хрустовский panic() это типичный бетонный отбойник. И хотел ли ты его получить в случае если кернел линуха не смог вооон там в аллокацию памяти - большой такой вопрос. Может лучше было зафейлить сискол с каким-нибудь -ENOMEM или чем там, да и хорен с ним - по сравнению с падежом всего кернела с грохотом то? Конечно, в панике кернел в довольно безопасном стостоянии, но...

На память об этом безопасные хрустики придумали try* костыли на свои конструкции (чем это так отличается от остальной динамической аллокации, с которой боролись?!). Изящно так получилось, совсем не похоже на костыль и на то с чем так пафосно боролись. Оказывается постоянно убиваться о бетонный отбойник то - это такое себе. Надо же!

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

82. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  –2 +/–
Сообщение от Ivan_83 (ok), 04-Фев-24, 01:20 
Нужна не абстрактная безопасность а работоспособность и производительность.
При этом работоспособность иногда включает в себя и вашу "безопасность", если это является целью работы програмы.

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

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

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

84. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (84), 04-Фев-24, 02:53 
Мне почему-то кажется, что вы ездите на автомобиле, не пристёгиваясь ремнём.
Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Ivan_83 (ok), 04-Фев-24, 02:55 
Вам действительно кажется :)
Я езжу В такси, пристёгиваясь там где таксисты не убрали ремни.
Ответить | Правка | Наверх | Cообщить модератору

116. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +2 +/–
Сообщение от Аноним (13), 04-Фев-24, 14:59 
Как насчёт того, что пристёгивание ремнём влияет на производительность поездки (добавляет +2 секунды в начале и в конце)?
В вашем представлении, это должен быть очень серьёзный оверхед.
Ответить | Правка | Наверх | Cообщить модератору

140. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Ivan_83 (ok), 05-Фев-24, 02:37 
Функция перевозки - доставить пассажира до места целым, очевидно что не пристёгивание может повлиять на целостность :)
Водитель обычно не ждёт когда пристегнутся, по крайней мере здесь обычно так, и поскольку он не стартует сразу до сотки (да тут и погонять негде) то это не существенно.
Ответить | Правка | Наверх | Cообщить модератору

204. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (-), 05-Фев-24, 19:29 
> Как насчёт того, что пристёгивание ремнём влияет на производительность поездки (добавляет
> +2 секунды в начале и в конце)?
> В вашем представлении, это должен быть очень серьёзный оверхед.

Ну, если телепортатор перекидывал меня через половину глобуса за секунду - 2 секунды на пристегнуться, и 2 на отстегнуться будут, очевидно, подбешивать...

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

88. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +2 +/–
Сообщение от Аноним (-), 04-Фев-24, 06:02 
> При этом работоспособность иногда включает в себя и вашу "безопасность", если это является целью работы програмы.

Корректность программы -- это составная часть работоспособности. А если мы под "безопасностью" понимаем safety в стиле раста, то это составная часть корректности. К киберсекурити это имеет лишь косвенное отношение.

> А эта ваша "безопасность" похоже на кастрацию, когда ничего в языке сделать нельзя

Не лезь в программирование, это не твоё. Попробуй сисадмином устроиться, там надо не столько уметь, сколько знать, то есть декларативное знание важнее процедурного. Может тебе лучше зайдёт.

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

111. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (13), 04-Фев-24, 14:47 
> Нужна не абстрактная безопасность а работоспособность и производительность.

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

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

90. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (91), 04-Фев-24, 07:39 
> Это да. Если компиляторы сишки будут бить разработчика десятком киловольт при любой
> попытке использовать указатели или динамически аллоцировать память — сишка станет
> безопасным языком.

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

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

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

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




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

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