The OpenNET Project / Index page

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



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

Оглавление

Уязвимость в приложениях на базе HTTP-библиотеки Hyper, opennews (??), 06-Янв-23, (0) [смотреть все]

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


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ообщить модератору

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

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




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

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