В библиотеке Hyper, предлагающей реализацию протоколов HTTP/1 и HTTP/2 на языке Rust, выявлена особенность работы с памятью, которая может использоваться для инициирования отказа в обслуживании через исчерпание доступной процессу памяти. Для эксплуатации уязвимости достаточно отправить специально оформленный HTTP-запрос уязвимому обработчику, использующему Hyper. Библиотека достаточно популярна (67 млн загрузок) и используется в качестве зависимости у 2579 проектов, представленных в каталоге crates.io...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58444
Шах и мат
Ох уж эти голуби...
> Ох уж эти голуби...Вы научили голубей играть в шахматы? О...еть, дайте две!
Нет, это голуби вообразили, что они умеют играть в шахматы.
Как будто Си-макаки читают документацию и пишут скучные проверки. Только в сишке подобный "тяп-ляп-в продакшн" бы привел к RCE, а не к исчерпанию памяти.
Я всегда делаю проверки, особенно параллельно разрабатывая на Го привычка выработалась. А документацию на что? У нас же нет миллионов импортов.
> Я всегда делаю проверкиА причём здесь ты?
> У нас же нет миллионов импортов.
Каждый раз велосипед с нуля изобретаете, что ли?
Это язык системного уровня. А не одно название языка ногами запиханное в ядро.
> Это язык системного уровня.Это сплошная дыра системного уровня. Костыль, которому давно пора на свалку, потому что с нынешней сложностью По он уже явно не справляется.
Это у вас в мозгах сложность. Buttplug можно и на Си делать, только никому в голову не пришло.
Это не у меня в мозгах сложность. Это очевидный и хорошо задокументированный факт, подтверждённый разными независимыми источниками. А вот ваши высказывания - да, их происхождение обусловлено исключительно вашим ограниченным представлением о современном ПО.
Это ж как 40 лет костыль работу всей мировой техники обеспечил? Революционеры малолетние.
> Это ж как 40 лет костыль работу всей мировой техники обеспечил?Мягко скажем, очень и очень плохо. Хотя люди старались, да.
> Мягко скажем, очень и очень плохо. Хотя люди старались, да.Ну ты то пока и так не смог, так что чья бы мычала. Хотя нагадить под себя у таких как ты норма, конечно.
Ну да, ну да. Сперва добейся. :)
> Революционеры малолетние.О, давай приборами меряться. Мне шестой десяток пошёл уже. А тебе?
А где ты был, почему раст не изобрел? ведь 60 лет назад любой чел мог в гараже зачать мировое лидерство.
У тебя с головушкой всё в порядке? Или после НГ никак отойти не можешь?Поясню, пожалуй, ибо логика не твой конёк. По-твоему, все, кому пошёл шестой десяток должны обязательно стать изобрателями Rust, что ли?
Мне не 60 лет. Мне шестой десяток пошёл. У тебя и с математикой нелады. Теперь понятно, почему ты так новому сопротивляешься. Что ж, мне жаль.
Это тот который "документацию читать надо, и не будет ошибок".Но так и не смог прочитать "6ой десяток" и отличить от "60 лет". И что-то там ещё втирает про чтение документации и неделание ошибок.
В двух словах потерялся. Рановато тебя к Сишной документации допускать. Тебе только Python пока выписываю. Приходи после Computer Science 101.
школоте не спится на каникулах?
Э-э-э, ты кому это?
> Мне шестой десяток пошёл уже.И ты до сих пор не научился сохранять холодный ум и не воспламеняться энтузиазмом по поводу любого выс*ра, который авторы объявляют спасением человечества?
Я не только этому научился за это время, а ещё и думать, анализировать. Чего не скажешь о многих из присутствующих здесь.
Документацию читать надо уметь, т.к. метод тыка в Си не работает. Макаки это когда стэковерфлоу программинг, галопом по европам запихнуть, скомпилилось и дальше.
А откуда, сишные дырени (тм) берутся? Нет, метод тыка везде работает. Особенно в сложных системах, написанных с запасом избыточности. Так что ты можешь и не узнать, что система работает, но не по той спецификации "на неё", что у тебя в голове.
Да тут нет С программистов, тут одни админы которые, как я понял воюют за "тру".Откуда им знать про документацию, он её и в глаза то не видел.
А если бы реально читал линуксовые маны, то знал бы что чтобы их хотя бы в целом понять надо раз 10 прочитать. И вчитываться в каждую буковку, в каждую запятую.
99% С-программистов так не делают, иначе писали бы по 10 строчек (корректных) в день. И этих чтецов нахрен бы повыгоняли.
Моё любимое - любой системный (и libc-шный) вызов может завершиться неудачей (быть прерван) и, даже для read нужно организовывать цикл со 2-3 условиями (всё прочитал, прочитал часть, и прерван - перечитать).
>и прерван - перечитатьага перечитай с битого диска, думаю там у вас while(true)
Нам проще написать leftpad, чем подключать заголовок или добавлять в сборку либу.
А бедные пользователи должны платить потом за эту "простоту". Гениально, чего уж.
Ты видишь текст новости? Там макаки не глядя запихали свою простоту, ведь великий и могучий канпилятор позволяет не думать ни о чем, а кратеры позволяют собирать как лего (у вас в детстве уже существовало лего или еще нет?)
Я вижу. Но не только вижу, а ещё и анализирую. Макаки есть в любой сфере, от них нельзя оградиться. Но причём тут язык программирования? Никто никогда не говорил, что данный конкретный компилятор защищает от любого класса ошибок. Если ты, или тебе подобный, почему-то представлял в своём воображении иначе - у меня есть способ, как это исправить - RTFM до посинения.> у вас в детстве уже существовало лего или еще нет?
Нет, я родом из СССР. Было, скажем так, подобие Лего.
"подобие", которое развивало фантазию, а не заставляла лепить заранее заготовленные блоки друг к другу.
На самом деле, те конструкторы были практически полной копией Лего. Спионерены один к одному.
Друк, а ты понимаешь значение слова "конструктор"? Оно если что как раз про лепление блоков друг к другу)
Как будто сишники делают иначе.
И называть макакими сишников это отчаяние. Всех тех, кто всю твою жизнь и до твоего существования всё это нынешнее рабочее разработал.
> всё это нынешнеедырявое и дорогое в конечной эксплуатации по этой причине. Низко кланяюсь (нет).
удОли весь сишный код со своего компа, с телефона и с домашнего роутера. Вангую ты сразу пропадешь из Интернета.
Как же могучи эти аргументы "сперва добейся, не надо раскачивать лодку и знающие люди разберутся" (нет).
Да, шах и мат сишникам. Ибо ещё раз доказывает, что "70% ошибок" исключает (в safe-режиме), а на оставшиеся 30% включай голову - domain-бизнес-логику за тебя язык не напишет и документацию к продукту не прочтет. Плюс в карму расту. Разве что с циклическими ссылками надо быть осторожным.
вижу "шах и мат" - ставлю минус. где шах, где мат, ты хоть правила знаешь или только конём могёшь?
Я знаю. И даже когда-то (давно, на самом деле) играл на уровне первого взрослого разряда. А что не так он написал? Или надо было к чему-то придолбаться?
Ожидаемое поведение, в документации все описано.JFrog решили в очередной раз попиарится - ок. Зачем это сюда принесли?
Второй параграф в документации> 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.
Делают комбайн со 100500 возможностей - фуфуфу гигантская кодовая база, сложно проводить аудит и вообще не юниксвейно.
Делают библиотеку с ограниченной функциональностью - о нет она не валидирует штуканейм и это уязвимость.Типичная биполярка различных экспертов.
P.S. https://docs.rs/tower-http/latest/tower_http/limit/struct.Re...
Можешь как угодно называть уязвимость (ниже уже назвали "задокументированным поведением"), как угодно критиковать архитектуры и как угодно выставлять диагнозы опеннетчикам, но отказ в обслуживании это не исправит.
Проблема этой ветки обсуждения в том, что некоторые комментаторы пытаются экстраполировать человеческую ошибку пользователей библиотеки на якобы имеющиеся изъяны языка программирования.И при этом эти же комментаторы в упор не замечают изъяны в логической цепочке своих рассуждений.
Проблема этой ветки в том что раст преподносился (и преподносится) как язык решающий человеческие ошибки. Но по факту он решает их малую часть (и создает новые). То есть от чего уходили (человеческие ошибки в си) к тому и пришли (человеческие ошибки в расте).
Люди разделились на тех кто решил этого не замечать (растоманы) и тех кто об этом говорил с момента зарождения раста (сишники). В зависимости от этого и разное отношение к каждой подобной новости.
> Но по факту он решает их малую часть (и создает новые).Ложь. Решает бОльшую часть. Решает 70% ошибок. 30% < 70%. Новые не создвал. Просвети насчет новых. Главная ошибка - ты не смог осилить новый ЯП?
> Ложь. Решает бОльшую часть. Решает 70% ошибок. 30% < 70%. Новые не
> создвал. Просвети насчет новых.Давай посчитаем. Какие конкретно ошибки в твоих программах с использованием современного C/C++ по современным методикам с линтерами и анализаторами решил раст и к каким последствиям эти ошибки привели лично для тебя и твоих пользователей?
> Главная ошибка - ты не смог осилить
> новый ЯП?Спервадобейся в 2023? Серьезно?
"Но я же могу рассуждать о качестве омлета, хотя еще ни разу не снёс ни одного яйца."
Зачем обмазываться линтерами, анализаторами и распухшим до безобразия новым стандартом, если можно писать сразу удобно и в кайф?
> Зачем обмазываться линтерами, анализаторами и распухшим до безобразия новым стандартом,Так ты и в расте ими обмазываешься, только выбора у тебя нет в отличии от плюсов.
А новые стандарты не распухшие и гораздо менее новые чем новый раст со своими новыми растовыми проблемами.> если можно писать сразу удобно и в кайф?
Разработчики сабжа так и сделали, а пользователи получили кайфовые уязвимости.
> раст преподносился (и преподносится) как язык решающий человеческие ошибкиВот только не было обещаний, что он решит их все.
>> раст преподносился (и преподносится) как язык решающий человеческие ошибки
> Вот только не было обещаний, что он решит их все.Я еще с первых форсов раста писал что чуда не случится и все имеет свою цену, давайте разбирать техническую сторону и смотреть трезво на то что раст предлагает и что он требует. Никто из растоманов тогда не удосужился адекватно ответить что же раст порешает и каким образом.
Это не мешало растоманам ругать си и основной упор был на дедовские библиотеки, необходимость бесконечных проверок в коде на си, сложности написания безопасного кода на си и т.д.. Проходит несколько лет и несколько относительно крупных проектов на расте..."забывают" добавить проверку описанную в документации. Прямо как деды в си. Конечно "это не проблема раста", но уязвимости в программах на си не были "проблемами ЯП", а именно так заявляли растоманы.
Я прекрасно помню как в новостях об очередной найденной нетривиальной уязвимости утилиты на си, допущенной программистом (а не ограничем ЯП), приходили растоманы и писали что на си невозможно написать безопасный код и что срочно надо все переписать на расте. Теперь ровно такая же ситуация (даже намного более тривиальная) с проектами на расте, но растоманы говорят "вы не понимаете! это другое! наш ЯП не виноват". Так и си был не виноват.
Двуличность растоманов мягко говоря зашкаливает.
Если ты бездумно используешь метод "я буду сохранять все байтики в память", который явно в документации помечен опасным - надо свою кукуху лечить, а не низкоуровневую библиотеку. А вот почему создатели более высокоуровневых реализаций серверов не поставили ограничение по-умолчанию - это уже совершенно обоснованная претензия.
>Care needs to be taken if the remote is untrusted.У них там с башкой проблема? Remote is always implicitly untrusted.
Нет. Remote может быть nginx в режиме reverse proxy, который сделает все проверки за тебя.
Это же библиотека для сборки из кирпичиков, а не полнофункциональный сервер. А лимит понятие относительное. На видеохостинге он обычно чуть больше, чем на смарт-часах.Это примерно как в malloc() засунуть проверку, чтобы слишком много не выделяли :-)
Так и в си UB описаны, необходимость проверок тоже. Но почему-то в си это фатальный недостаток, а в расте "задокументированное поведение".
> Так и в си UB описаны, необходимость проверок тоже.Правда, сам ты весь список не читал, просто слышал звон.
> Но почему-то в си это фатальный недостаток, а в расте "задокументированное поведение".Никаких "почему-то" не было, если бы ты черпал свои познания по ЯП не только лишь из комментов на опеннете - тебе бы вряд ли пришло в голову сравнивать один ЯП с HTTP-библиотекой на другом.
Но увы, увы ...
> а в расте "задокументированное поведение".В расте или в имплементации какой-то библиотеки на расте? Ты чем читал? Молодец, сравнил недостатки языка программирования си с недостатками кем-то написанной библиотекой-фреймворком. Никто не мешает тебе сознательно на расте написать пучок "полезных" фреймворков, специально впендюрить туда что-то типа "извне запросили выделить 1 мегабайт памяти? Выделю 1 гигабайт, ха-ха-ха", а потом кричать на каждом углу: "-раст гнилой! Он ошибки памяти делает! Жрет как не в себя!". Ну или не проверять переданные извне параметры. И опять у тебя будет раст виноват, чего это ЯП, а не программист, не проверил, что там в JSON/XML прилетело.
Ну пошли отмазки. Лет 9 назад вас, растоманов, не волновало что ещё и библиотеки надо писать с новыми багами(между прочим один из аргументов сишников против раста) и вообще думать все равно придется. Наоборот, растоманы писали что "разработчики раста уже подумали за программиста". Теперь вот на ходу (последние несколько лет) меняете риторику.
Всё чем вы оправдываетесь в последнее время, всё это писали вам сишники лет 9 назад.
Это не отмазки. Это попытка объяснить слабым разумом, что данная конкретная ошибка не имеет никакого отношения к языку программирования. Но некоторым, что в лоб, что по лбу. Увы.
Библиотека на чем написана? Значит обгадился раст.
Попытка выделить большой кусок памяти не является небезопасной операцией. Safe Rust такое разрешает и подобные "ошибки" (а на самом деле и не ошибки вовсе) не устраняет.
хе, представляю. Пишет кто-то какой-нибудь хайлоад для суперкомпа с терабайтом озу. Выделяет такой память под буфер, скажем, 10ГБ (ну там наколеночно-велосипедный in-memory-db), а тебе такой компилятор (или код в рантайме) раз: " - ошибка! разрешается выделять не более 1МБ ОЗУ, я так решил, 1 МБ должно хватить всем! Читай мануал языка, там это написано, в мануале запрещено выделять более 1МБ памяти!". Я правильно тебя понял?> Библиотека на чем написана? Значит обгадился раст.
А на си дофига троянов, вирусни написано для сишных же ОС. Причем трояны тоже зачастую с сишными ошибками. Вот уж насколько тогда си обгадился - на столетия хватит легенды и мифы сочинять.
Об этом сишники писали 10 лет назад. Что ЯП не исправит человеческие ошибки, даже наоборот - либ нет, а пока сделают новые наклепают и новых ошибок (что и произошло).
В ответ им заявлялось что де раст то все исправит, якобы разработка на расте изначально безопаснее и намного проще и быстрее (поэтому все дедовские либы перепишут гораздо быстрее чем писали на си).
Чуда не случилось и теперь аргументы сишников 9 летней давности отправляют обратно сишникам и считают что это ок.
> В ответ им заявлялось что де раст то все исправит,наглая ложь. И ты это понимаешь. Троллишь наверное. Всем понятно (и тебе тоже), что всё не исправит. Какой ЯП тебе исправит ошибку, где ты знаки "больше" "меньше" перепутал в логическом условии, где синтаксически могут быть оба знака? Или считал что-то из БД, а потом не вычел это из промежуточного результата, а сложил с ним? Или не проверил диапазон допустимых значений в поле полученного JSON и потом склеил из этого гов.а SQL-запрос, вместо всех предварительных проверок и использования переменных подстановки? В таких ошибках си и раст не отличаются друг от друга. Но печалька для тебя в том, что статистика показывает, что таких ошибок только процентов 30% в сишных программах. А остальных 70% в расте нет (если нет ансейфа), всё в си госталось.
> якобы разработка на расте изначально безопаснее и намного проще и быстрее
ну вот создатели tor прямо так прямым текстом и говорят - и безопаснее и разработка пошла быстрее и проще - им надо значительно меньше ручных проверок в код добавлять, дизайн языка и компилятор помогают.
> наглая ложь. И ты это понимаешь. Троллишь наверное.Нет
> Всем понятно (и тебе тоже), что всё не исправит. Какой ЯП тебе исправит ошибку, где
> ты знаки "больше" "меньше" перепутал в логическом условии, где синтаксически могут
> быть оба знака? Или считал что-то из БД, а потом не
> вычел это из промежуточного результата, а сложил с ним? Или не
> проверил диапазон допустимых значений в поле полученного JSON и потом склеил
> из этого гов.а SQL-запрос, вместо всех предварительных проверок и использования переменных
> подстановки? В таких ошибках си и раст не отличаются друг от
> друга.Так это и заявлялось противниками раста и лично мной. ЕМНИП даже пример
> знаки "больше" "меньше" перепутал в логическом условииприводился такой же. На что растоманы отвечали что да, раст не решает вообще всех проблем, а только конкретные. На что задавался вопрос какие конкретно проблемы, почему их нельзя решить в си и плюсах, почему нужно городить новый велосипед. В итоге выяснялось что решить в плюсах с помощью линтеров и либ можно почти все (отдельно стоял вопрос по борроу чекеру, где традиционно закидывались ссылки на статьи которые ни одна сторона не осиливала прочесть), далее просто шли холивары вкусовщины: встраивать ли линтер в компилятор, что должно быть в стандартной библиотеке, есть ли вообще польза от unsafe, т.е. в основном все сводилось к "программист-творец должен все делать сам" против "творцев в дикой природе быть не может, мы все макаки, за нас уже подумала мозилла".
> Но печалька для тебя в том, что статистика показывает, что
> таких ошибок только процентов 30% в сишных программах. А остальных 70%
> в расте нет (если нет ансейфа), всё в си госталось.Печалька в том что вся статистика которую я видел готовилась самими растоманами с нарушением всем методик. В духе "сравним проблемы в коде написанного специально для криптолибы полгода назад с грепалкой написанной в доинтернетовскую эпоху на старых плюсах без линтеров и анализаторов".
Ну а практика показывает что фурифокс переписали крайне малую часть, из вменяемого софта пожалуй только ripgrep и rustdesk вспомню и пожалуй все, но даже отсутствие популярного софта на расте не мешает периодически выстреливать сабжевыми новостями, что как бы намекает.> ну вот создатели tor прямо так прямым текстом и говорят - и
> безопаснее и разработка пошла быстрее и проще - им надо значительно
> меньше ручных проверок в код добавлять, дизайн языка и компилятор помогают.Я такое уже слышал один в один, но в разное время про java (причем несколько раз в разное время), C#, js (nodejs, electron), очередную версию php, ruby. И конечно же по каждому из них были восторженные статьи от успешных компаний.
> На что задавался вопрос какие конкретно проблемы, почему их нельзя решить в си и плюсах, почему нужно городить новый велосипед. В итоге выяснялось что решить в плюсах с помощью линтеров и либ можно почти всеТак почему так и не решили?
Так в основном и решили.
> Ожидаемое поведение, в документации все описано.Дополню. Запросы со слишком большим телом почикает nginx. Расходимся
Почикает нгиннкс на С
а че с чанками делать и крывыми размерами контента в заголовках?
Я бы сказал безмозглое поведение - выделять оперативную память под запрос целиком на основе "Content-Length". Рустоманы так упоролись на том чтобы всем доказать "безопасность работы с памятью", что их поделие заболело детскими болячками Apache. Так скоро LOIC опять станет актуален.
Еще поди можно так:
- кидаем много запросов с небольшим Content-Length, но с телом усеченным до нуля и одного байта.
- сервер выделяет под них память, но освобождает ее с лагом, так как ждет нужное количество байт которых нет.
>так как ждет нужное количество байт которых нет.в смысле? освобождает ровно столько сколько выделил
Выделяет столько сколько сказали. Затем он по какому-то таймауту должен понять, что столько байт ему никто передавать столько не собирается. Думаю не меньше нескольких секунд. К примеру, открыл какой-нибудь бот 1000 соединений, в каждом попросил принять 10M, и ... добрый сервер выделил боту 10G оперативной памяти? А если столько нет? Да и затраты на выделение не нулевые. Допустим через секунду бот отвалился и все соединения сброшены, а память освобождена, но что мешает боту еще "медленной записью" заняться передавая эти 10M по паре байт в секунду, тогда и таймаут не сработает и у сервера 10G оперативки будут заняты на неопределенный срок.
Выделять под буфер нужно столько памяти, чтобы обработчик запроса успевал обрабатывать без задержек(к примеру парсер JSON успевал обработать ключ и привести его значение к нужному типу), а не помещать весь запрос в оперативную память, а потом обрабатывать.
> добрый сервер выделил боту 10G оперативной памяти? А если столько нет?overcommit
> что мешает боту еще "медленной записью" заняться передавая эти 10M по паре байт в секунду
Лимит по времени на запрос
Но при этом на "лимит времени" память будет занята. Притом атакующий затратит гораздо меньше ресурсов. Так ему нужна память только на заголовки одного запроса, а в качестве тела будет "мусор". Нет, так дела не делаются. Выделяем буфер на заголовки. Парсим проверяем. Далее либо буферизуем тело небольшим буфером передавая по частям обработчику, либо просто пробрасываем TCP-соединение ему - пусть сам разбирается.
В данном случае упоролись всё же Воины Борьбы Супротив Раста, раз и после нескольких десятков комментариев не понимают, что данная конкретная ошибка не имеет никакого отношения к возможностям языка программирования.
упоролись растоманы которые всегда утверждали, что раст решает все проблемы безопасности.
Приведите доказательства, что растоманы утверждали, будто Rust решает ВСЕ проблемы безопасности. А не подмножество проблем, связанных с безопасностью работы с памятью и безопасностью типов.
> Приведите доказательства, что растоманы утверждали, будто Rust решает ВСЕ проблемы безопасности.
> А не подмножество проблем, связанных с безопасностью работы с памятью и
> безопасностью типов.Давненько я лично писал на опеннете что раст не решает всех проблем, а только некоторые небольшие и не самые важные проблемы, многие из которых и на плюсах решаются линтерами, зато раст требует очень уж большую цену и может вместо своего нового велосипеда стоит сконцентрироваться на старых плюсах. Проходит несколько лет и этот же аргумент теперь приводят растоманы в защиту раста.
Я конечно не буду тратить свое время на поиск доказательств и комментариев многолетней давности, но прекрасно помню как раст в начале преподносился (в основном на хабре и в комментариях опеннета, официально мозилла таких заявлений не делала) как серебрянная пуля решающая все проблемы как миниум с памятью и тредами. Какие конкретно проблемы и как это реализовано технически на тот момент растоманы опеннета внятно ответить не могли. За это время я видел как менялась позиция растоманов: сначала от фанатского "придёт и все-все-все решит" и "нужно все переписать на раст, он все делает лучше" до "это не проблема ЯП/на си тоже такие проблемы есть/никто и не обещал решить эту проблему". Радует что в ответах растоманов все меньше фанатизма и все больше технических подробностей, но забавно видеть как с каждым таким ответом от гиганта отваливается кусок и вместо непобедимого колосса до финиша доходит захудалый замухрышка, который "никому ничего не обещал".
А сейчас растоманы усиленно закрывают глаза на то что раст фактически принадлежит гуглу и мелкософту. Увы, если раст взлетит, то это ружье обязтельно выстрелит.
Rust решает некоторые проблемы, но большие и очень важные. Линтерами на плюсах они не решаются в той мере, которой решаются растом. Как видите, это совсем не "тот же самый аргумент".Поэтому и прошу привести подтверждения. Пока вы только привели свою интерпретацию слов растоманов, а самих исходных слов не привели.
Так это специальная функция для чтения запроса целиком. Когда он заведомо небольшой. Если больше лимита - проверь и отдай HTTP 413 Payload Too Large. Лимит, разумеется, на усмотрение разработчика, а не автора библиотеки - а как еще?Для чтения по кускам там есть функция aggregate(), и, внезапно, в мануале рекомендуется использовать именно её.
Безопасность не поместилась в оперативную память
боров-чекер оказался слишком жирным боровым и не влез в оперативку
борров чекер проверяется и работает на этапе компиляции в скомпилированном коде он потребляет 0, вы белину сьели?
Я знаю что это такое, просто мне слово нравится... боров
Проверяльщик боровов, дядь. Который при компиляции бегает между каждым боровом и смотрит им...хм, пусть будет в пятачок, чтобы не залезли боровы и рылом дырок-уязвимостей не нарыл.
я может что-то не понимаю, но раст с кучей не умеет что ли работать? Если на этапе компиляции, то как он выполняет эти ваши боровы-чекеры с аллоцированной в рантайме памятью?
Компилятор не проверяет, сколько именно памяти есть в системе - это не его задача. Он проверяет, чтобы висячие ссылки не появлялись, чтобы use-after-free не происходило. Конечно же Rust умеет работать с кучей, но он не всемогущ, как некоторые ошибочно полагают. В нём по-прежнему возможны разные ошибки (в том числе утечка или переполнение памяти). В чём же смысл тогда, кто-то может спросить? В том, что Rust предотвращает наиболее распространённые ошибки.
... способствует программисту потерять бдительность
Не способствует, а освобождает программиста от слежения за определённым классом ошибок, позволяя ему сосредотачиваться на других вещах, более полезных и продуктивных.
Способствует. Более того: создает впечатление у новичков что программирование - это очень просто.
Скажем так, у слабых разумом такое может случиться. Но мы ж о нормальных, правда?Ну и какой новичок лучше, если уж на то пошло? Который постоянно забывает память освобождать, или которому это помогает избежать компилятор?
Можно выразить надежду, что со временем новичок научится память освобождать. Но практика, увы, показывает иную статистику. Даже профессионалы высочайшего класса допускают подобные ошибки. Потому что все люди ошибаются. Так зачем позволять людям плодить ошибки, если можно от них оградиться? В чём смысл продолжать использовать такие языки, которые содержат архитектурные изьяны с рождения? Ладно, для обучения - ещё куда ни шло. Но в серьёзных дорогих проектах - зачем?
Какой же ты тупой. Это не архитектурный изъян. Такими словами можно сказать интелам и амд с ARM -- почему вы на уровне ядер и конвеера кода позволяете обращаться не туда?
> Это не архитектурный изъян.Отсутствие возможности контролировать работу с памятью, когда тебе это нужно - это изьян. Си не предоставляет таких возможностей на уровне языка. Поэтому он ущербный по современным меркам язык программирования. Плюсы - предоставляют, но они стали настолько сложными, и с таким количеством UB, что пользоваться ими стало просто опасно: иной раз можно наступить на такие грабли, который фиг потом найдёшь.
> Такими словами можно сказать интелам и амд с ARM -- почему вы на уровне ядер и конвеера кода позволяете обращаться не туда?
Нельзя такими словами сказать. Потому что процессоры - это базовый элемент конструкции (аппартно-программного комплекса). На этом уровне и не должно быть высокоуровневых проверок. Это кирпичики, из которых строится здание. И как всякие кирпичики, они обладают только базовыми свойствами. Перефразируя известную поговорку: то, что можно процессору, программисту - смерть.
> Какой же ты тупой.
Ты ни в зуб ногой о современных способах разработки ПО, а тупой - я. Говорю же, ты забавен. :)
> Отсутствие возможности контролировать работу с памятью, когда тебе это нужно - это изьянwhat? В Си контроллировать память можно когда угодно и как угодно? Про какой изъян ты бредишь?
Так таким значит надо писать на Java, Go, Dart, C#, JS наконец с Питоном -- вы же бизнес-логику прикладную пишете? Или у вас комплекс называться системным языком, зачем лезете к железу близко, но при этом избегаете его? Это как девочки у вас в вебкамах -- на расстоянии только, а IRL Buttplug и единороги.
> Так такимКаким таким? Все люди подвержены ошибкам. Исключений нет. И это, как я уже сказал выше, документально засвидетельствованый факт.
> Java, Go, Dart, C#, JS наконец с Питоном --
Эти все языки придумали не от хорошей жизни. Люди осознали, что надо что-то делать с дыренями Си, и сложностью Плюсов.
> Или у вас комплекс называться системным языком, зачем лезете к железу близко, но при этом избегаете его
Это не у меня комплекс. Это у тебя комплекс, потому что ты не понимаешь идеологию Rust. А раз не понимаешь, то эта идеология тебе кажется глупой. Rust позволяет тебе работать так, как хочешь. Но по умолчанию не даёт тебе "кудесничать", как ты, очевидно, привык. Однако же, если очень хочется - пожалуйста, но тогда пеняй на себя.
> Это как девочки у вас в вебкамах
Какие девочки, у кого у вас? Ты точно трезвый?
Добывай огонь трением, мало ли, спички закончатся
> Rust
> выявлена особенность работы с памятью, которая может использоваться для инициирования отказа в обслуживании
> достаточно отправить специально оформленный HTTP-запросОк, ясно
Не думаю, что тебе стало что-либо ясно. Но ок.
> копирующая данные запроса и ответа целиком в один буфер без проверки размера полученных данныхРастоманы, что с лицом?
>> Примечательно, что указанное поведение явно описано в документации, в которой рекомендуется выполнять отдельные проверки размера, но предупреждение игнорировалось в различных продуктах
> Растоманы, что с лицом?Воены Супротив Раста, что с чтением новости дальше первого абзатца?
А что там?
А там читать доку нужно уметь
Ах, так это лицо! ©
Всё правильно. Ещё со времён Юниксов и Си правильно. Программа или библиотечная функция должа делать ровно одну задачу и делать её хорошо. Проверка входящих параметров — это отдельная задача. Если она не нужна, зачем за неё платить? Это кстати, часть философии Раста.
Всё верно,товарищ.
Проверки выхода за границы массива - тоже отдельная задача.Эту Unix/C философию разгребаем уже 30 лет.
> Проверки выхода за границы массива - тоже отдельная задача.В современных крестах это уже реализовано. Но раст не дотягивает до крестов.
А Си это системный язык, близкий к железу, а не к единорогам по фрейду. Это фича, а не баг, код скомпилил -- получил листинг ассемблера соответствующий коду (условно), а не какие-то чистилки мусора, виртуалки, обслуживалки. Ввел ты какое-то число, забыли проверить индекс на любом языке, всё.
Тыкну тебя в единственный по-настоящему системный язык программирования. Он называется Zig.Ближе к железу только чистый ассемблер.
И ты узнаешь что возможности языка (система типов, например) никакого отношения не имеет к тому системный язык или нет.
В Debug все проверки есть. В ReleaseFast проверок выхода за границы нет. Можно же было сделать такое и в С (лет 15 назад)?
А в С++ только если .at() есть проверки, в [] проверок нет.
> Можно же было сделать такое и в С (лет 15 назад)?Это уже давно есть. Открой для себя санитайзеры наконец.
Ты понимаешь разницу между специализированным ПО (которое, несмотря на все усилия, не в состоянии выловить все ошибки) и архитектурными особенностями языка программирования, не дающими тебе совершать такие ошибки априори? Это был риторический вопрос, потому что из твоего комментария и так всё понятно.
> Ты понимаешь разницу между специализированным ПОА ты понимаешь, что компилятор раста - это тоже специализированное ПО?
> которое, несмотря на все усилия, не
> в состоянии выловить все ошибкиА компилятор раста способен выловить все ошибки? Может санитайзеры и фазинг не нужен?
> Это был риторический вопрос
Тебе указали конкретный рабочий способ проверки выходов за границы, а ты все равно брызгаешь слюной. Совсем уже с растом своим офанатели и перестали воспринимать реальность.
> Но раст не дотягивает до крестов.Чего не хватает Rust, о гуру системного программирования?
> а не какие-то чистилки мусора, виртуалки, обслуживалки
В Rust всего этого нет. Сюрприз?
>> Но раст не дотягивает до крестов.
> Чего не хватает Rust, о гуру системного программирования?* Прибитость гвоздями к LLVM
* Обработки ошибок аллокации памяти
* Float-free libcore
* Работа без cargo
* Работа без стандартной либы
* Работа с динамически разделяемыми билиотеками
* Стабильного ABI и внятного версионирования
> * Прибитость гвоздями к LLVMCranelift
> * Обработки ошибок аллокации памяти
set_alloc_error_hook
> * Float-free libcore
зачем?
> * Работа без cargoесть
> * Работа без стандартной либыесть
> * Работа с динамически разделяемыми билиотекамиможно использовать C ABI, идет работа над нормальным ABI
> * Стабильного ABI и внятного версионирования
опять же, работа над ABI идет, что не так с версионированием? По моему намного лучше чем в C/C++
>> * Прибитость гвоздями к LLVM
> CraneliftСудя по описанию это еще сырой проект и нацелен в первую очередь на WASM?
>> * Обработки ошибок аллокации памяти
Это nightly-only experimental API. К тому же хочется какой-то реальный пример с этим увидеть. А так обычно все просто сводится к панике.
>> * Float-free libcore
> зачем?https://github.com/rust-lang/rfcs/issues/1364
>> * Стабильного ABI и внятного версионирования
> опять же, работа над ABI идет, что не так с версионированием? По
> моему намного лучше чем в C/C++У С++ есть стандарт. Код переписывают в соответствии со стандартами, которые выходят не так часто.
У раста стандарта языка нет, много нужных фич еще в найтли. Версии как горячие пирожки выпускают.
Ты бы не позорился. У Раст так же стандарты выходят раз в три года.
> Ты бы не позорился. У Раст так же стандарты выходят раз в
> три года.Ссылкой на стандарт поделишься?
Так если подумать и реализовано неправильно.
Если заведомо нет проверок на длину сырых (задача обработки и формирования буфера ДОКУМЕНТИРОВАНО возложена на приложение, вызывающее функцию) данных, значит функция просто обязана обрезать данные по внутреннему буферу, беря первые MAX_BUF_SIZE байт, остальное отбрасывая.Т.е. так и запишем, в библиотеке в функции работы с памятью нет даже аварийных ограничителей по работе с явно аномальными входящими данными. Лажа на деле.
А если не только подумать, тыкая пальчиком в небо, а ещё почитать доку, например? Понимаю, некоторым питонистам это слишком тяжело, и я, наверное, многого хочу, но всё же. Вот же, несколько раз уже выдержку из стандарта приводили: "Checking the Content-Length is a possibility, but it is not strictly mandated to be present."> Если заведомо нет проверок на длину сырых ... данных, значит функция просто обязана обрезать данные по внутреннему буферу, беря первые MAX_BUF_SIZE байт, остальное отбрасывая.
И каким должен быть этот внутренний буфер, уважаемый эксперт?
> Т.е. так и запишем
Очередной Воин Супротив Раста сел в лужу.
В стандартах на протоколы не пишут, что можно делать use-after-free, что память должна течь и тп. Дак какие претензии к сишника? Или это другое?
> В стандартах на протоколы не пишут, что можно делать use-after-free, что память должна течь и тп. Дак какие претензии к сишника? Или это другое?Претензии к сишникам очень простые. Они делают слишком много ошибок в сложных проектах, потому что используют морально устаревший на сегодняшний день ЯП. Что выливается в огромные денежные потери для конечных потребителей их продуктов.
То, что пользователи данной конкретной библиотеки не умудрились прочесть документацию - это, разумеется, не есть хорошо. Но причём здесь язык программирования, авторы которого никогда не утверждали, что их компилятор защитит от всех ошибок на свете?
Претензии к растоманам, питонистам и JS/TypeScript-ам (не всем!) простые - они карго-культисты, которые делают сумасшедшие вещи только потому, что какой-то сумасшедший либо за них решил, дибо им порекомендовал так делать.
> они карго-культисты, которые делают сумасшедшие вещи только потому, что какой-то сумасшедший либо за них решил, дибо им порекомендовал так делать.Какой-то поток сознания, не распарсил, сорри.
свайпай дальше
Предлагаешь, каждую вспышку больного сознания комментировать? Сорри, это не ко мне.
дебилизм какой-то, давайте напишем в документации ядра линукс, что хакеры не должны использовать дыры для целей порочащих безопасность и ядро автоматически станет безопасным. а от сбоев памяти защититься всюду ECC.
Функция выделяет памяти столько, сколько её попросили. Никаких UB при этом нет. В чем дебилизм- то?
Там написали, что ты не должен это выставлять наружу, в недоверенное окружение. Т.е. если ты аналогии про ядро кидаешь, то это не должно быть системным вызовом ядра для программ. Т.е., есть какой-то небезопасный, но универсальный механизм (молоток, которым можно гвоздь забить, а можно и голову пробить). Им можно пользоваться, как выше уже кто-то приводил пример, и в ядре для смарт-часов и в кластере из топ-500, т.е. условия эксплуатации разные. Наружу из ядра ты должен выставить другие вызовы, а не этот внутренний механизм. Этот механизм не может и не должен знать что творится снаружи и параметры этого "снаружи", это знают и проверяют клиенты этого механизма, т.е. другие вызовы ядра. А тут кто-то взял и написал прокси-сискол без проверок, который, скажем, условно, сквозным образом позволяет из юзерспейс программ читать любую страницу памяти в системе, хотя в документации написано что так делать нельзя, он не для этого предназначен. Этот внутренний механизм нужен многим другим сисколам. Большинство работает с ним правильно, согласно документации, а как появились 2-3 ленивых паршивых овцы - механизм стал нехорошим.
как же тупо, тупо никаких ограничений на выделение по "Content-Length"...
> как же тупо, тупо никаких ограничений на выделение по "Content-Length"...И каким должно быть универсальное ограничение на выделение памяти для универсальной библиотеки?
Очевидно, так как растоманы решили - чтоб отказ в обслуживании.
> Очевидно, так как растоманы решили - чтоб отказ в обслуживании.Очевидно, открыта перепись Ыкспердов опеннета.
Правда, Ыксперды не знали (а так как дальше заголовка не читали - и не смогли узнать), что Content-Length - "not strictly mandated to be present."
я и сам никогда не ориентировался на content-length, прислушивался но не ориентировался
Очевидно: библиотека должна посмотреть размер свободной памяти на машине, помножить на коэффициент нехило меньше 1 (напр. 0.25), далее помножить на (1. - 0.005 + random(0.01)), и такое ограничение и выставить.
А что если на машине 64гб рам, а в слайсе сигруппы приложению выделили всего 256мб рам?
а приложение в этой группе, когда дёрнет API, увидит, что у неё доступно для выделения 64 гига?
Какая нахрен разница, в С / libc / Linux нет реального выделения памяти. Выделяй на выделяй всё равно получишь...Выделить можно всю память + swap. На каждый процесс:)))
Адекватные люди отключают оверкоммит. И тут же выясняется, что говно и линукс и его экосистема (бочка мёда с ложкой говна есть бочка говна), программы на нём памяти жрут на порядки больше, чем на винде, и фиксить это никто не будет, потому что "у кого нет денег на железо, тот пусть пользуется софтом для быдла, а мы, илитка, можем себе позволить жрущий софт".
Очевидно: чтение реквеста должно быть блочным, а не "запихать всё в память и отдать вызывающему".
Ты про такой протокол, как UDP и на нем основанных слышал? Знаешь, как там всё работает?
Дед, ты таблетки забыл принять на ночь? Что ты, блин, несешь, старый идиот?
Ты для начала хотя бы попробуй написать простейший UDP-сервер, к-й принимает пакет по сети, дак вот сразу перестанешь такой бред нести про UDP.По твоей логике, я должен потоковое видео, льющеяся по UDP сохранять в буфер полностью? o_O Ты дурак? Что ты тут кичишься знаниями UDP, хотя сам в этом нихера не понимаешь. Знаем мы как UDP работает, и даже софт, использующий его пишем. А вот ты видимо нет, раз приводишь его тут в пример в контексе копирования ответ в мега-огромный буфер без проверки.
Если оно по 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... .
И вообще, дед, причем тут UDP или TCP? Это нижележащий уровень, транспортные протоколы. Их задача - доставить тебе в приложение (идентифицируемое по номеру порта) payload, всё. Какая разница как тебе их доставили, через TCP или UDP? Ну вот что ты так бредишь то, зачем ты так позоришься? Выпей кефиру на ночь, или что вы там злобные стариканы пьёте, и ложись уже спать.
Добавить рандом в либу... И привязать его к параметру окружения...
Да ты просто злой гений! Пусть эти зaсрaнцы попробуют найти почему оно иногда не работает!
Документацию читать надо, а ошибки - писать в лог вместе с причинами. Рандом нужен для того, чтобы удаленные атакующие не могли определить количество свободной памяти на машине в данном окне по времени.
Э-э. Выделить небольшой буфер на проверку заголовков. Передать их обработчику, чтобы тот авторизовал, проверил и сам выделил нужное количество оперативы. Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнению буфера или даже раньше передавать их обработчику. Что он с ними будет делать уже его проблема, главное буфер тут нужен чтобы избежать задержек. Но точно не пытаться считать весь запрос в оперативку.
Ну а chunked-запрос - это извращение. Насколько я помню изначально chunked был только для ответа сервера. Но потом реализовали и для запроса. При этом у chunked отсутствует заголовок Content-Length. Сколько читать указано перед чанком. Наиболее безопасно выделять буфер непосредственно перед чтением чанка проверив предварительно, что тот не слишком длинный, так как стандартом не оговорены ни максимальная длинна, ни то что чанки должны быть одинаковой длинны.
В любом случае chunked это не про быстродействие, это скорее про "бедность" передающего на оперативку. Так что нет никаких причин быстро его на сервере обрабатывать помещая весь запрос в оперативку.
Почему извращение?
Допустим мы хотим залить контент заранее не известного объёма.
Какую-нибудь телеметрию например, которая идёт потоком, но лить хотим по HTTP.
Why not?
Потому, что заранее не известно когда закончится запрос. Теоретически я хоть целый день могу развлекать сервер одним запросом(насколько хватит терпения у проектировавшего сервер). Кроме того ему нужно будет решать вопросы с увеличивающимся или уменьшающимся буфером или склеиванием, ведь максимальная длинна чанка не известна заранее и нигде не сказано что они могут быть одной и той же длинны. и эта проблема умножается на два или на три, если со стороны сервера или клиента есть прокси. Лучше уж тогда TCP и бинарный протокол, где все, включая длинну сообщения будет заранее оговорено. Не спорю то же самое можно оговорить и в заголовке HTTP, но зачем? Учитывая что выбрав бинарь вы минимум вдвое сэкономите на длинне сообщения.
Тем более, что часто люди просто не думают. Вот к примеру реальный случай. Мне предлагают использвать chunked HTTP(даже не HTTPS). Есть некий девайс на esp32(520 KB RAM), в нем есть буфер EEPROM на 128KB. Разработчик говорит: я не знаю сколько у меня записей будет потому не могу сказать заранее Content-Length. Но в данном случае это чистое лукавство. Судя по коду у него две третьих оперативы всегда свободны. Т. е. запрос содержащий если не половину, то четверть EEPROM можно спокойно затолкать в оперативку даже в формате JSON и посчитать его длинну.В 4-5 запросов можно передать все данные. Но нет, нужно же осложнить жизнь разработчику сервера и передать все в одном chunked, и пусть этот разработчик продумает все возможные способы атаки, где левый долбящийся бот может вызвать отказ.
Если что, реальный случай. Есть некая небольшая компания занимающаяся IOT, у них есть сайт с demo-кабинетом. Меня пригласили оценить и возможно сделать что-то подобное(я универсал, "сам пою, сам снимаю, сам по морде получаю"). Зашел в кабинет - красивенько. Ну там схема квартиры, и один датчик. Вижу кнопку "отчет" и datetimepicker. Пробую отчет за день - нормально. За неделю - сервер слегка задумался. За месяц - сервер упал. Да так что даже статус не возвращает. Вместе с сервером упал и сайт компашки. Вот специально попросил заказчика проверитть, что не меня забанили, а именно сервер упал. Да не может быть думаю. Через полчаса, когда кто-то видимо перезагрузил сервер повторяю операцию - сервер еще на полчаса в отрубе. Вот что бывает когда кто-то не продумал все возможные варианты использования его поделия.
Про read timeout что-нибудь слышал?
Ну и да - чанк не обязательно читать целиком, снова растожаберство какое-то в голове :)
Тут вся суть в том. Как отличить добросовестное использование от недобросовестного. Если это обычный http запрос с Content-Length, то довольно просто выделить буфер и установить таймаут. Если это Chunked, то придется устанавливать эти правила для каждого чанка. Что гораздо затратнее.
Чичиго?
> Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнениюЭ-э, там, в той самой библиотеке, для этого есть aggregate - читает в буфер, размер буфера устанавливается по вкусу. Кто ж виноват, что нельзя никак заставить использовать именно это API?
Можно посмотреть как эту проблему решили высокооплачиваемые программисты из 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
как эту проблему решили опеннет эксперты тоже хотелось бы посмотреть, но вряд ли кто-то из них сможет показать код
и вообще смог понять что за проблема
Это норм. Просто макакинг-девелопмент
Чудесное определение — "особенность работы с памятью". Запомню.
ой как интересно получилось
Ой какой длинный список получается
"Программы на Rust текут из-за особенности работы с памятью."
> "Программы на Rust текут из-за особенности работы с памятью."Нет, зато опеннетные экспертусы-по-всему не владеют даже элементарной терминологией.
Сишник забывает очистить память в указателе
растоман: диды писали, надо переписать на растрастоман: забывает проверить входные данные и вообще весь ответ целиком копирует в буфер.
опять растоман: это задокументировано!
> растоман: забывает проверить входные данные и вообще весь ответ целиком копирует в буфер.Питонист, расскажи куда его еще копировать, заодно выдай, каким должен быть "разумный" ограничитель по дефолту.
> опять растоман: это задокументировано!Дорогой питонист, естественно это задокументированно, потому что у разных проектов могут быть разные потребности относительно "разумности" величины входящих данных.
UB в ANSI C тоже задокументировано.
>> Checking the Content-Length is a possibility, but it is not strictly mandated to be present.
> UB в ANSI C тоже задокументировано.А в огороде бузина.
Да нее, тут опять сишники виноваты
Не тут. Но виноваты, конечно.
Помнится си критиковали за то что программисту нужно слишком много думать и знать и о многом заботиться. И что раст сейчас придёт и возьмёт всё на себя. Но чуда не случилось, зато мелкософт и гугл (текущих владельцев раста) захватили ещё немного влияния.
>> Примечательно, что указанное поведение явно описано в документации, в которой рекомендуется выполнять отдельные проверки размера
> И что раст сейчас придёт и возьмёт всё на себя. Но чуда не случилосьОчередная перепись не читающих дальше заголовка?
Это уже новая риторика. Изначально было "раст все порешает" и "программисты не будут совершать ошибки".
Потом было "мы ещё сырые, но вот ещё чуток подпилим".
Сейчас вот "раст не виноват, это всё...".
Собственно всё это мы уже проходили с джавой, а единственный результат который получили это зависимость от корпораций (в данном случае гугель и мелкософт).
> Изначально было "раст все порешает" и "программисты не будут совершать ошибки"Где это заявлялось?
> Это уже новая риторика. Изначально было "раст все порешает" и "программисты не будут совершать ошибки".Ой звездуны-ы-ы-ы... Вкладывать свои слова и мысли в уста оппонента и потом с пафосом опровергать их - это уже дно, второе, после первого, в которое постучались снизу. Раст порешает только (примерно-условно) 70% проблем, определенные ошибки работы с памятью, да и то, с одним условием - никакого unsafe-кода. Даже взаимодействие с твоим "божественным си" через (ансейфовские) врапперы хоть и локализует проблему, но сводит часть работы на нет. Ну даже ложка дерь... дегтя бочку меда портит. Тем больше стимул заменять всё на мёд и не взаимодействовать с дёгтем. Просто дёготь пока везде вокруг, но это не повод сложить руки и отказаться от прогресса. Всё новое пиши на мёде, старое на дёгте, если еще хоть немного сопровождаемо, тяни дальше.
У Си уязвимости, а у Раста ОСОБЕННОСТИ работы с памятью, понимать надо.
Говори толерантнее, иначе к тебе приедет айнзац-команда и до реанимации будет учить тебя политкорректности: у раста не особенности, у раста ЗАДОКУМЕНТИРОВАННОЕ ПОВЕДЕНИЕ.
Эх, видимо, рано я порадовался за питониста. Эй, питонист. Не у Раста, а в стандарте такое поведение. Надеюсь, ты понимаешь разницу между стандартом и языком программирования? Или я опять слишком многого прошу?
Способность обращаться по любому адресу памяти это нормальное поведение кода, исполняющегося на процессоре.
С точки зрения процессора - да, нормальное. А с точки зрения программиста, который в здравом уме находится - нет, не всегда это нормально, и часто это надо пресекать.
Не любого кода. Подавляющая часть программ (состоящих из данных и кода) категорически не должна иметь доступ _по любому_ адресу памяти. С точки зрения современной (относительно) универсальной (многопроцессной, многопользовательской) операционной системы. Ну, просто как пример, ты не должен обращаться к еще не выделенной памяти. Или к уже освобожденной. Или выделенной другой программе, если у них специально разделяемую область не создал, с казино и шлю... с доступом примитивы синхронизации (семафоры и т.п.). В своих наколенных ОС-поделках воруй память наперегонки из разных программ как тебе вздумается. Т.е. подозреваю кроме как под DOS, используя хитрые "хакирские" трюки, ты ничего не писал.
> Не любого кодаТебе сказали - работающего на процессоре, а не под ОС, работающей на процессоре.
> Ну, просто как пример, ты не должен обращаться к еще не выделенной памятикем не выделенной, куда не выделенной? Вот есть у меня ядро, оно стартует, и... кто и как мне должен память выделить? MINIX3 в IntelME что ли?
> Или к уже освобожденной
еще раз - тебе уже сказали, что "Способность обращаться по любому адресу памяти это нормальное поведение кода, исполняющегося на процессоре".
Если это было бы не так, то как, черт возьми, операционки будут на процах исполняться?
>ЗАДОКУМЕНТИРОВАННОЕот слова "док", как в док-станции?
Тебе далеко пока до Евгения Вагановича. Тренируйся ещё.
Уязвимость, но не в Rust и даже не в библиотеке Hyper, а в тех серверах, которые реализовали ошибочную логику.
В Си тоже нету уязвимостей, они могут встречаться в софте на нем написаном
Мда, это даже смешно.
Это поведение не только записано в доке, там даже пример есть с комментом "// Just to protect ourselves from a malicious response"И из всех проектов которые использую hyper нашлась тройка особенных которые на это забили, причем один из которых - участник web-frameworks-benchmark - которые известны "победа любой ценой".
Просто для "оценки значимости" этих проектов - у хипера 68кк загрузок и примерно 60-100к ежедневно.
Внимания заслуживает наверное только axum у которого в 10 раз меньше общих загрузок и где-то в 3-5 раз меньше ежедневных. Потому что у Сальво же - 1600 ежедневно (да, просто 1600, без к), а у кондуита - вообще в пике 45 в день.
Т.е. кому-то было не лень найти эти проекты и написать об УЖАСНОЙ УЯЗВИМОСТИ!!!111
Кондуит конечный продукт, естественно у него будет меньше загрузок с сайта «библиотек», странно сравнивать.
> на языке Rust, выявлена
> особенность работы с памятьюДа ну ладно?!
Ещё один подражатель Евгения Вагановича. Такая популярная на Опеннете личность, кто бы мог подумать.
> Ещё один подражатель Евгения Вагановича. Такая популярная на Опеннете личность, кто бы
> мог подумать."Но как, Холмс?!"
Галустян, залогинься.
When lights go down, I see no reason
For you to cry, we've been through this before
In every time, in every season
God knows I've tried
So please don't ask for moreCan't you see Rust in my eyes?
That this might be our last goodbye
Caa-arbon
Caa-arbon
Things they change my friend, whoa oh
Caa-arbon
Caa-arbon
Maybe we'll meet again
Somewhere, again
Напомни, пожалуйста, какая текущая версия у Carbon? Мне гуглить лень, честно признаюсь.
создатели карбона где-то недалеко от вводной написали, что если вы используете раст - то молодцы и используйте его дальше, а этот карбон - костыль для тех, кто за всю свою жизнь только плюсы смог как-то наполовину осилить или для тех, кому уже не разгрести унаследованные авгиевы конюшни плюсплюснутых решений, которые уже не выкинуть, а переписать на чем-то другом, совершенно отличном от плюсов - жизни или денег не хватит. А вот на карбон перенести якобы значительно легче и дешевле. Как-то так.
Вот она победа раста над древней сишкой!
Растоманы накосячили с памятью и все лишь получили DoS, а не RCE-дырень с получением рута и тыреньем всех твоих данных.
Не зря его сделали, не зря его добавили в ядро!
Ну и развивали бы дальше свой победоносный redox. Нафига в сишный linux полезли?
Потому что это будет просто преступлением оставить линукс таким дырявым какой он сейчас!
Да, просто за драйверами зашли. Сейчас с ними и уйдут обратно.
Никто уже никуда не уйдёт, не переживай. Учить язык придётся. Хотя для некоторых это может оказаться и непосильной задачей.
Но дрова то на небезопасном Си, все равно их переписывать с нуля надо
Redox - это почти домашний проект, просто чтобы убедиться, на данном языке можно писать системный софт.
Полезли в сишный Линукс, потому что последний стал очень распространённым, что означает, что каждая ошибка программиста очень дорого обходится в итоге конечным пользователям. И с этим надо что-то делать. Раст оказался как нельзя кстати.
А можно написать еще хотя бы одну библиотеку для работы с HTTP, а то что-то свет клином столкнулся с этим Хайпером.
Бугагашно, чанк по частям мегабезопастные кодеры читать не научились? :D
(так-то вообще школьная ошибка, чтение из сети по заданному размеру без лимитов...)
О великий эксперт. А где ты потом собирать будешь эти чанки? Почитай на досуге про UDP, например.
Никогда не останавливайся на полпути, позорься до конца!Ты хотя бы посмотри как чтение кусками из UDP реализовано в популярном софте. Боже, растоманы РЕАЛЬНО думают, что UDP весь(!!!) целиком(!!!) надо прочитать в мега-огромный-буфер прям из сети?
Упоминание UDP - это была попытка намекнуть, что не все так просто, как сишники себе вообразили.Заодно предлагаю тебе поразмыслить (понимаю, для сишников это сложная когнитивная задача, но ты хоть попытайся) , что в данном конкретном случае речь идёт об универсальной БИБЛИОТЕКЕ, а не о конечном продукте, который, конечно, знает, что ему следует ожидать из сети, а что может игнорировать.
Хорошее упоминание. Ты собрался весь поток UDP за неизвестный период в память тащить, или всё-таки будешь его "клиенту" отдавать, чтобы тот решал сам, что с ним делать?
Собственно об чём и речь. УНИВЕРСАМНАЯ либлиотека оказалась ни фига не универсальной, а заточенной только на очень специфичный вариант применения - когда всё в память помещается. Растожабаскриптерство - оно такое.
Если ты туда всунешь какой-то лимит на размер буфера она перестанет быть универсальной. На малинке с 2Г оперативы для кастомной программы там одни лимиты будут, для суперкомпа с терабайтом оперативы в защищенном периметре, где к нему не обращаются неавторизованные хосты и программы - другие лимиты. А так впендюришь ты 640KB и скажешь - "этого должно хватить на всё! Универсально!". Универсальность как раз в том, что её могут использовать по разному, под разные нужды. Проблема в том, что кто-то не прочел документацию и не проникся этой универсальностью создавая уже свой продукт. Тут уже от ЯП не зависит. И чего я бисер мечу перед вами...
Ты в курсе, что лимит может быть конфигурируемым со стороны клиента?
> Собственно об чём и речь. УНИВЕРСАМНАЯ либлиотека оказалась ни фига не универсальной,
> а заточенной только на очень специфичный вариант применения - когда всё
> в память помещается. Растожабаскриптерство - оно такое.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И зачем ты так громко пустил метан в лужу?
Жаборастера видно издалека, да.
Собирать будет "клиентский" код - там, где ему надо. С лимитами и т.п.
Простая проблема мерзкого дизайна. Либа должна отдавать не весь контент целиком, если он большой, а его куски, наподобие read(), с предзаданной длиной. Тогда и чанки будут читаться кусочками, и сборка будет мягкой и шелковистой. Зачем например тащить в память весь гиговый файл, если его можно на диск кусками писать?
И чего?
У меня сейчас допустим есть асинхронная корутинная реализация HTTP на PHP.
Она вполне себе клиенту что хедеры, что контент в обе стороны отдаёт кусками - через эксплицитный запрос на чтение. Кусками читает с сокета, кусками парсит (попутно применяя лимиты на те же хедеры, чтобы многомегабайтный хедер не скушать), и кусками же отдаёт по readHeader() / readHeaders() / readContent(). Клиент сам решит, что делать с очередным куском - буферизовать или свалить куда-либо.
А для универсальности там же есть - readAllHeaders() / readFullContent(), первое читает с лимитом, второе - когда длина контента клиенту уже известна, и клиент хочет всё целиком. Внутри это просто обвязка к вышеупомянутым.
> Бугагашно, чанк по частям мегабезопастные кодеры читать не научились? :DБугагашно, читать дальше заголовка местные Воены Супротив Раста так и не научились?
https://docs.rs/hyper/latest/hyper/body/fn.aggregate.html
А ты по ссылочке-то пробовал пройти?This may require copying the data into a single buffer. If you don’t need a contiguous buffer, prefer the aggregate function.
С английского перевести, или сам осилишь буковки?
Пациенты клиники Кащенко в комментах в полном сборе."Но вы же гаварили что в расте нет проблем а тут праблемка ихихихихихих" - пишут они на разный лад в новости про задокументированное поведение http библиотеки.
Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано. А из какой клиники сами будете?
>Ну то, что си по умолчанию не проверяет границы массивов тоже задокументированоЕщё один сравниватель Си с реализацией конкретной библиотеки. Как-то много вас развелось. Подозрительно много.
>>Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано
> Ещё один сравниватель Си с реализацией конкретной библиотеки. Как-то много вас развелось.
> Подозрительно много.Подозрительно много тут только твоих комментариев.
Ты читать умеешь? Проблема в библиотеке ебтвм, можешь форкнуть и поправить если хочешь. Но больные люди видят ключевое слово "раст" и ну никак не могут сдержаться.
> можешь форкнуть и поправить если хочешьНоваторство в борьбе с уязвимостями.
Очевидно, и читать, и писать он умеет. А вот с осмысливанием прочитанного у него явные проблемы, как и у 90 процентов здешних комментаторов.Вы бы поберегли нервы, всё равно же ничего этим людям не докажете. Они очухаются только тогда, когда жизнь заставит. Но к тому времени уже может быть поздно.
Строго говоря, это не проблема библиотеки Hyper, это проблема тех нескольких серверов, которые её лениво используют. В Hyper есть возможность как читать все в один присест, так и читать кусками. На выбор вызывающей стороны. Просто кто-то сделал неверный выбор.
У чтения в один присест должны быть лимиты.
Потому что всем, кроме хрустоманов, очевидно, что доступная память - не резиновая.
Еще скажите, что у обращения по индексу всегда должна быть проверка выхода за границы. Потому что размеры буфера не бесконечны.
Только в случае, если индекс зависит от пользовательского ввода.
Проверять границы буфера во внутреннем обходном цикле - так себе затея :D
В цикле и так будет проверка на каждом шаге условия достижения конца цикла. Чтобы проверку не дублировать ещё и при непосредственном доступе по индексу, и при этом не жертвовать безопасностью, лучше использовать итератор вместо прямого доступа.
Проверка на каждом шаге условия?
Ну удачки, чего.
Есть допустим у меня кадр. 7680x4320.
Мне его надо вдоль и поперёк обработать, согласно пользовательскому вводу.На каждом шаге проверять выход за пределы буфера? Итераторы?
Жабоскрипт и прочие расты ГМ, однако. В здравом уме - проверяется однократно до обработки.
Ваше предыдущее сообщение было про цикл. Как вы себе представляете цикл без проверки условия выхода?
Между проверкой условия выхода и проверкой границ есть небольшая разница, не?
Мы(пациенты) смеемся не с новости, а с ваших попыток оправдаться. Особенно смешно это читать после ваших набегов на темы вида "Уязвимость в коде на Си в проекте Х...", где каждый писал что-то в духе
>ряяя дырявая сишка, швятой хруст бы помогхотя разрабы просто забыли поставить сравнение и патч выглядел в одну строчку. Пытался найти ссылку на эту тему, но наткнулся на другую:
https://www.opennet.me/opennews/art.shtml?num=56551
>Ваших попыток оправдатьсяПонятно.
Этого пока рано выписывать.
>Понятно.А разве это не так?
Происходит жирный наброс в духе "Ха, самый безопастный язык не помог, растаманы слились"
И тут же десятки опрадвний на это сообщение:
>Ряяя вы ничего не понимаете, раст не виноват
>тупые сишники, ряяя
> пук-среньк, это библиотека виновата
> и т.д.
Какие оправдания? Это (безуспешные) попытки объяснить недалеким, что вообще-то так оно и должно работать. Если в мануале написано что rm -rf удаляет папку и проверьте что вы туда передаете, чтобы не сжечь свой стул, то те кто это не делают ССЗБ.Разве эти можно сравнить с оправданиями при разыменовании null или при очередном выходе за границы массива с получением рута? Хотя в последнем случае, оправдаться пытаються только самые клинические сишники...
>Какие оправдания?Которые ты написал...
Чтобы убедиться, что в том случае растоманы действительно были неправы (если они такое писали), нужно найти новость и понять, не вызывала ли подобная ошибка сравнения в С далее обращение к уже освобожденной памяти или к выходу за пределы буфера. Сама по себе логическая ошибка сравнения может быть допущена как в Rust, так и в С. Но важен также контекст и последствия, к которым приводит эта ошибка: возможно в Rust действительно просто не было бы смысла/возможности писать такой код, который бы привел к порче памяти из-за подобной логической ошибки.
А у тебя как всегда сишники виноваты.
> Пациенты клиники Кащенко в комментах в полном сборе.Тут согласен, пациенты клиники Кащенко пишут, что чтобы избегать какой-то тип ошибок нужен новый язык
То ли дело молиться, что всё порешают линтеры, санитайзеры, да прямые руки.
Толи дело написать язык, на котором ничего невозможно написать.
Хах растобезопасность снова превратилась в тыкву
Безопасность Rust'а? Или безопасность Hyper? Или безопасность Axum, Salvo и conduit-hyper? Перечитайте новость внимательно.
> Хах растобезопасность снова превратилась в тыквуКакая именно безопасность? Боров-чекер перестал работать?
Кстати, новость написана правильно. А вот комментаторы неверно интерпретируют сказанное. Тут нет уязвимости в Rust, даже нет уязвимости в Hyper. Но есть уязвимость в нескольких проектах, построенных на Hyper.
Ваш растопроект вылетел в DoS из-за непроверки входных данных? Знаете кто виноват? Нет, не Раст, который декларировал безопасность работы с аллокацией, и не Hyper, который не делает проверок входных данных, но только документирует это. Виноваты ВЫ - потому что доверились сказкам растоманов про безопасность кода и выключили голову, когда писали свой проект, опираясь на библиотеку, которая в перекладывает проверки на клиента.
Rust и растоманы нигде не обещают избавления от логических ошибок. Те гарантии, которые давал Rust, он их не нарушил: никакой гонки не произошло, никто не вышел за пределы буфера, не обратился к неинициализированной памяти и пр. Остальное - это уже ваши додумки и домыслы тех, кто Rust и не видел вовсе, и даже дня на нем не программировал, судя по всему.
Прикол в том, что в Расте вероятность совершить логическую ошибку повышается из-за того, что даже простейший код раздувается до ненормальных размеров. Это не говоря уже о том, что приходится структурировать код не в угоду читабельности, а чтобы угодить компилятору. Ну и не стоит забывать про сумасшедший синтаксис
Код раздувается из-за того, что развитая строгая типизация требует больше явных проверок и обработки всех веток на месте. Из-за этого же наоборот, вероятность совершить ошибку понижается.То есть, вы цепляетесь за свойство, что кода становится больше, поэтому вероятность ошибки выше, но вы упускаете из виду, что кода становится больше из-за большего количества проверок, которые требует компилятор. То есть программисту приходится думать обо всех вариантах в данном месте и явно их обрабатывать, что наоборот, должно понижать вероятность ошибки.
Я говорю о ЛОГИЧЕСКИХ ошибках
Так я тоже о них говорю. Обработка не всех вариантов - в общем случае ведет к логическим ошибкам.
+1. Причём "растаманить" на их неуклюжем языке в 2 раза сложнее и они это оправдывали повышенной безопасностью. Так накой мне лишний геморой, если всё равно раст дырявый?!
Даже С++ со смарт указателями стократ надёжнее.
Вызвать команду на загрузку всех данных в память и обвинять язык в том что память закончилась это какой-то особый способ идиотизма.Вывод. Не верь сказкам растоманов и джаваманов о том что их языки безопасные. Пиши на ANSI C где даже элементарные арифметические операции продолжают неопределенное проведение.
> элементарные арифметические операции продолжают неопределенное проведениеболобол
Когда новость про ошибки в программах на расте не связаны с самим растом, у наСИльников особенно ярко и гулко полыхает. Что только подкидывает в копилку надежности и нужности раста: вот, очередная ошибка! ан нет, не переполнение буфера, не обращение к невыделенной/освобожденной памяти, не двойное освобождение. Это пока не пропускается, если только с сишным легаси не взаимодействует. Просто знаки больше-меньше перепутали или входные данные не проверили. Отрадно. Так держать. Не, понятно, никто не безгрешен, наверное раз в пятилетку проблемы с памятью и от самого раста будут находить, но я готов это терпеть.
Это не очень на пятилетку похоже(удивительно как много ошибок в стандартной библиотеке и тулчейне):
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
Ну и хотите верьте, хотите нет, но мне не будет легче если программа просто упадет, займет всю память или даст рут-доступ, но ЗАТО безопастно и не портя память.
Конечно верим, потому что сразу видно админа локалхоста...
Тебе будет легче если она не упадет и продолжить работу, но при этом твой диск зашифруют? или бд утечет? или просто станет частью ботнета?
>при этом твой диск зашифруют? или бд утечет? или просто станет частью ботнета?А что мешает это сделать из под раста, если возможность получения рут-доступа никуда не исчезла?
Как получить рут-доступ, если сервер замедлился или упал из-за перерасхода памяти?
>Как получить рут-доступ,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(). В случае применения данной функции для удаления временных файлов в привилегированном приложении злоумышленник может добиться удаления произвольных системных файлов и каталогов, к удалению которых в обычных условиях у атакующего нет доступа.
Эти случаи уже много раз обсудили, обмусолили и сделали выводы. Давайте здесь обсуждать тему топика и не перескакивать, а то иначе не понять, кто что имеет ввиду и о каких проблемах вообще говоря речь. Проблема, вызванная отсутствием проверки реального объема загружаемых данных и попыткой резервировать большой кусок памяти, никак не приведет к повышению привилегий в системе.
>4:19: Какой рут? Из под раста нельзя ничего подобного получить
>приносятся ссылки
>4:20: Это уже сто раз обсудили, так что давайте не будем переводить тему, да и вообще забудем про данный разговор, ничего не было. Раст швятойКлассика.
Нужен новый язык. Раст решает не все проблемы
Новый будет создан на основе Раста и с учетом его преимуществ и недостатков. Ещё не скоро.
Rust with classes, Objective-Rust, Rust++
Ты ещё в сортах уязвимость разбираешься? Типа когда тебя взломают через неправильный знак это что будет смягчающем обстоятельством? Да пофиг тебе уже взломали.
А где обычная приписка, что Раст позволяет избегать ошибок и т.д.
Будет в следующий раз. А когда ты дашь ссылку на эту новость тебе скажут что ты всё врёшь.
Это другое
> А где обычная приписка, что Раст позволяет избегать ошибок и т.д.Он и без приписки позволяет избегать.
Клоун, ты новость читал? Или сразу в каменты как адвокат ржавого прибежал?
Клоун тут только ты: ошибка из новости не имеет никакого отношения к memory safety.
Когда же вы поймёте что самый безопасный язык это Carbon
Когда пройдет фанатизм == никогда.
Не ври, most wanted лучше!
> копирующая данные запроса и ответа целиком в один буфер без проверки размера полученных данныхЧто и требовалось доказать: баги полностью зависят от криворуких погромиздов, язык не причём.