The OpenNET Project / Index page

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



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

Оглавление

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

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


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

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

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




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

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