The OpenNET Project / Index page

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



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

"Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от opennews (??), 06-Янв-23, 21:28 
В библиотеке Hyper, предлагающей реализацию протоколов HTTP/1 и HTTP/2 на языке Rust, выявлена особенность работы с памятью, которая может использоваться для инициирования отказа в обслуживании  через исчерпание доступной процессу памяти. Для эксплуатации уязвимости достаточно отправить специально оформленный HTTP-запрос уязвимому обработчику, использующему Hyper. Библиотека достаточно популярна (67 млн загрузок) и используется в качестве зависимости у 2579 проектов, представленных в каталоге crates.io...

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

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

Оглавление

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


1. Скрыто модератором  +5 +/
Сообщение от Аноним (1), 06-Янв-23, 21:28 
Ответить | Правка | Наверх | Cообщить модератору

54. Скрыто модератором  –1 +/
Сообщение от Прохожий (??), 07-Янв-23, 01:46 
Ответить | Правка | Наверх | Cообщить модератору

154. Скрыто модератором  –1 +/
Сообщение от Аноним (-), 07-Янв-23, 06:03 
Ответить | Правка | Наверх | Cообщить модератору

189. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 12:27 
Ответить | Правка | Наверх | Cообщить модератору

72. Скрыто модератором  –1 +/
Сообщение от Аноним (72), 07-Янв-23, 02:30 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

74. Скрыто модератором  +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:33 
Ответить | Правка | Наверх | Cообщить модератору

77. Скрыто модератором  +1 +/
Сообщение от Прохожий (??), 07-Янв-23, 02:36 
Ответить | Правка | Наверх | Cообщить модератору

79. Скрыто модератором  +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:37 
Ответить | Правка | Наверх | Cообщить модератору

82. Скрыто модератором  +1 +/
Сообщение от Прохожий (??), 07-Янв-23, 02:39 
Ответить | Правка | Наверх | Cообщить модератору

84. Скрыто модератором  +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:40 
Ответить | Правка | Наверх | Cообщить модератору

88. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 02:42 
Ответить | Правка | Наверх | Cообщить модератору

86. Скрыто модератором  +1 +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:41 
Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

91. Скрыто модератором  –1 +/
Сообщение от Прохожий (??), 07-Янв-23, 02:43 
Ответить | Правка | Наверх | Cообщить модератору

155. Скрыто модератором  –1 +/
Сообщение от Аноним (-), 07-Янв-23, 06:04 
Ответить | Правка | Наверх | Cообщить модератору

172. Скрыто модератором  +1 +/
Сообщение от Прохожий (??), 07-Янв-23, 11:33 
Ответить | Правка | Наверх | Cообщить модератору

102. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 02:53 
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

129. Скрыто модератором  –1 +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:22 
Ответить | Правка | Наверх | Cообщить модератору

130. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 03:26 
Ответить | Правка | Наверх | Cообщить модератору

133. Скрыто модератором  +/
Сообщение от Аноним (133), 07-Янв-23, 03:41 
Ответить | Правка | Наверх | Cообщить модератору

138. Скрыто модератором  –1 +/
Сообщение от Аноним (138), 07-Янв-23, 03:57 
Ответить | Правка | Наверх | Cообщить модератору

144. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 04:07 
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

170. Скрыто модератором  +1 +/
Сообщение от YetAnotherOnanym (ok), 07-Янв-23, 11:23 
Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

171. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 11:31 
Ответить | Правка | Наверх | Cообщить модератору

83. Скрыто модератором  +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:39 
Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

94. Скрыто модератором  +/
Сообщение от Аноним (72), 07-Янв-23, 02:48 
Ответить | Правка | Наверх | Cообщить модератору

124. Скрыто модератором  +/
Сообщение от Аноним (133), 07-Янв-23, 03:15 
Ответить | Правка | Наверх | Cообщить модератору

158. Скрыто модератором  +/
Сообщение от Sw00p aka Jerom (?), 07-Янв-23, 09:09 
Ответить | Правка | Наверх | Cообщить модератору

78. Скрыто модератором  +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:36 
Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

85. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 02:40 
Ответить | Правка | Наверх | Cообщить модератору

89. Скрыто модератором  +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:42 
Ответить | Правка | Наверх | Cообщить модератору

95. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 02:48 
Ответить | Правка | Наверх | Cообщить модератору

180. Скрыто модератором  +/
Сообщение от Ананимаз (?), 07-Янв-23, 11:53 
Ответить | Правка | Наверх | Cообщить модератору

185. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 12:02 
Ответить | Правка | Наверх | Cообщить модератору

233. Скрыто модератором  +/
Сообщение от Аноним (233), 07-Янв-23, 16:45 
Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

96. Скрыто модератором  +/
Сообщение от Аноним (72), 07-Янв-23, 02:49 
Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

76. Скрыто модератором  +1 +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:34 
Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

81. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 02:37 
Ответить | Правка | Наверх | Cообщить модератору

228. Скрыто модератором  +/
Сообщение от Аноним (228), 07-Янв-23, 16:18 
Ответить | Правка | Наверх | Cообщить модератору

234. Скрыто модератором  +/
Сообщение от Аноним (233), 07-Янв-23, 16:47 
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

90. Скрыто модератором  +/
Сообщение от Аноним (90), 07-Янв-23, 02:43 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

139. Скрыто модератором  +/
Сообщение от Аноним (138), 07-Янв-23, 04:00 
Ответить | Правка | Наверх | Cообщить модератору

192. Скрыто модератором  +/
Сообщение от Прохожий (??), 07-Янв-23, 12:33 
Ответить | Правка | Наверх | Cообщить модератору

2. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +16 +/
Сообщение от ПомидорИзДолины (?), 06-Янв-23, 21:35 
Ожидаемое поведение, в документации все описано.

JFrog решили в очередной раз попиарится - ок. Зачем это сюда принесли?

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

3. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +7 +/
Сообщение от ПомидорИзДолины (?), 06-Янв-23, 21:38 
Второй параграф в документации

> Care needs to be taken if the remote is untrusted. The function doesn’t implement any length checks and an malicious peer might make it consume arbitrary amounts of memory. Checking the Content-Length is a possibility, but it is not strictly mandated to be present.

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

17. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от НяшМяш (ok), 06-Янв-23, 22:35 
Делают комбайн со 100500 возможностей - фуфуфу гигантская кодовая база, сложно проводить аудит и вообще не юниксвейно.
Делают библиотеку с ограниченной функциональностью - о нет она не валидирует штуканейм и это уязвимость.

Типичная биполярка различных экспертов.

P.S. https://docs.rs/tower-http/latest/tower_http/limit/struct.Re...

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

25. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (25), 06-Янв-23, 23:24 
Можешь как угодно называть уязвимость (ниже уже назвали "задокументированным поведением"), как угодно критиковать архитектуры и как угодно выставлять диагнозы опеннетчикам, но отказ в обслуживании это не исправит.
Ответить | Правка | Наверх | Cообщить модератору

194. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +5 +/
Сообщение от Прохожий (??), 07-Янв-23, 12:40 
Проблема этой ветки обсуждения в том, что некоторые комментаторы пытаются экстраполировать человеческую ошибку пользователей библиотеки на якобы имеющиеся изъяны языка программирования.

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

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

261. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от keydon (ok), 07-Янв-23, 23:21 
Проблема этой ветки в том что раст преподносился (и преподносится) как язык решающий человеческие ошибки. Но по факту он решает их малую часть (и создает новые). То есть от чего уходили (человеческие ошибки в си) к тому и пришли (человеческие ошибки в расте).
Люди разделились на тех кто решил этого не замечать (растоманы) и тех кто об этом говорил с момента зарождения раста (сишники). В зависимости от этого и разное отношение к каждой подобной новости.
Ответить | Правка | Наверх | Cообщить модератору

273. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (90), 08-Янв-23, 00:10 
> Но по факту он решает их малую часть (и создает новые).

Ложь. Решает бОльшую часть. Решает 70% ошибок. 30% < 70%. Новые не создвал. Просвети насчет новых. Главная ошибка - ты не смог осилить новый ЯП?

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

284. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от keydon (ok), 08-Янв-23, 01:00 
> Ложь. Решает бОльшую часть. Решает 70% ошибок. 30% < 70%. Новые не
> создвал. Просвети насчет новых.

Давай посчитаем. Какие конкретно ошибки в твоих программах с использованием современного C/C++ по современным методикам с линтерами и анализаторами решил раст и к каким последствиям эти ошибки привели лично для тебя и твоих пользователей?

> Главная ошибка - ты не смог осилить
> новый ЯП?

Спервадобейся в 2023? Серьезно?
"Но я же могу рассуждать о качестве омлета, хотя еще ни разу не снёс ни одного яйца."

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

362. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Анимус (?), 10-Янв-23, 18:58 
Зачем обмазываться линтерами, анализаторами и распухшим до безобразия новым стандартом, если можно писать сразу удобно и в кайф?
Ответить | Правка | Наверх | Cообщить модератору

370. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от keydon (ok), 11-Янв-23, 12:50 
> Зачем обмазываться линтерами, анализаторами и распухшим до безобразия новым стандартом,

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

> если можно писать сразу удобно и в кайф?

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

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

300. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (300), 08-Янв-23, 13:43 
> раст преподносился (и преподносится) как язык решающий человеческие ошибки

Вот только не было обещаний, что он решит их все.

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

306. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от keydon (ok), 08-Янв-23, 14:38 
>> раст преподносился (и преподносится) как язык решающий человеческие ошибки
> Вот только не было обещаний, что он решит их все.

Я еще с первых форсов раста писал что чуда не случится и все имеет свою цену, давайте разбирать техническую сторону и смотреть трезво на то что раст предлагает и что он требует. Никто из растоманов тогда не удосужился адекватно ответить что же раст порешает и каким образом.
Это не мешало растоманам ругать си и основной упор был на дедовские библиотеки, необходимость бесконечных проверок в коде на си, сложности написания безопасного кода на си и т.д.. Проходит несколько лет и несколько относительно крупных проектов на расте..."забывают" добавить проверку описанную в документации. Прямо как деды в си. Конечно "это не проблема раста", но уязвимости в программах на си не были "проблемами ЯП", а именно так заявляли растоманы.
Я прекрасно помню как в новостях об очередной найденной нетривиальной уязвимости утилиты на си, допущенной программистом (а не ограничем ЯП), приходили растоманы и писали что на си невозможно написать безопасный код и что срочно надо все переписать на расте. Теперь ровно такая же ситуация (даже намного более тривиальная) с проектами на расте, но растоманы говорят "вы не понимаете! это другое! наш ЯП не виноват". Так и си был не виноват.
Двуличность растоманов мягко говоря зашкаливает.

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

240. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от НяшМяш (ok), 07-Янв-23, 17:45 
Если ты бездумно используешь метод "я буду сохранять все байтики в память", который явно в документации помечен опасным - надо свою кукуху лечить, а не низкоуровневую библиотеку. А вот почему создатели более высокоуровневых реализаций серверов не поставили ограничение по-умолчанию - это уже совершенно обоснованная претензия.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

73. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +3 +/
Сообщение от Аноним (72), 07-Янв-23, 02:32 
>Care needs to be taken if the remote is untrusted.

У них там с башкой проблема? Remote is always implicitly untrusted.

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

125. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от ПомидорИзДолины (?), 07-Янв-23, 03:15 
Нет. Remote может быть nginx в режиме reverse proxy, который сделает все проверки за тебя.
Ответить | Правка | Наверх | Cообщить модератору

148. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +8 +/
Сообщение от Аноним (148), 07-Янв-23, 04:13 
Это же библиотека для сборки из кирпичиков, а не полнофункциональный сервер. А лимит понятие относительное. На видеохостинге он обычно чуть больше, чем на смарт-часах.

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

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

27. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (25), 06-Янв-23, 23:26 
Так и в си UB описаны, необходимость проверок тоже. Но почему-то в си это фатальный недостаток, а в расте "задокументированное поведение".
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

35. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (35), 06-Янв-23, 23:40 
> Так и в си UB описаны, необходимость проверок тоже.

Правда, сам ты весь список не читал, просто слышал звон.
> Но почему-то в си это фатальный недостаток, а в расте "задокументированное поведение".

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

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

104. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +4 +/
Сообщение от Аноним (90), 07-Янв-23, 02:55 
>  а в расте "задокументированное поведение".

В расте или в имплементации какой-то библиотеки на расте? Ты чем читал? Молодец, сравнил недостатки языка программирования си с недостатками кем-то написанной библиотекой-фреймворком. Никто не мешает тебе сознательно на расте написать пучок "полезных" фреймворков, специально впендюрить туда что-то типа "извне запросили выделить 1 мегабайт памяти? Выделю 1 гигабайт, ха-ха-ха", а потом кричать на каждом углу: "-раст гнилой! Он ошибки памяти делает! Жрет как не в себя!". Ну или не проверять переданные извне параметры. И опять у тебя будет раст виноват, чего это ЯП, а не программист, не проверил, что там в JSON/XML прилетело.

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

157. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (25), 07-Янв-23, 08:55 
Ну пошли отмазки. Лет 9 назад вас, растоманов, не волновало что ещё и библиотеки надо писать с новыми багами(между прочим один из аргументов сишников против раста) и вообще думать все равно придется. Наоборот, растоманы писали что "разработчики раста уже подумали за программиста". Теперь вот на ходу (последние несколько лет) меняете риторику.
Всё чем вы оправдываетесь в последнее время, всё это писали вам сишники лет 9 назад.
Ответить | Правка | Наверх | Cообщить модератору

175. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 11:41 
Это не отмазки. Это попытка объяснить слабым разумом, что данная конкретная ошибка не имеет никакого отношения к языку программирования. Но некоторым, что в лоб, что по лбу. Увы.
Ответить | Правка | Наверх | Cообщить модератору

236. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Аноним (228), 07-Янв-23, 17:05 
Библиотека на чем написана? Значит обгадился раст.
Ответить | Правка | Наверх | Cообщить модератору

249. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от freecoder (ok), 07-Янв-23, 22:13 
Попытка выделить большой кусок памяти не является небезопасной операцией. Safe Rust такое разрешает и подобные "ошибки" (а на самом деле и не ошибки вовсе) не устраняет.
Ответить | Правка | Наверх | Cообщить модератору

272. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (90), 08-Янв-23, 00:08 
хе, представляю. Пишет кто-то какой-нибудь хайлоад для суперкомпа с терабайтом озу. Выделяет такой память под буфер, скажем, 10ГБ (ну там наколеночно-велосипедный in-memory-db), а тебе такой компилятор (или код в рантайме) раз: " - ошибка! разрешается выделять не более 1МБ ОЗУ, я так решил, 1 МБ должно хватить всем! Читай мануал языка, там это написано, в мануале запрещено выделять более 1МБ памяти!". Я правильно тебя понял?

> Библиотека на чем написана? Значит обгадился раст.

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

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

264. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от keydon (ok), 07-Янв-23, 23:29 
Об этом сишники писали 10 лет назад. Что ЯП не исправит человеческие ошибки, даже наоборот - либ нет, а пока сделают новые наклепают и новых ошибок (что и произошло).
В ответ им заявлялось что де раст то все исправит, якобы разработка на расте изначально безопаснее и намного проще и быстрее (поэтому все дедовские либы перепишут гораздо быстрее чем писали на си).
Чуда не случилось и теперь аргументы сишников 9 летней давности отправляют обратно сишникам и считают что это ок.
Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

268. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (90), 07-Янв-23, 23:57 
> В ответ им заявлялось что де раст то все исправит,

наглая ложь. И ты это понимаешь. Троллишь наверное. Всем понятно (и тебе тоже), что всё не исправит. Какой ЯП тебе исправит ошибку, где ты знаки "больше" "меньше" перепутал в логическом условии, где синтаксически могут быть оба знака? Или считал что-то из БД, а потом не вычел это из промежуточного результата, а сложил с ним? Или не проверил диапазон допустимых значений в поле полученного JSON и потом склеил из этого гов.а SQL-запрос, вместо всех предварительных проверок и использования переменных подстановки? В таких ошибках си и раст не отличаются друг от друга. Но печалька для тебя в том, что статистика показывает, что таких ошибок только процентов 30% в сишных программах. А остальных 70% в расте нет (если нет ансейфа), всё в си госталось.

> якобы разработка на расте изначально безопаснее и намного проще и быстрее

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

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

281. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от keydon (ok), 08-Янв-23, 00:46 
> наглая ложь. И ты это понимаешь. Троллишь наверное.

Нет

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

Так это и заявлялось противниками раста и лично мной. ЕМНИП даже пример
> знаки "больше" "меньше" перепутал в логическом условии

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

> Но печалька для тебя в том, что статистика показывает, что
> таких ошибок только процентов 30% в сишных программах. А остальных 70%
> в расте нет (если нет ансейфа), всё в си госталось.

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

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

Я такое уже слышал один в один, но в разное время про java (причем несколько раз в разное время), C#, js (nodejs, electron), очередную версию php, ruby. И конечно же по каждому из них были восторженные статьи от успешных компаний.

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

301. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (300), 08-Янв-23, 13:48 
> На что задавался вопрос какие конкретно проблемы, почему их нельзя решить в си и плюсах, почему нужно городить новый велосипед. В итоге выяснялось что решить в плюсах с помощью линтеров и либ можно почти все

Так почему так и не решили?

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

369. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от keydon (ok), 11-Янв-23, 12:47 
Так в основном и решили.
Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от kai3341 (ok), 07-Янв-23, 02:14 
> Ожидаемое поведение, в документации все описано.

Дополню. Запросы со слишком большим телом почикает nginx. Расходимся

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

75. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (228), 07-Янв-23, 02:34 
Почикает нгиннкс на С
Ответить | Правка | Наверх | Cообщить модератору

160. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Sw00p aka Jerom (?), 07-Янв-23, 09:13 
а че с чанками делать и крывыми размерами контента в заголовках?
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

145. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от MaleDog (?), 07-Янв-23, 04:07 
Я бы сказал безмозглое поведение - выделять оперативную память под запрос целиком на основе "Content-Length". Рустоманы так упоролись на том чтобы всем доказать "безопасность работы с памятью", что их поделие заболело детскими болячками Apache. Так скоро LOIC опять станет актуален.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

149. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от MaleDog (?), 07-Янв-23, 04:15 
Еще поди можно так:
- кидаем много запросов с небольшим Content-Length, но с телом усеченным до нуля и одного байта.
- сервер выделяет под них память, но освобождает ее с лагом, так как ждет нужное количество байт которых нет.
Ответить | Правка | Наверх | Cообщить модератору

161. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Sw00p aka Jerom (?), 07-Янв-23, 09:15 
>так как ждет нужное количество байт которых нет.

в смысле? освобождает ровно столько сколько выделил

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

184. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от MaleDog (?), 07-Янв-23, 12:02 
Выделяет столько сколько сказали. Затем он по какому-то таймауту должен понять, что столько байт ему никто передавать столько не собирается. Думаю не меньше нескольких секунд. К примеру, открыл какой-нибудь бот 1000 соединений, в каждом попросил принять 10M, и ... добрый сервер выделил боту 10G оперативной памяти? А если столько нет? Да и затраты на выделение не нулевые. Допустим через секунду бот отвалился и все соединения сброшены, а память освобождена, но что мешает боту еще "медленной записью" заняться передавая эти 10M по паре байт в секунду, тогда и таймаут не сработает и у сервера 10G оперативки будут заняты на неопределенный срок.
Выделять под буфер нужно столько памяти, чтобы обработчик запроса успевал обрабатывать без задержек(к примеру парсер JSON успевал обработать ключ и привести его значение к нужному типу), а не помещать весь запрос в оперативную память, а потом обрабатывать.
Ответить | Правка | Наверх | Cообщить модератору

330. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (330), 08-Янв-23, 19:44 
> добрый сервер выделил боту 10G оперативной памяти? А если столько нет?

overcommit

> что мешает боту еще "медленной записью" заняться передавая эти 10M по паре байт в секунду

Лимит по времени на запрос

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

359. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от MaleDog (?), 10-Янв-23, 11:01 
Но при этом на "лимит времени" память будет занята. Притом атакующий затратит гораздо меньше ресурсов. Так ему нужна память только на заголовки одного запроса, а в качестве тела будет "мусор". Нет, так дела не делаются. Выделяем буфер на заголовки. Парсим проверяем. Далее либо буферизуем тело небольшим буфером передавая по частям обработчику, либо просто пробрасываем TCP-соединение ему - пусть сам разбирается.
Ответить | Правка | Наверх | Cообщить модератору

176. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 11:44 
В данном случае упоролись всё же Воины Борьбы Супротив Раста, раз и после нескольких десятков комментариев не понимают, что данная конкретная ошибка не имеет никакого отношения к возможностям языка программирования.
Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

245. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (245), 07-Янв-23, 19:40 
упоролись растоманы которые всегда утверждали, что раст решает все проблемы безопасности.
Ответить | Правка | Наверх | Cообщить модератору

250. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 07-Янв-23, 22:16 
Приведите доказательства, что растоманы утверждали, будто Rust решает ВСЕ проблемы безопасности. А не подмножество проблем, связанных с безопасностью работы с памятью и безопасностью типов.
Ответить | Правка | Наверх | Cообщить модератору

271. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от keydon (ok), 08-Янв-23, 00:04 
> Приведите доказательства, что растоманы утверждали, будто Rust решает ВСЕ проблемы безопасности.
> А не подмножество проблем, связанных с безопасностью работы с памятью и
> безопасностью типов.

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

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

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

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

283. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 08-Янв-23, 00:52 
Rust решает некоторые проблемы, но большие и очень важные. Линтерами на плюсах они не решаются в той мере, которой решаются растом. Как видите, это совсем не "тот же самый аргумент".

Поэтому и прошу привести подтверждения. Пока вы только привели свою интерпретацию слов растоманов, а самих исходных слов не привели.

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

267. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (267), 07-Янв-23, 23:40 
Так это специальная функция для чтения запроса целиком. Когда он заведомо небольшой. Если больше лимита - проверь и отдай HTTP 413 Payload Too Large. Лимит, разумеется, на усмотрение разработчика, а не автора библиотеки - а как еще?

Для чтения по кускам там есть функция aggregate(), и, внезапно, в мануале рекомендуется использовать именно её.

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

4. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +13 +/
Сообщение от Аноним (4), 06-Янв-23, 21:39 
Безопасность не поместилась в оперативную память
Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (228), 06-Янв-23, 21:54 
боров-чекер оказался слишком жирным боровым и не влез в оперативку
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Alladin (?), 06-Янв-23, 22:29 
борров чекер проверяется и работает на этапе компиляции в скомпилированном коде он потребляет 0, вы белину сьели?
Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (228), 06-Янв-23, 23:07 
Я знаю что это такое, просто мне слово нравится... боров
Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Dzen Python (ok), 06-Янв-23, 23:57 
Проверяльщик боровов, дядь. Который при компиляции бегает между каждым боровом и смотрит им...хм, пусть будет в пятачок, чтобы не залезли боровы и рылом дырок-уязвимостей не нарыл.
Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (228), 06-Янв-23, 23:16 
я может что-то не понимаю, но раст с кучей не умеет что ли работать? Если на этапе компиляции, то как он выполняет эти ваши боровы-чекеры с аллоцированной в рантайме памятью?
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

49. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 01:18 
Компилятор не проверяет, сколько именно памяти есть в системе - это не его задача. Он проверяет, чтобы висячие ссылки не появлялись, чтобы use-after-free не происходило. Конечно же Rust умеет работать с кучей, но он не всемогущ, как некоторые ошибочно полагают. В нём по-прежнему возможны разные ошибки (в том числе утечка или переполнение памяти). В чём же смысл тогда, кто-то может спросить? В том, что Rust предотвращает наиболее распространённые ошибки.
Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Проффесорemail (?), 07-Янв-23, 01:45 
... способствует программисту потерять бдительность
Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Прохожий (??), 07-Янв-23, 01:48 
Не способствует, а освобождает программиста от слежения за определённым классом ошибок, позволяя ему сосредотачиваться на других вещах, более полезных и продуктивных.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Проффесорemail (?), 07-Янв-23, 01:55 
Способствует. Более того: создает впечатление у новичков что программирование - это очень просто.
Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 02:11 
Скажем так, у слабых разумом такое может случиться. Но мы ж о нормальных, правда?

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

Можно выразить надежду, что со временем новичок научится память освобождать. Но практика, увы, показывает иную статистику. Даже профессионалы высочайшего класса допускают подобные ошибки. Потому что все люди ошибаются. Так зачем позволять людям плодить ошибки, если можно от них оградиться? В чём смысл продолжать использовать такие языки, которые содержат архитектурные изьяны с рождения? Ладно, для обучения - ещё куда ни шло. Но в серьёзных дорогих проектах - зачем?

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

121. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:12 
Какой же ты тупой. Это не архитектурный изъян. Такими словами можно сказать интелам и амд с ARM -- почему вы на уровне ядер и конвеера кода позволяете обращаться не туда?
Ответить | Правка | Наверх | Cообщить модератору

134. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 03:41 
> Это не архитектурный изъян.

Отсутствие возможности контролировать работу с памятью, когда тебе это нужно - это изьян. Си не предоставляет таких возможностей на уровне языка. Поэтому он ущербный по современным меркам язык программирования. Плюсы - предоставляют, но они стали настолько сложными, и с таким количеством UB, что пользоваться ими стало просто опасно: иной раз можно наступить на такие грабли, который фиг потом найдёшь.

> Такими словами можно сказать интелам и амд с ARM -- почему вы на уровне ядер и конвеера кода позволяете обращаться не туда?

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

> Какой же ты тупой.

Ты ни в зуб ногой о современных способах разработки ПО, а тупой - я. Говорю же, ты забавен. :)

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

237. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (228), 07-Янв-23, 17:11 
> Отсутствие возможности контролировать работу с памятью, когда тебе это нужно - это изьян

what? В Си контроллировать память можно когда угодно и как угодно? Про какой изъян ты бредишь?

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

123. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:15 
Так таким значит надо писать на Java, Go, Dart, C#, JS наконец с Питоном -- вы же бизнес-логику прикладную пишете? Или у вас комплекс называться системным языком, зачем лезете к железу близко, но при этом избегаете его? Это как девочки у вас в вебкамах -- на расстоянии только, а IRL Buttplug и единороги.
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

135. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 03:48 
> Так таким

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

> Java, Go, Dart, C#, JS наконец с Питоном --

Эти все языки придумали не от хорошей жизни. Люди осознали, что надо что-то делать с дыренями Си, и сложностью Плюсов.

> Или у вас комплекс называться системным языком, зачем лезете к железу близко, но при этом избегаете его

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

> Это как девочки у вас в вебкамах

Какие девочки, у кого у вас? Ты точно трезвый?

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

363. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Анимус (?), 10-Янв-23, 19:08 
Добывай огонь трением, мало ли, спички закончатся
Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

6. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (228), 06-Янв-23, 21:47 
> Rust
> выявлена особенность работы с памятью, которая может использоваться для инициирования отказа в обслуживании
> достаточно отправить специально оформленный HTTP-запрос

Ок, ясно

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

204. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +3 +/
Сообщение от Прохожий (??), 07-Янв-23, 13:14 
Не думаю, что тебе стало что-либо ясно. Но ок.
Ответить | Правка | Наверх | Cообщить модератору

7. Скрыто модератором  +2 +/
Сообщение от Аноним (228), 06-Янв-23, 21:49 
Ответить | Правка | Наверх | Cообщить модератору

24. Скрыто модератором  +6 +/
Сообщение от Аноним (24), 06-Янв-23, 23:22 
Ответить | Правка | Наверх | Cообщить модератору

36. Скрыто модератором  –1 +/
Сообщение от Аноним (36), 06-Янв-23, 23:41 
Ответить | Правка | Наверх | Cообщить модератору

47. Скрыто модератором  +2 +/
Сообщение от Аноним (47), 07-Янв-23, 00:39 
Ответить | Правка | Наверх | Cообщить модератору

231. Скрыто модератором  –1 +/
Сообщение от псевдонимус (?), 07-Янв-23, 16:25 
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

8. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от pashev.ru (?), 06-Янв-23, 21:51 
Всё правильно. Ещё со времён Юниксов и Си правильно. Программа или библиотечная функция должа делать ровно одну задачу и делать её хорошо. Проверка входящих параметров — это отдельная задача. Если она не нужна, зачем за неё платить? Это кстати, часть философии Раста.
Ответить | Правка | Наверх | Cообщить модератору

12. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –10 +/
Сообщение от Аноним (133), 06-Янв-23, 22:10 
Всё верно,товарищ.
Проверки выхода за границы массива - тоже отдельная задача.

Эту Unix/C  философию разгребаем уже 30 лет.

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

101. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –3 +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:53 
> Проверки выхода за границы массива - тоже отдельная задача.

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

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

132. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Аноним (133), 07-Янв-23, 03:31 
Тыкну тебя в единственный по-настоящему системный язык программирования. Он называется Zig.

Ближе к железу только чистый ассемблер.

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

В Debug все проверки есть. В ReleaseFast проверок выхода за границы нет. Можно же было сделать такое и в С (лет 15 назад)?

А в С++ только если .at() есть проверки, в [] проверок нет.


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

162. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –3 +/
Сообщение от Вы забыли заполнить поле Name (?), 07-Янв-23, 09:16 
> Можно же было сделать такое и в С (лет 15 назад)?

Это уже давно есть. Открой для себя санитайзеры наконец.

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

206. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Прохожий (??), 07-Янв-23, 13:19 
Ты понимаешь разницу между специализированным ПО (которое, несмотря на все усилия, не в состоянии выловить все ошибки)  и архитектурными особенностями языка программирования, не дающими тебе совершать такие ошибки априори? Это был риторический вопрос, потому что из твоего комментария и так всё понятно.
Ответить | Правка | Наверх | Cообщить модератору

262. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Вы забыли заполнить поле Name (?), 07-Янв-23, 23:23 
> Ты понимаешь разницу между специализированным ПО

А ты понимаешь, что компилятор раста - это тоже специализированное ПО?

> которое, несмотря на все усилия, не
> в состоянии выловить все ошибки

А компилятор раста способен выловить все ошибки? Может санитайзеры и фазинг не нужен?

> Это был риторический вопрос

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

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

150. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +3 +/
Сообщение от Прохожий (??), 07-Янв-23, 04:20 
> Но раст не дотягивает до крестов.

Чего не хватает Rust, о гуру системного программирования?

> а не какие-то чистилки мусора, виртуалки, обслуживалки

В Rust всего этого нет. Сюрприз?

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

277. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Вы забыли заполнить поле Name (?), 08-Янв-23, 00:31 
>> Но раст не дотягивает до крестов.
> Чего не хватает Rust, о гуру системного программирования?

* Прибитость гвоздями к LLVM
* Обработки ошибок аллокации памяти
* Float-free libcore
* Работа без cargo
* Работа без стандартной либы
* Работа с динамически разделяемыми билиотеками
* Стабильного ABI и внятного версионирования


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

280. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Andrewpotam (?), 08-Янв-23, 00:46 
> * Прибитость гвоздями к LLVM

Cranelift

> * Обработки ошибок аллокации памяти

set_alloc_error_hook

> * Float-free libcore

зачем?
> * Работа без cargo

есть
> * Работа без стандартной либы

есть
> * Работа с динамически разделяемыми билиотеками

можно использовать C ABI, идет работа над нормальным ABI

> * Стабильного ABI и внятного версионирования

опять же, работа над ABI идет, что не так с версионированием? По моему намного лучше чем в C/C++

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

285. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Вы забыли заполнить поле Name (?), 08-Янв-23, 01:23 
>> * Прибитость гвоздями к LLVM
> Cranelift

Судя по описанию это еще сырой проект и нацелен в первую очередь на WASM?

>> * Обработки ошибок аллокации памяти

Это nightly-only experimental API. К тому же хочется какой-то реальный пример с этим увидеть. А так обычно все просто сводится к панике.

>> * Float-free libcore
> зачем?

https://github.com/rust-lang/rfcs/issues/1364

>> * Стабильного ABI и внятного версионирования
> опять же, работа над ABI идет, что не так с версионированием? По
> моему намного лучше чем в C/C++

У С++ есть стандарт. Код переписывают в соответствии со стандартами, которые выходят не так часто.

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

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

364. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Анимус (?), 10-Янв-23, 19:15 
Ты бы не позорился. У Раст так же стандарты выходят раз в три года.
Ответить | Правка | Наверх | Cообщить модератору

366. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Вы забыли заполнить поле Name (?), 10-Янв-23, 21:34 
> Ты бы не позорился. У Раст так же стандарты выходят раз в
> три года.

Ссылкой на стандарт поделишься?

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

42. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Dzen Python (ok), 06-Янв-23, 23:48 
Так если подумать и реализовано неправильно.
Если заведомо нет проверок на длину сырых (задача обработки и формирования буфера ДОКУМЕНТИРОВАНО возложена на приложение, вызывающее функцию) данных, значит функция просто обязана обрезать данные по внутреннему буферу, беря первые MAX_BUF_SIZE байт, остальное отбрасывая.

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

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

52. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +3 +/
Сообщение от Прохожий (??), 07-Янв-23, 01:39 
А если не только подумать, тыкая пальчиком в небо, а ещё почитать доку, например? Понимаю, некоторым питонистам это слишком тяжело, и я, наверное, многого хочу, но всё же. Вот же, несколько раз уже выдержку из стандарта приводили: "Checking the Content-Length is a possibility, but it is not strictly mandated to be present."

> Если заведомо нет проверок на длину сырых ... данных, значит функция просто обязана обрезать данные по внутреннему буферу, беря первые MAX_BUF_SIZE байт, остальное отбрасывая.

И каким должен быть этот внутренний буфер, уважаемый эксперт?

> Т.е. так и запишем

Очередной Воин Супротив Раста сел в лужу.

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

69. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Аноним (228), 07-Янв-23, 02:15 
В стандартах на протоколы не пишут, что можно делать use-after-free, что память должна течь и тп. Дак какие претензии к сишника? Или это другое?
Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Прохожий (??), 07-Янв-23, 02:28 
> В стандартах на протоколы не пишут, что можно делать use-after-free, что память должна течь и тп. Дак какие претензии к сишника? Или это другое?

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

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

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

87. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (72), 07-Янв-23, 02:42 
Претензии к растоманам, питонистам и JS/TypeScript-ам (не всем!) простые - они карго-культисты, которые делают сумасшедшие вещи только потому, что какой-то сумасшедший либо за них решил, дибо им порекомендовал так делать.
Ответить | Правка | Наверх | Cообщить модератору

106. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Прохожий (??), 07-Янв-23, 02:56 
>  они карго-культисты, которые делают сумасшедшие вещи только потому, что какой-то сумасшедший либо за них решил, дибо им порекомендовал так делать.

Какой-то поток сознания, не распарсил, сорри.

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

117. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:09 
свайпай дальше
Ответить | Правка | Наверх | Cообщить модератору

178. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 11:49 
Предлагаешь, каждую вспышку больного сознания комментировать? Сорри, это не ко мне.
Ответить | Правка | Наверх | Cообщить модератору

246. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Аноним (245), 07-Янв-23, 19:46 
дебилизм какой-то, давайте напишем в документации ядра линукс, что хакеры не должны использовать дыры для целей порочащих безопасность и ядро автоматически станет безопасным. а от сбоев памяти защититься всюду ECC.
Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

251. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 07-Янв-23, 22:24 
Функция выделяет памяти столько, сколько её попросили. Никаких UB при этом нет. В чем дебилизм- то?
Ответить | Правка | Наверх | Cообщить модератору

278. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (90), 08-Янв-23, 00:36 
Там написали, что ты не должен это выставлять наружу, в недоверенное окружение. Т.е. если ты аналогии про ядро кидаешь, то это не должно быть системным вызовом ядра для программ. Т.е., есть какой-то небезопасный, но универсальный механизм (молоток, которым можно гвоздь забить, а можно и голову пробить). Им можно пользоваться, как выше уже кто-то приводил пример, и в ядре для смарт-часов и в кластере из топ-500, т.е. условия эксплуатации разные. Наружу из ядра ты должен выставить другие вызовы, а не этот внутренний механизм. Этот механизм не может и не должен знать что творится снаружи и параметры этого "снаружи", это знают и проверяют клиенты этого механизма, т.е. другие вызовы ядра. А тут кто-то взял и написал прокси-сискол без проверок, который, скажем, условно, сквозным образом позволяет из юзерспейс программ читать любую страницу памяти в системе, хотя в документации написано что так делать нельзя, он не для этого предназначен. Этот внутренний механизм нужен многим другим сисколам. Большинство работает с ним правильно, согласно документации, а как появились 2-3 ленивых паршивых овцы - механизм стал нехорошим.
Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

9. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Alladin (?), 06-Янв-23, 21:53 
как же тупо, тупо никаких ограничений на выделение по "Content-Length"...
Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (29), 06-Янв-23, 23:28 
> как же тупо, тупо никаких ограничений на выделение по "Content-Length"...

И каким должно быть универсальное ограничение на выделение памяти для универсальной библиотеки?


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

31. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (228), 06-Янв-23, 23:33 
Очевидно, так как растоманы решили - чтоб отказ в обслуживании.
Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (44), 06-Янв-23, 23:59 
> Очевидно, так как растоманы решили - чтоб отказ в обслуживании.

Очевидно, открыта перепись Ыкспердов опеннета.
Правда, Ыксперды не знали (а так как дальше заголовка не читали - и не смогли узнать), что Content-Length - "not strictly mandated to be present."

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

46. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Alladin (?), 07-Янв-23, 00:37 
я и сам никогда не ориентировался на content-length, прислушивался но не ориентировался
Ответить | Правка | Наверх | Cообщить модератору

80. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Аноним (72), 07-Янв-23, 02:37 
Очевидно: библиотека должна посмотреть размер свободной памяти на машине, помножить на коэффициент нехило меньше 1 (напр. 0.25), далее помножить на (1. - 0.005 + random(0.01)), и такое ограничение и выставить.
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

93. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (330), 07-Янв-23, 02:46 
А что если на машине 64гб рам, а в слайсе сигруппы приложению выделили всего 256мб рам?
Ответить | Правка | Наверх | Cообщить модератору

99. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (72), 07-Янв-23, 02:52 
а приложение в этой группе, когда дёрнет API, увидит, что у неё доступно для выделения 64 гига?
Ответить | Правка | Наверх | Cообщить модератору

136. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +3 +/
Сообщение от Аноним (133), 07-Янв-23, 03:49 
Какая нахрен разница, в С / libc / Linux нет реального выделения памяти. Выделяй на выделяй всё равно получишь...

Выделить можно всю память + swap. На каждый процесс:)))

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

297. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (297), 08-Янв-23, 13:17 
Адекватные люди отключают оверкоммит. И тут же выясняется, что говно и линукс и его экосистема (бочка мёда с ложкой говна есть бочка говна), программы на нём памяти жрут на порядки больше, чем на винде, и фиксить это никто не будет, потому что "у кого нет денег на железо, тот пусть пользуется софтом для быдла, а мы, илитка, можем себе позволить жрущий софт".
Ответить | Правка | Наверх | Cообщить модератору

190. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Омномним (?), 07-Янв-23, 12:27 
Очевидно: чтение реквеста должно быть блочным, а не "запихать всё в память и отдать вызывающему".
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

197. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 12:57 
Ты про такой протокол, как UDP и на нем основанных слышал? Знаешь, как там всё работает?
Ответить | Правка | Наверх | Cообщить модератору

243. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (228), 07-Янв-23, 18:29 
Дед, ты таблетки забыл принять на ночь? Что ты, блин, несешь, старый идиот?
Ты для начала хотя бы попробуй написать простейший UDP-сервер, к-й принимает пакет по сети, дак вот сразу перестанешь такой бред нести про UDP.

По твоей логике, я должен потоковое видео, льющеяся по UDP сохранять в буфер полностью? o_O Ты дурак? Что ты тут кичишься знаниями UDP, хотя сам в этом нихера не понимаешь. Знаем мы как UDP работает, и даже софт, использующий его пишем. А вот ты видимо нет, раз приводишь его тут в пример в контексе копирования ответ в мега-огромный буфер без проверки.

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

299. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (297), 08-Янв-23, 13:29 
Если оно по HTTP - то да. HTTP/3 включает в себя свой TCP поверх UDP. Протоколы, основанные на TCP, не занимаются обработкой потери и перетасовкой пакетов, за них это должен делать TCP-слой. HTTP/1 и HTTP/2 и TLS основаны на TCP, поэтому обработка потери пакетов не есть зона ответственности приложения, использующего эти протоколы. HTTP/3 есть прозрачная замена для HTTP/2 и HTTP,  добавление которой в приложение заключа5тся в обновлении версии библиотеки и, возможно, включении возможности.

Поэтшму гнать потоковое видео по HTTP - плохая идея. Для этого есть RTP и более новые протоколы, вроде https://www.haivision.com/products/srt-secure-reliable-trans.../ и https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp... .

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

244. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (228), 07-Янв-23, 19:22 
И вообще, дед, причем тут UDP или TCP? Это нижележащий уровень, транспортные протоколы. Их задача - доставить тебе в приложение (идентифицируемое по номеру порта) payload, всё. Какая разница как тебе их доставили, через TCP или UDP? Ну вот что ты так бредишь то, зачем ты так позоришься? Выпей кефиру на ночь, или что вы там злобные стариканы пьёте, и ложись уже спать.
Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

238. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Анонн (?), 07-Янв-23, 17:16 
Добавить рандом в либу... И привязать его к параметру окружения...
Да ты просто злой гений! Пусть эти зaсрaнцы попробуют найти почему оно иногда не работает!
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

296. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (297), 08-Янв-23, 13:13 
Документацию читать надо, а ошибки - писать в лог вместе с причинами. Рандом нужен для того, чтобы удаленные атакующие не могли определить количество свободной памяти на машине в данном окне по времени.
Ответить | Правка | Наверх | Cообщить модератору

198. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от MaleDog (?), 07-Янв-23, 12:58 
Э-э. Выделить небольшой буфер на проверку заголовков. Передать их обработчику, чтобы тот авторизовал, проверил и сам выделил нужное количество оперативы. Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнению буфера или даже раньше передавать их обработчику. Что он с ними будет делать уже его проблема, главное буфер тут нужен чтобы избежать задержек. Но точно не пытаться считать весь запрос в оперативку.
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

208. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от MaleDog (?), 07-Янв-23, 13:33 
Ну а chunked-запрос - это извращение. Насколько я помню изначально chunked был только для ответа сервера. Но потом реализовали и для запроса. При этом у chunked отсутствует заголовок Content-Length. Сколько читать указано перед чанком. Наиболее безопасно выделять буфер непосредственно перед чтением чанка проверив предварительно, что тот не слишком длинный, так как стандартом не оговорены ни максимальная длинна, ни то что чанки должны быть одинаковой длинны.
В любом случае chunked это не про быстродействие, это скорее про "бедность" передающего на оперативку. Так что нет никаких причин быстро его на сервере обрабатывать помещая весь запрос в оперативку.
Ответить | Правка | Наверх | Cообщить модератору

339. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 08-Янв-23, 20:47 
Почему извращение?
Допустим мы хотим залить контент заранее не известного объёма.
Какую-нибудь телеметрию например, которая идёт потоком, но лить хотим по HTTP.
Why not?
Ответить | Правка | Наверх | Cообщить модератору

367. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от MaleDog (?), 10-Янв-23, 22:28 
Потому, что заранее не известно когда закончится запрос. Теоретически я хоть целый день могу развлекать сервер одним запросом(насколько хватит терпения у проектировавшего сервер). Кроме того ему нужно будет решать вопросы с увеличивающимся или уменьшающимся буфером или склеиванием, ведь максимальная длинна чанка не известна заранее и нигде не сказано что они могут быть одной и той же длинны. и эта проблема умножается на два или на три, если со стороны сервера или клиента есть прокси. Лучше уж тогда TCP и бинарный протокол, где все, включая длинну сообщения будет заранее оговорено. Не спорю то же самое можно оговорить и в заголовке HTTP, но зачем? Учитывая что выбрав бинарь вы минимум вдвое сэкономите на длинне сообщения.
Ответить | Правка | Наверх | Cообщить модератору

368. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от MaleDog (?), 10-Янв-23, 22:56 
Тем более, что часто люди просто не думают. Вот к примеру реальный случай. Мне предлагают использвать chunked HTTP(даже не HTTPS). Есть некий девайс на esp32(520 KB RAM), в нем есть буфер EEPROM на 128KB. Разработчик говорит: я не знаю сколько у меня записей будет потому не могу сказать заранее Content-Length. Но в данном случае это чистое лукавство. Судя по коду у него две третьих оперативы всегда свободны. Т. е. запрос содержащий если не половину, то четверть EEPROM можно спокойно затолкать в оперативку даже в формате JSON и посчитать его длинну.В 4-5 запросов можно передать все данные. Но нет, нужно же осложнить жизнь разработчику сервера и передать все в одном chunked, и пусть этот разработчик продумает все возможные способы атаки, где левый долбящийся бот может вызвать отказ.
Если что, реальный случай. Есть некая небольшая компания занимающаяся IOT, у них есть сайт с demo-кабинетом. Меня пригласили оценить и возможно сделать что-то подобное(я универсал, "сам пою, сам снимаю, сам по морде получаю"). Зашел в кабинет - красивенько. Ну там схема квартиры, и один датчик. Вижу кнопку "отчет" и datetimepicker. Пробую отчет за день - нормально. За неделю - сервер слегка задумался. За месяц - сервер упал. Да так что даже статус не возвращает. Вместе с сервером упал и сайт компашки. Вот специально попросил заказчика проверитть, что не меня забанили, а именно сервер упал. Да не может быть думаю. Через полчаса, когда кто-то видимо перезагрузил сервер повторяю операцию - сервер еще на полчаса в отрубе. Вот что бывает когда кто-то не продумал все возможные варианты использования его поделия.
Ответить | Правка | Наверх | Cообщить модератору

371. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 11-Янв-23, 15:07 
Про read timeout что-нибудь слышал?
Ну и да - чанк не обязательно читать целиком, снова растожаберство какое-то в голове :)
Ответить | Правка | К родителю #367 | Наверх | Cообщить модератору

372. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от MaleDog (?), 12-Янв-23, 23:15 
Тут вся суть в том. Как отличить добросовестное использование от недобросовестного. Если это обычный http запрос с Content-Length, то довольно просто выделить буфер и установить таймаут. Если это Chunked, то придется устанавливать эти правила для каждого чанка. Что гораздо затратнее.
Ответить | Правка | Наверх | Cообщить модератору

373. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 13-Янв-23, 00:45 
Чичиго?
Ответить | Правка | Наверх | Cообщить модератору

248. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (248), 07-Янв-23, 21:27 
> Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнению

Э-э, там, в той самой библиотеке, для этого есть aggregate - читает в буфер, размер буфера устанавливается по вкусу. Кто ж виноват, что нельзя никак заставить использовать именно это API?

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

241. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Аноним (241), 07-Янв-23, 18:00 
Можно посмотреть как эту проблему решили высокооплачиваемые программисты из Sun.
https://docs.oracle.com/javase/7/docs/api/java/nio/file/File...)

OutOfMemoryError - if an array of the required size cannot be allocated, for example the file is larger that 2GB

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

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

307. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (307), 08-Янв-23, 14:50 
и вообще смог понять что за проблема
Ответить | Правка | Наверх | Cообщить модератору

103. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:55 
Это норм. Просто макакинг-девелопмент
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

20. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (20), 06-Янв-23, 23:11 
Чудесное определение — "особенность работы с памятью". Запомню.
Ответить | Правка | Наверх | Cообщить модератору

55. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Проффесорemail (?), 07-Янв-23, 01:48 
ой как интересно получилось
Ответить | Правка | Наверх | Cообщить модератору

62. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Прохожий (??), 07-Янв-23, 01:59 
Ой какой длинный список получается
Ответить | Правка | Наверх | Cообщить модератору

351. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (351), 09-Янв-23, 15:11 
"Программы на Rust текут из-за особенности работы с памятью."
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

355. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (355), 09-Янв-23, 20:20 
> "Программы на Rust текут из-за особенности работы с памятью."

Нет, зато опеннетные экспертусы-по-всему не владеют даже элементарной терминологией.

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

21. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (228), 06-Янв-23, 23:12 
Сишник забывает очистить память в указателе
растоман: диды писали, надо переписать на раст

растоман: забывает проверить входные данные и вообще весь ответ целиком копирует в буфер.
опять растоман: это задокументировано!

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

26. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +5 +/
Сообщение от Аноним (29), 06-Янв-23, 23:25 
> растоман: забывает проверить входные данные и вообще весь ответ целиком копирует в буфер.

Питонист, расскажи куда его еще копировать, заодно выдай, каким должен быть "разумный" ограничитель по дефолту.
> опять растоман: это задокументировано!

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


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

28. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (228), 06-Янв-23, 23:27 
UB в ANSI C тоже задокументировано.
Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (248), 07-Янв-23, 00:00 
>> Checking the Content-Length is a possibility, but it is not strictly mandated to be present.
> UB в ANSI C тоже задокументировано.

А в огороде бузина.

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

107. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:57 
Да нее, тут опять сишники виноваты
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

211. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 13:44 
Не тут. Но виноваты, конечно.
Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Аноним (25), 06-Янв-23, 23:16 
Помнится си критиковали за то что программисту нужно слишком много думать и знать и о многом заботиться. И что раст сейчас придёт и возьмёт всё на себя. Но чуда не случилось, зато мелкософт и гугл (текущих владельцев раста) захватили ещё немного влияния.
Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +3 +/
Сообщение от Аноним (30), 06-Янв-23, 23:32 
>>  Примечательно, что указанное поведение явно описано в документации, в которой рекомендуется выполнять отдельные проверки размера
> И что раст сейчас придёт и возьмёт всё на себя. Но чуда не случилось

Очередная перепись не читающих дальше заголовка?

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

164. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Аноним (25), 07-Янв-23, 09:51 
Это уже новая риторика. Изначально было "раст все порешает" и "программисты не будут совершать ошибки".
Потом было "мы ещё сырые, но вот ещё чуток подпилим".
Сейчас вот "раст не виноват, это всё...".
Собственно всё это мы уже проходили с джавой, а единственный результат который получили это зависимость от корпораций (в данном случае гугель и мелкософт).
Ответить | Правка | Наверх | Cообщить модератору

177. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +3 +/
Сообщение от Аноним (300), 07-Янв-23, 11:48 
> Изначально было "раст все порешает" и "программисты не будут совершать ошибки"

Где это заявлялось?

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

258. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (90), 07-Янв-23, 23:01 
> Это уже новая риторика. Изначально было "раст все порешает" и "программисты не будут совершать ошибки".

Ой звездуны-ы-ы-ы... Вкладывать свои слова и мысли в уста оппонента и потом с пафосом опровергать их - это уже дно, второе, после первого, в которое постучались снизу. Раст порешает только (примерно-условно) 70% проблем, определенные ошибки работы с памятью, да и то, с одним условием - никакого unsafe-кода. Даже взаимодействие с твоим "божественным си" через (ансейфовские) врапперы хоть и локализует проблему, но сводит часть работы на нет. Ну даже ложка дерь... дегтя бочку меда портит. Тем больше стимул заменять всё на мёд и не взаимодействовать с дёгтем. Просто дёготь пока везде вокруг, но это не повод сложить руки и отказаться от прогресса. Всё новое пиши на мёде, старое на дёгте, если еще хоть немного сопровождаемо, тяни дальше.

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

38. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (38), 06-Янв-23, 23:42 
У Си уязвимости, а у Раста ОСОБЕННОСТИ работы с памятью, понимать надо.
Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Dzen Python (ok), 06-Янв-23, 23:44 
Говори толерантнее, иначе к тебе приедет айнзац-команда и до реанимации будет учить тебя политкорректности: у раста не особенности, у раста ЗАДОКУМЕНТИРОВАННОЕ ПОВЕДЕНИЕ.
Ответить | Правка | Наверх | Cообщить модератору

61. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 01:57 
Эх, видимо, рано я порадовался за питониста. Эй, питонист. Не у Раста, а в стандарте такое поведение. Надеюсь, ты понимаешь разницу между стандартом и языком программирования? Или я опять слишком многого прошу?
Ответить | Правка | Наверх | Cообщить модератору

112. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:01 
Способность обращаться по любому адресу памяти это нормальное поведение кода, исполняющегося на процессоре.
Ответить | Правка | Наверх | Cообщить модератору

122. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 03:13 
С точки зрения процессора - да, нормальное. А с точки зрения программиста, который в здравом уме находится - нет, не всегда это нормально, и часто это надо пресекать.
Ответить | Правка | Наверх | Cообщить модератору

259. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (90), 07-Янв-23, 23:12 
Не любого кода. Подавляющая часть программ (состоящих из данных и кода) категорически не должна иметь доступ _по любому_ адресу памяти. С точки зрения современной (относительно) универсальной (многопроцессной, многопользовательской) операционной системы. Ну, просто как пример, ты не должен обращаться к еще не выделенной памяти. Или к уже освобожденной. Или выделенной другой программе, если у них специально разделяемую область не создал, с казино и шлю... с доступом примитивы синхронизации (семафоры и т.п.). В своих наколенных ОС-поделках воруй память наперегонки из разных программ как тебе вздумается. Т.е. подозреваю кроме как под DOS, используя хитрые "хакирские" трюки, ты ничего не писал.
Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

276. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (228), 08-Янв-23, 00:27 
> Не любого кода

Тебе сказали - работающего на процессоре, а не под ОС, работающей на процессоре.

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

279. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (228), 08-Янв-23, 00:42 
> Ну, просто как пример, ты не должен обращаться к еще не выделенной памяти

кем не выделенной, куда не выделенной? Вот есть у меня ядро, оно стартует, и... кто и как мне должен память выделить? MINIX3 в IntelME что ли?

> Или к уже освобожденной

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

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

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

169. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от раст переусложнён (?), 07-Янв-23, 11:12 
>ЗАДОКУМЕНТИРОВАННОЕ

от слова "док", как в док-станции?

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

179. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 11:53 
Тебе далеко пока до Евгения Вагановича. Тренируйся ещё.
Ответить | Правка | Наверх | Cообщить модератору

252. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от freecoder (ok), 07-Янв-23, 22:32 
Уязвимость, но не в Rust и даже не в библиотеке Hyper, а в тех серверах, которые реализовали ошибочную логику.
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

270. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (228), 08-Янв-23, 00:01 
В Си тоже нету уязвимостей, они могут встречаться в софте на нем написаном
Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +6 +/
Сообщение от Анонн (?), 07-Янв-23, 00:57 
Мда, это даже смешно.
Это поведение не только записано в доке, там даже пример есть с комментом "// Just to protect ourselves from a malicious response"

И из всех проектов которые использую hyper нашлась тройка особенных которые на это забили, причем один из которых - участник web-frameworks-benchmark - которые известны "победа любой ценой".

Просто для "оценки значимости" этих проектов - у хипера 68кк загрузок и примерно 60-100к ежедневно.
Внимания заслуживает наверное только axum у которого в 10 раз меньше общих загрузок и где-то в 3-5 раз меньше ежедневных. Потому что у Сальво же - 1600 ежедневно (да, просто 1600, без к), а у кондуита - вообще в пике 45 в день.
Т.е. кому-то было не лень найти эти проекты и написать об УЖАСНОЙ УЯЗВИМОСТИ!!!111

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

196. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (-), 07-Янв-23, 12:49 
Кондуит конечный продукт, естественно у него будет меньше загрузок с сайта «библиотек», странно сравнивать.
Ответить | Правка | Наверх | Cообщить модератору

141. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (-), 07-Янв-23, 04:04 
> на языке Rust, выявлена
> особенность работы с памятью

Да ну ладно?!

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

147. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Прохожий (??), 07-Янв-23, 04:12 
Ещё один подражатель Евгения Вагановича. Такая популярная на Опеннете личность, кто бы мог подумать.
Ответить | Правка | Наверх | Cообщить модератору

156. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (-), 07-Янв-23, 06:05 
> Ещё один подражатель Евгения Вагановича. Такая популярная на Опеннете личность, кто бы
> мог подумать.

"Но как, Холмс?!"

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

232. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от псевдонимус (?), 07-Янв-23, 16:31 
Галустян,  залогинься.
Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

143. Скрыто модератором  –1 +/
Сообщение от Аноним (138), 07-Янв-23, 04:06 
Ответить | Правка | Наверх | Cообщить модератору

146. Скрыто модератором  +2 +/
Сообщение от Прохожий (??), 07-Янв-23, 04:12 
Ответить | Правка | Наверх | Cообщить модератору

260. Скрыто модератором  +/
Сообщение от Аноним (90), 07-Янв-23, 23:19 
Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

165. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Анонимусс (?), 07-Янв-23, 10:38 
Вот она победа раста над древней сишкой!
Растоманы накосячили с памятью и все лишь получили DoS, а не RCE-дырень с получением рута и тыреньем всех твоих данных.
Не зря его сделали, не зря его добавили в ядро!
Ответить | Правка | Наверх | Cообщить модератору

166. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от An (??), 07-Янв-23, 10:50 
Ну и развивали бы дальше свой победоносный redox. Нафига в сишный linux полезли?
Ответить | Правка | Наверх | Cообщить модератору

168. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Анонимусс (?), 07-Янв-23, 11:09 
Потому что это будет просто преступлением оставить линукс таким дырявым какой он сейчас!
Ответить | Правка | Наверх | Cообщить модератору

173. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (173), 07-Янв-23, 11:36 
Да, просто за драйверами зашли. Сейчас с ними и уйдут обратно.
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

187. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 12:17 
Никто уже никуда не уйдёт, не переживай. Учить язык придётся. Хотя для некоторых это может оказаться и непосильной задачей.
Ответить | Правка | Наверх | Cообщить модератору

294. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (294), 08-Янв-23, 11:45 
Но дрова то на небезопасном Си, все равно их переписывать с нуля надо
Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

186. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Прохожий (??), 07-Янв-23, 12:15 
Redox - это почти домашний проект, просто чтобы убедиться, на данном языке можно писать системный софт.
Полезли в сишный Линукс, потому что последний стал очень распространённым, что означает, что каждая ошибка программиста очень дорого обходится в итоге конечным пользователям. И с этим надо что-то делать. Раст оказался как нельзя кстати.
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

174. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (173), 07-Янв-23, 11:37 
А можно написать еще хотя бы одну библиотеку для работы с HTTP, а то что-то свет клином столкнулся с этим Хайпером.
Ответить | Правка | Наверх | Cообщить модератору

181. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Омномним (?), 07-Янв-23, 11:54 
Бугагашно, чанк по частям мегабезопастные кодеры читать не научились? :D
Ответить | Правка | Наверх | Cообщить модератору

183. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Омномним (?), 07-Янв-23, 11:55 
(так-то вообще школьная ошибка, чтение из сети по заданному размеру без лимитов...)
Ответить | Правка | Наверх | Cообщить модератору

201. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Прохожий (??), 07-Янв-23, 13:03 
О великий эксперт. А где ты потом собирать будешь эти чанки? Почитай на досуге про UDP, например.
Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

210. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (228), 07-Янв-23, 13:38 
Никогда не останавливайся на полпути, позорься до конца!

Ты хотя бы посмотри как чтение кусками из UDP реализовано в популярном софте. Боже, растоманы РЕАЛЬНО думают, что UDP весь(!!!) целиком(!!!) надо прочитать в мега-огромный-буфер  прям из сети?

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

212. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Прохожий (??), 07-Янв-23, 13:56 
Упоминание UDP - это была попытка намекнуть, что не все так просто, как сишники себе вообразили.

Заодно предлагаю тебе поразмыслить (понимаю, для сишников это сложная когнитивная задача, но ты хоть попытайся) , что в данном конкретном случае речь идёт об универсальной  БИБЛИОТЕКЕ, а не о конечном продукте, который, конечно, знает, что ему следует ожидать из сети, а что может игнорировать.

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

223. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Омномним (?), 07-Янв-23, 16:01 
Хорошее упоминание. Ты собрался весь поток UDP за неизвестный период в память тащить, или всё-таки будешь его "клиенту" отдавать, чтобы тот решал сам, что с ним делать?
Ответить | Правка | Наверх | Cообщить модератору

224. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Омномним (?), 07-Янв-23, 16:02 
Собственно об чём и речь. УНИВЕРСАМНАЯ либлиотека оказалась ни фига не универсальной, а заточенной только на очень специфичный вариант применения - когда всё в память помещается. Растожабаскриптерство - оно такое.
Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

266. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (90), 07-Янв-23, 23:35 
Если ты туда всунешь какой-то лимит на размер буфера она перестанет быть универсальной. На малинке с 2Г оперативы для кастомной программы там одни лимиты будут, для суперкомпа с терабайтом оперативы в защищенном периметре, где к нему не обращаются неавторизованные хосты и программы - другие лимиты. А так впендюришь ты 640KB и скажешь - "этого должно хватить на всё! Универсально!". Универсальность как раз в том, что её могут использовать по разному, под разные нужды. Проблема в том, что кто-то не прочел документацию и не проникся этой универсальностью создавая уже свой продукт. Тут уже от ЯП не зависит. И чего я бисер мечу перед вами...
Ответить | Правка | Наверх | Cообщить модератору

295. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 08-Янв-23, 11:56 
Ты в курсе, что лимит может быть конфигурируемым со стороны клиента?
Ответить | Правка | Наверх | Cообщить модератору

269. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (269), 07-Янв-23, 23:57 
> Собственно об чём и речь. УНИВЕРСАМНАЯ либлиотека оказалась ни фига не универсальной,
> а заточенной только на очень специфичный вариант применения - когда всё
> в память помещается. Растожабаскриптерство - оно такое.

https://docs.rs/hyper/latest/hyper/body/fn.aggregate.html
> Aggregate the data buffers from a body asynchronously.
> The returned impl Buf groups the Bufs from the HttpBody without copying them. This is ideal if you don’t require a contiguous buffer.

https://docs.rs/hyper/latest/hyper/body/trait.Buf.html
> fn remaining(&self) -> usize
> Returns the number of bytes between the current position and the end of the buffer

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

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

222. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Омномним (?), 07-Янв-23, 16:00 
Жаборастера видно издалека, да.
Собирать будет "клиентский" код - там, где ему надо. С лимитами и т.п.
Простая проблема мерзкого дизайна. Либа должна отдавать не весь контент целиком, если он большой, а его куски, наподобие read(), с предзаданной длиной. Тогда и чанки будут читаться кусочками, и сборка будет мягкой и шелковистой. Зачем например тащить в память весь гиговый файл, если его можно на диск кусками писать?
Ответить | Правка | К родителю #201 | Наверх | Cообщить модератору

225. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Омномним (?), 07-Янв-23, 16:04 
И чего?
У меня сейчас допустим есть асинхронная корутинная реализация HTTP на PHP.
Она вполне себе клиенту что хедеры, что контент в обе стороны отдаёт кусками - через эксплицитный запрос на чтение. Кусками читает с сокета, кусками парсит (попутно применяя лимиты на те же хедеры, чтобы многомегабайтный хедер не скушать), и кусками же отдаёт по readHeader() / readHeaders() / readContent(). Клиент сам решит, что делать с очередным куском - буферизовать или свалить куда-либо.
Ответить | Правка | К родителю #201 | Наверх | Cообщить модератору

226. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Омномним (?), 07-Янв-23, 16:11 
А для универсальности там же есть - readAllHeaders() / readFullContent(), первое читает с лимитом, второе - когда длина контента клиенту уже известна, и клиент хочет всё целиком. Внутри это просто обвязка к вышеупомянутым.
Ответить | Правка | Наверх | Cообщить модератору

247. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (248), 07-Янв-23, 21:21 
> Бугагашно, чанк по частям мегабезопастные кодеры читать не научились? :D

Бугагашно, читать дальше заголовка местные Воены Супротив Раста так и не научились?
https://docs.rs/hyper/latest/hyper/body/fn.aggregate.html


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

265. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (267), 07-Янв-23, 23:32 
А ты по ссылочке-то пробовал пройти?

This may require copying the data into a single buffer. If you don’t need a contiguous buffer, prefer the aggregate function.


С английского перевести, или сам осилишь буковки?

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

191. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +3 +/
Сообщение от анон (?), 07-Янв-23, 12:29 
Пациенты клиники Кащенко в комментах в полном сборе.

"Но вы же гаварили что в расте нет проблем а тут праблемка ихихихихихих" - пишут они на разный лад в новости про задокументированное поведение http библиотеки.

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

200. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –4 +/
Сообщение от Вы забыли заполнить поле Name (?), 07-Янв-23, 13:02 
Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано. А из какой клиники сами будете?
Ответить | Правка | Наверх | Cообщить модератору

202. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Прохожий (??), 07-Янв-23, 13:05 
>Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано

Ещё один сравниватель Си с реализацией конкретной библиотеки. Как-то много вас развелось. Подозрительно много.

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

286. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Вы забыли заполнить поле Name (?), 08-Янв-23, 01:24 
>>Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано
> Ещё один сравниватель Си с реализацией конкретной библиотеки. Как-то много вас развелось.
> Подозрительно много.

Подозрительно много тут только твоих комментариев.

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

203. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от анон (?), 07-Янв-23, 13:07 
Ты читать умеешь? Проблема в библиотеке ебтвм, можешь форкнуть и поправить если хочешь. Но больные люди видят ключевое слово "раст" и ну никак не могут сдержаться.
Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

205. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (205), 07-Янв-23, 13:16 
> можешь форкнуть и поправить если хочешь

Новаторство в борьбе с уязвимостями.

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

209. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Прохожий (??), 07-Янв-23, 13:36 
Очевидно, и читать, и писать он умеет. А вот с осмысливанием прочитанного у него явные проблемы, как и у 90 процентов здешних комментаторов.

Вы бы поберегли нервы, всё равно же ничего этим людям не докажете. Они очухаются только тогда, когда жизнь заставит. Но к тому времени уже может быть поздно.

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

256. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 07-Янв-23, 22:46 
Строго говоря, это не проблема библиотеки Hyper, это проблема тех нескольких серверов, которые её лениво используют. В Hyper есть возможность как читать все в один присест, так и читать кусками. На выбор вызывающей стороны. Просто кто-то сделал неверный выбор.
Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

340. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Омномним (?), 08-Янв-23, 20:49 
У чтения в один присест должны быть лимиты.
Потому что всем, кроме хрустоманов, очевидно, что доступная память - не резиновая.
Ответить | Правка | Наверх | Cообщить модератору

353. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 09-Янв-23, 15:27 
Еще скажите, что у обращения по индексу всегда должна быть проверка выхода за границы. Потому что размеры буфера не бесконечны.
Ответить | Правка | Наверх | Cообщить модератору

374. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 18-Янв-23, 10:44 
Только в случае, если индекс зависит от пользовательского ввода.
Проверять границы буфера во внутреннем обходном цикле - так себе затея :D
Ответить | Правка | Наверх | Cообщить модератору

375. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 20-Янв-23, 12:31 
В цикле и так будет проверка на каждом шаге условия достижения конца цикла. Чтобы проверку не дублировать ещё и при непосредственном доступе по индексу, и при этом не жертвовать безопасностью, лучше использовать итератор вместо прямого доступа.

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

376. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 20-Янв-23, 21:02 
Проверка на каждом шаге условия?
Ну удачки, чего.
Ответить | Правка | Наверх | Cообщить модератору

377. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 20-Янв-23, 21:13 
Есть допустим у меня кадр. 7680x4320.
Мне его надо вдоль и поперёк обработать, согласно пользовательскому вводу.

На каждом шаге проверять выход за пределы буфера? Итераторы?
Жабоскрипт и прочие расты ГМ, однако. В здравом уме - проверяется однократно до обработки.

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

378. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 21-Янв-23, 21:23 
Ваше предыдущее сообщение было про цикл. Как вы себе представляете цикл без проверки условия выхода?

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

379. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 22-Янв-23, 09:39 
Между проверкой условия выхода и проверкой границ есть небольшая разница, не?
Ответить | Правка | Наверх | Cообщить модератору

214. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (214), 07-Янв-23, 14:38 
Мы(пациенты) смеемся не с новости, а с ваших попыток оправдаться. Особенно смешно это читать после ваших набегов на темы вида "Уязвимость в коде на Си в проекте Х...", где каждый писал что-то в духе
>ряяя дырявая сишка, швятой хруст бы помог

хотя разрабы просто забыли поставить сравнение и патч выглядел в одну строчку. Пытался найти ссылку на эту тему, но наткнулся на другую:
https://www.opennet.me/opennews/art.shtml?num=56551

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

215. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от анон (?), 07-Янв-23, 14:46 
>Ваших попыток оправдаться

Понятно.
Этого пока рано выписывать.

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

216. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (214), 07-Янв-23, 14:51 
>Понятно.

А разве это не так?
Происходит жирный наброс в духе "Ха, самый безопастный язык не помог, растаманы слились"
И тут же десятки опрадвний на это сообщение:
>Ряяя вы ничего не понимаете, раст не виноват
>тупые сишники, ряяя
> пук-среньк, это библиотека виновата
> и т.д.

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

227. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +4 +/
Сообщение от Анонимусс (?), 07-Янв-23, 16:15 
Какие оправдания? Это (безуспешные) попытки объяснить недалеким, что вообще-то так оно и должно работать. Если в мануале написано что rm -rf удаляет папку и проверьте что вы туда передаете, чтобы не сжечь свой стул, то те кто это не делают ССЗБ.

Разве эти можно сравнить с оправданиями при разыменовании null или при очередном выходе за границы массива с получением рута? Хотя в последнем случае, оправдаться пытаються только самые клинические сишники...

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

230. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Аноним (214), 07-Янв-23, 16:23 
>Какие оправдания?

Которые ты написал...

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

255. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 07-Янв-23, 22:43 
Чтобы убедиться, что в том случае растоманы действительно были неправы (если они такое писали), нужно найти новость и понять, не вызывала ли подобная ошибка сравнения в С далее обращение к уже освобожденной памяти или к выходу за пределы буфера. Сама по себе логическая ошибка сравнения может быть допущена как в Rust, так и в С. Но важен также контекст и последствия, к которым приводит эта ошибка: возможно в Rust действительно просто не было бы смысла/возможности писать такой код, который бы привел к порче памяти из-за подобной логической ошибки.
Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

219. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (219), 07-Янв-23, 15:49 
А у тебя как всегда сишники виноваты.
Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

292. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (294), 08-Янв-23, 11:41 
> Пациенты клиники Кащенко в комментах в полном сборе.

Тут согласен, пациенты клиники Кащенко пишут, что чтобы избегать какой-то тип ошибок нужен новый язык

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

304. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (300), 08-Янв-23, 14:16 
То ли дело молиться, что всё порешают линтеры, санитайзеры, да прямые руки.
Ответить | Правка | Наверх | Cообщить модератору

314. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (314), 08-Янв-23, 16:01 
Толи дело написать язык, на котором ничего невозможно написать.
Ответить | Правка | Наверх | Cообщить модератору

217. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (217), 07-Янв-23, 14:55 
Хах растобезопасность снова превратилась в тыкву
Ответить | Правка | Наверх | Cообщить модератору

254. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 07-Янв-23, 22:37 
Безопасность Rust'а? Или безопасность Hyper? Или безопасность Axum, Salvo и conduit-hyper? Перечитайте новость внимательно.
Ответить | Правка | Наверх | Cообщить модератору

324. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 08-Янв-23, 17:23 
> Хах растобезопасность снова превратилась в тыкву

Какая именно безопасность? Боров-чекер перестал работать?

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

253. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 07-Янв-23, 22:35 
Кстати, новость написана правильно. А вот комментаторы неверно интерпретируют сказанное. Тут нет уязвимости в Rust, даже нет уязвимости в Hyper. Но есть уязвимость в нескольких проектах, построенных на Hyper.
Ответить | Правка | Наверх | Cообщить модератору

328. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от anonymous (??), 08-Янв-23, 18:21 
Ваш растопроект вылетел в DoS из-за непроверки входных данных? Знаете кто виноват? Нет, не Раст, который декларировал безопасность работы с аллокацией, и не Hyper, который не делает проверок входных данных, но только документирует это. Виноваты ВЫ - потому что доверились сказкам растоманов про безопасность кода и выключили голову, когда писали свой проект, опираясь на библиотеку, которая в перекладывает проверки на клиента.
Ответить | Правка | Наверх | Cообщить модератору

332. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 08-Янв-23, 20:09 
Rust и растоманы нигде не обещают избавления от логических ошибок. Те гарантии, которые давал Rust, он их не нарушил: никакой гонки не произошло, никто не вышел за пределы буфера, не обратился к неинициализированной памяти и пр. Остальное - это уже ваши додумки и домыслы тех, кто Rust и не видел вовсе, и даже дня на нем не программировал, судя по всему.
Ответить | Правка | Наверх | Cообщить модератору

354. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (294), 09-Янв-23, 16:12 
Прикол в том, что в Расте вероятность совершить логическую ошибку повышается из-за того, что даже простейший код раздувается до ненормальных размеров. Это не говоря уже о том, что приходится структурировать код не в угоду читабельности, а чтобы угодить компилятору. Ну и не стоит забывать про сумасшедший синтаксис
Ответить | Правка | Наверх | Cообщить модератору

356. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 09-Янв-23, 20:28 
Код раздувается из-за того, что развитая строгая типизация требует больше явных проверок и обработки всех веток на месте. Из-за этого же наоборот, вероятность совершить ошибку понижается.

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

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

357. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (294), 09-Янв-23, 20:33 
Я говорю о ЛОГИЧЕСКИХ ошибках
Ответить | Правка | Наверх | Cообщить модератору

361. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 10-Янв-23, 14:01 
Так я тоже о них говорю. Обработка не всех вариантов - в общем случае ведет к логическим ошибкам.


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

349. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (349), 09-Янв-23, 14:03 
+1. Причём "растаманить" на их неуклюжем языке в 2 раза сложнее и они это оправдывали повышенной безопасностью. Так накой мне лишний геморой, если всё равно раст дырявый?!
Даже С++ со смарт указателями стократ надёжнее.
Ответить | Правка | К родителю #328 | Наверх | Cообщить модератору

346. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (307), 09-Янв-23, 11:31 
Вызвать команду на загрузку всех данных в память и обвинять язык в том что память закончилась это какой-то особый способ идиотизма.

Вывод. Не верь сказкам растоманов и джаваманов о том что их языки безопасные. Пиши на ANSI C где даже элементарные арифметические операции продолжают неопределенное проведение.

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

360. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (228), 10-Янв-23, 12:37 
> элементарные арифметические операции продолжают неопределенное проведение

болобол

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

282. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (90), 08-Янв-23, 00:49 
Когда новость про ошибки в программах на расте не связаны с самим растом, у наСИльников особенно ярко и гулко полыхает. Что только подкидывает в копилку надежности и нужности раста: вот, очередная ошибка! ан нет, не переполнение буфера, не обращение к невыделенной/освобожденной памяти, не двойное освобождение. Это пока не пропускается, если только с сишным легаси не взаимодействует. Просто знаки больше-меньше перепутали или входные данные не проверили. Отрадно. Так держать. Не, понятно, никто не безгрешен, наверное раз в пятилетку проблемы с памятью и от самого раста будут находить, но я готов это терпеть.
Ответить | Правка | Наверх | Cообщить модератору

287. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (287), 08-Янв-23, 01:50 
Это не очень на пятилетку похоже(удивительно как много ошибок в стандартной библиотеке и тулчейне):
https://www.opennet.me/opennews/art.shtml?num=55167
https://www.opennet.me/opennews/art.shtml?num=55607
https://www.opennet.me/opennews/art.shtml?num=56551
https://www.opennet.me/opennews/art.shtml?num=57787
Ну и хотите верьте, хотите нет, но мне не будет легче если программа просто упадет, займет всю память или даст рут-доступ, но ЗАТО безопастно и не портя память.
Ответить | Правка | Наверх | Cообщить модератору

293. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (47), 08-Янв-23, 11:43 
Конечно верим, потому что сразу видно админа локалхоста...
Тебе будет легче если она не упадет и продолжить работу, но при этом твой диск зашифруют? или бд утечет? или просто станет частью ботнета?
Ответить | Правка | Наверх | Cообщить модератору

318. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (318), 08-Янв-23, 16:57 
>при этом твой диск зашифруют? или бд утечет? или просто станет частью ботнета?

А что мешает это сделать из под раста, если возможность получения рут-доступа никуда не исчезла?

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

323. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 08-Янв-23, 17:21 
Как получить рут-доступ, если сервер замедлился или упал из-за перерасхода памяти?
Ответить | Правка | Наверх | Cообщить модератору

325. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от Аноним (318), 08-Янв-23, 17:37 
>Как получить рут-доступ,

https://www.opennet.me/opennews/art.shtml?num=55607
>В Rust проблеме оказалась подвержена стандартная библиотека "std::net" (CVE-2021-29922). Парсер IP-адресов данной библиотеки отбрасывал ноль перед значениями в адресе, но только если указано не более трёх цифр, например, "0177.0.0.1" будет воспринято как недопустимое значение, а в ответ на 010.8.8.8 и 127.0.026.1 будет возвращён неверный результат. Приложения, использующие std::net::IpAddr при разборе указанных пользователем адресов потенциально подвержены атакам SSRF (Server-side request forgery), RFI (Remote File Inclusion) и LFI (Local File Inclusion).

https://www.opennet.me/opennews/art.shtml?num=55167
>В ходе аудита была выявлена группа уязвимостей (CVE-2021-31153, CVE-2021-31154, CVE-2021-31155), приводящих к краху и не исключающих возможность создания эксплоитов для повышению привилегий в системе

Ну и не совсем рут-доступ, но удаление системных файлов тоже неприятно
https://www.opennet.me/opennews/art.shtml?num=56551
>В стандартной библиотеке языка Rust выявлена уязвимость (CVE-2022-21658), связанная с состоянием гонки в функции std::fs::remove_dir_all(). В случае применения данной функции для удаления временных файлов в привилегированном приложении злоумышленник может добиться удаления произвольных системных файлов и каталогов, к удалению которых в обычных условиях у атакующего нет доступа.

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

331. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 08-Янв-23, 20:05 
Эти случаи уже много раз обсудили, обмусолили и сделали выводы. Давайте здесь обсуждать тему топика и не перескакивать, а то иначе не понять, кто что имеет ввиду и о каких проблемах вообще говоря речь. Проблема, вызванная отсутствием проверки реального объема загружаемых данных и попыткой резервировать большой кусок памяти, никак не приведет к повышению привилегий в системе.
Ответить | Правка | Наверх | Cообщить модератору

341. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (341), 08-Янв-23, 23:35 
>4:19: Какой рут? Из под раста нельзя ничего подобного получить
>приносятся ссылки
>4:20: Это уже сто раз обсудили, так что давайте не будем переводить тему, да и вообще забудем про данный разговор, ничего не было. Раст швятой

Классика.

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

291. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (294), 08-Янв-23, 11:39 
Нужен новый язык. Раст решает не все проблемы
Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

322. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от freecoder (ok), 08-Янв-23, 17:20 
Новый будет создан на основе Раста и с учетом его преимуществ и недостатков. Ещё не скоро.
Ответить | Правка | Наверх | Cообщить модератору

350. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (351), 09-Янв-23, 15:03 
Rust with classes, Objective-Rust, Rust++
Ответить | Правка | Наверх | Cообщить модератору

312. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Аноним (314), 08-Янв-23, 16:00 
Ты ещё в сортах уязвимость разбираешься? Типа когда тебя взломают через неправильный знак это что будет смягчающем обстоятельством? Да пофиг тебе уже взломали.
Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

290. Скрыто модератором  +1 +/
Сообщение от Аноним (294), 08-Янв-23, 11:38 
Ответить | Правка | Наверх | Cообщить модератору

311. Скрыто модератором  +/
Сообщение от Аноним (314), 08-Янв-23, 15:57 
Ответить | Правка | Наверх | Cообщить модератору

316. Скрыто модератором  +/
Сообщение от Вы забыли заполнить поле Name (?), 08-Янв-23, 16:17 
Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

321. Скрыто модератором  –1 +/
Сообщение от freecoder (ok), 08-Янв-23, 17:18 
Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

337. Скрыто модератором  –1 +/
Сообщение от Ыыыыыы (?), 08-Янв-23, 20:25 
Ответить | Правка | Наверх | Cообщить модератору

352. Скрыто модератором  +/
Сообщение от freecoder (ok), 09-Янв-23, 15:23 
Ответить | Правка | Наверх | Cообщить модератору

305. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –2 +/
Сообщение от Карбон лучший (?), 08-Янв-23, 14:35 
Когда же вы поймёте что самый безопасный язык это Carbon
Ответить | Правка | Наверх | Cообщить модератору

309. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (314), 08-Янв-23, 15:56 
Когда пройдет фанатизм == никогда.
Ответить | Правка | Наверх | Cообщить модератору

338. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Ыыыыыы (?), 08-Янв-23, 20:27 
Не ври, most wanted лучше!
Ответить | Правка | К родителю #305 | Наверх | Cообщить модератору

348. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от Аноним (349), 09-Янв-23, 14:00 
> копирующая данные запроса и ответа целиком в один буфер без проверки размера полученных данных

Что и требовалось доказать: баги полностью зависят от криворуких погромиздов, язык не причём.

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

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

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




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

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