LINUX.ORG.RU
ФорумTalks

curl уязвим, но я вам не скажу, какие версии

 


0

4

Разраб (?) curl оповестил о том, что в curl найдена серьёзная уязвимость, жутчайшая за много лет. Мейнтейнеры дистрибутивов оповещены, детали 11 октября.

https://github.com/curl/curl/discussions/12026

I cannot disclose any information about which version range that is affected, as that would help identify the problem (area) with a very high accuracy so I cannot do that ahead of time. The "last several years" of versions is as specific as I can get.

We have notified the distros mailing list allowing the member distributions to prepare patches. (No one else gets details about these problems before October 11 without a support contract and a good reason.)

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

★★★★★

Последнее исправление: seiken (всего исправлений: 1)
Ответ на: комментарий от seiken

А какие ваши доказательства, что данная уязвимость вообще от ЯП зависит? Может быть, там, грубо говоря, на ноль делят…

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

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

byko3y ★★★★
()
Ответ на: комментарий от yax123

Если надо, обмажся статическими анализаторами вместе с MISRA и живи спокойно.

Это классная история для тех, кто не знает ничего про статические анализаторы и MISRA. MISRA — это заранее помойный мусор, он только морочит голову, не предоставляя никаких гарантий. Статические анализаторы могут гарантировано определять ошибки, но только ограниченный набор оных в достаточно простом и статически вычисляемом коде.

byko3y ★★★★
()
Ответ на: комментарий от ox55ff

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

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

seiken ★★★★★
() автор топика
Ответ на: комментарий от firkax

для шелла: wget/fetch

curl более заточен на отправку запросов, например он по дефолту выводит ответ в консоль, а wget сохраняет в файл, потому что он качальщик.

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

xh

xh is a friendly and fast tool for sending HTTP requests. It reimplements as much as possible of HTTPie's excellent design, with a focus on improved performance.

переписали какой-то HTTPie на Раст ради производительности. На сколько оно сыро не знает даже краб с логотипа, всё это несравнимо с curl.

seiken ★★★★★
() автор топика
Ответ на: комментарий от yax123

Никто не спорит с тем что Си очень опасен

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

Никто же не хейтит ассемблер за то, что он может сделать больно?

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

hateWin ★☆
()
Ответ на: комментарий от goingUp

Это совершенно незначительно. wget -O- если надо в консоль. Всё, что может потребоваться шелл-скрипту в плане http/https, wget умеет, и нет причин искать вместо дефолтного линуксового качателя другую прогу.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Это местный Дон Кихот, виртуоз борьбы с ветряными мельницами

alex1101
()
Ответ на: комментарий от yax123

Опять необоснованно завышенные ожидания от реальности?

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

hateWin ★☆
()
Ответ на: комментарий от firkax

Какие фантазии? Почитай хоть новости про раст в ядре и посмотри, сколько там сишкофанатиков-всепропальщиков

hateWin ★☆
()
Ответ на: комментарий от firkax

curl более дефолтный) Вот не помню дистр, wget надо было доустанавливать а курл уже был. В гугловском апи есть примеры, как дернуть с помощью курла, но для вгета нету.

Но, конечно, если ты уже освоил вгет, то переходить смысла нету)

goingUp ★★★★★
()
Ответ на: комментарий от hateWin

Фантазии в том что кто-то чего-то там превозмогает, в том что кто-то предлагает «писать всё» на си. Ну и постоянные обобщения чьих-то фанатских заявлений на язык, которым они пользуются.

Касательно ядра - мне почти пофиг.

firkax ★★★★★
()
Ответ на: комментарий от byko3y

Да, я наверно был через чур строг сказав «живите спокойно». Конечно не спокойно, так как указанные мной инструменты не решают всех проблем, а наиболее распространенные.

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

Насчеть «мусора» и «морочит голову», опять завышенные ожидания?

У вас там, что ли у всех такая попаболь? Ошибки в коде на си разрушают ваш идеальный манямирок?

yax123 ★★★★★
()
Ответ на: комментарий от goingUp

Ну может от дистра зависит. В дебиане wget всегда был что я его видел. Впрочем я недвано делал debootstrap дебана с 8 по 12 и в последних версиях кажется по дефолту и wget тоже не было.

освоил вгет

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

С libcurl слинковано реально многое, даже если он там используется для какой-то малозначимой фигни. В том числе, например, целая куча игр. Или git. Или, например, какой-нибудь OBS Studio (там http(s) надо для стриминга. И даже если юзать не для стриминга, либа то всё равно слинкована. И мы пока не знаем, как юзается уязвимость)), poppler тоже почему-то зависит от curl, и даже rust. Также всякие IRC-клиенты, торрент-клиенты. Ещё в зависимостях глянул, почему-то от curl зависит ещё и feh, например, а ещё хз зачем, но vorbis-tools.

Что касается списка используемого — хороший список. Однако для шелла wget не заменяет curl полностью. Правда сейчас я не вспомню, чего конкретно мне в нём не хватало…

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 2)
Ответ на: комментарий от hateWin

Для меня термины «опасность» и «дерьмо» несколько ортогональны. Одно из другого не следует. Поэтому к таким рассуждениям отношусь как чему-то незаслуживающего внимание.

Дальше. Что такое «подавляющая масса современного кода»? И что такое нормальные языки? Я бы сказал, что современное по как раз и есть то самое дерьмо, причем оно сразу такое задумывалось. А на сишечке задумывалась конфетка. Но да, писали люди, а они не совершенны.

Насчет уникальных возможностей. Наверно тут в удачном уровне абстракции от железа. Именно в этом заключается «уникальность». Чуть выше или ниже, и уже будет не то. Поэтому все эти ваши «перлы» и «рельсы» все уже забыли, а сишечка еще долго будет коптить мир. Именно как удачная абстракция. А любой заменитель сишки всегда будет ее косплеить и по факту либо это будут те же яйца в профиль либо замороченная высокоуровневая абстракция за лесом которой не видно деревьев.

Сишка сильна своей идеей, а не плохостью реализации этой идеи в конкретном стандарте или компиляторе.

yax123 ★★★★★
()
Ответ на: комментарий от hateWin

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

yax123 ★★★★★
()
Ответ на: комментарий от yax123

Наверно тут в удачном уровне абстракции от железа. Именно в этом заключается «уникальность». Чуть выше или ниже, и уже будет не то.

Плюсы разве хуже?

alex1101
()
Ответ на: комментарий от alex1101

А ты уговори Макса добавить такую реакцию

mittorn ★★★★★
()
Ответ на: комментарий от firkax

Если ты будет делать универсальные абстракции на все случаи жизни, то да, сложно избегать. А если у тебя конкретная задача, ты знаешь какой длины в ней будет максимально список, и эта длина не конкурирует с другими потребителями памяти - то выделяешь под неё всю память заранее, и «аллоцируешь» элементы из этого массива. Можно даже статически его задать на этапе компиляции.

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

На моем текущем проекте некие сишники изобразили волшебную вещь следуя твоим правилам — безусловно выделяют 11 ГБ оперативы (именно working set) «на всякие нужды» при старте совершенно пустого сервера. Вот это энтерпрайз! Зато потом внезапно не случится OOM (он возникнет прямо на старте). Жаль, что нельзя сразу на этапе компиляции выделить 100 ГБ на все случаи жизни.

Если он упадёт с понятной ошибкой «out of memory» - будет не сильно лучше. Хотя конечно лучше. Но тут речь, думаю, про другое: он вообще падать не должен. Во-первых, если закончилась память, надо отказать в добавлении элемента в список, но продолжать работать с остальных аспектах.

Юникс традиционно не умеет обрабатывать ситуации исчерпания памяти. Потому что overcommit, а он, в свою очередь, нужен по причине использования fork (иначе любой крупный процесс при попытке форка уткнется в OOM), а раз уж такая петрушка пошла, то еще куча софта стала аллоцировать страницы и не использовать их — в общем, большая часть никсового софта без overcommit работать не умеет.

Реально первые, кто как-то пытался решить эту проблему, был гугл со своим cgroups, которые как бы делили большой сервер на маленькие серверки каждый со своим заданным объемом памяти, за счет чего падал отдельный превысивший лимит процесс, а не самый жирный в системе (который часто является одним из важнейших, вроде БД).

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

byko3y ★★★★
()
Ответ на: комментарий от alex1101

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

yax123 ★★★★★
()
Ответ на: комментарий от yax123

очень далеко уходят в своих абстракциях от железа и системы

Это приводит к оверхеду или проблемы в чём-то другом? В плюсах же вроде абстракции с нулевой стоимостью

alex1101
()
Ответ на: комментарий от alex1101

Код пишет кожанный мешок, а он не может рассуждая на уровне std::cout думать к какому ассму это приведет. А это примитивный ввод-вывод. А если мы там контейнеры шаблонами обмажем и в лямбды засунем, то в голове уже ничего не удержишь. Поэтому мы вынуждены доверять авторам языка, которые должны за нас все внутри сделать быстро и безопасно. А тут сюрприз, авторы тоже кожанные мешки. И опять по новой, говнокод в библах.

yax123 ★★★★★
()
Ответ на: комментарий от byko3y

На моем текущем проекте некие сишники изобразили волшебную вещь следуя твоим правилам — безусловно выделяют 11 ГБ оперативы (именно working set) «на всякие нужды» при старте совершенно пустого сервера. Вот это энтерпрайз!

Я не знаю всех подробностей ситуации, но вполне возможно, что это действительно хорошее решение, несмотря на твой саркастический тон. Конкретные числа (11гб, 100гб) ни о чём не говорят, пока неизвестно чем же занимается этот сервер и в каких масштабах.

она может быть свопнута и OOM killer грохнет оконный менеджер при слишком активном пользовании свопом

На этот счёт есть mlock(). Но вроде oom-killer убивает не всегда того, кто пытается сейчас пользоваться памятью, а иногда просто кого-то кому не повезло, и с этим и правда сложно что-то сделать. Однако это всё не повод делать всё аккуратно хотя бы на уровне процессов. Тогда потом, когда oom-killer научится хорошему поведению, они сразу будут готовы к 100% стабильной работе. А ещё может быть у oom-killer-а есть настройка важных процессов которые нельзя трогать пока есть другие.

firkax ★★★★★
()
Ответ на: комментарий от hateWin

То есть вся это простыня только чтобы упомянуть раст?

Ты там выше говорил про «языки», во множественном числе, еще что-то кроме раста есть?

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

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

Давай простой пример. Вот коллега просит меня на мк типа stm32f1xx просит написать прошивку для включения подсветки в мерседесе. Все тупо, слушаем кан, прилетела наша цифирь, мы зажгли лампочку. Что и где мне взять чтобы все это написать на чистом расте без лишных зависимостей?

yax123 ★★★★★
()
Ответ на: комментарий от firkax

для шелла: wget/fetch

Зачем это нужно, когда есть curl?

socket(), bind(), connect(), openssl-обёртка

А если надо добавить, например, basic-аутентификацию, поддержку редиректа, работу через прокси - будешь велосипед делать? По RFC или «если на тестовом запросе работает - значит работает»?

Tanger ★★★★★
()
Ответ на: комментарий от hateWin

При всей моей любви к форту (честно), что на нем в космосе написано, кроме управления телескопами в одном отдельно взятом месте?

Где конкретно форт летает в космосе?

yax123 ★★★★★
()
Ответ на: комментарий от goingUp

curl более дефолтный)

дефолтный debian12: wget есть, curl - нет.

Tanger ★★★★★
()
Ответ на: комментарий от yax123

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

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

byko3y ★★★★
()
Ответ на: комментарий от seiken

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

Есть. Но большинство уязвимостей в индустрии вызваны именно устройством C/C++ и PHP, а не «кучей других вещей».

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Вот это поворот. Градус дискуссии повышается. Можно развернуть утверждения про «тупиковость» и не «следуют модели Тьюринга». Ну и очень хочется послушать мысли про светлое будущее, конечно.

yax123 ★★★★★
()
Ответ на: комментарий от Tanger

А если надо добавить

Где добавить, зачем? Есть конкретная задача, выполнять надо её, а не «а давайте будем поддерживать всё подряд на всякий случай».

Но на всякий случай уточню по первым двум:

1) basic auth это один заголовок - никакой логики в коде он не требует, чисто текстовая вставка

2) в редиректах нечего «поддерживать», это такие же ответы как http/200 или http/404, http-клиент должен их показать вышестоящему коду и всё, автоматически запрашивать урлы из них - максимально плохая идея, если речь идёт про какое-то встроенное апи; ты б ещё js-редиректы захотел «поддерживать» и указал на необходиомость внедрения js-движка в http-клиент для этого

firkax ★★★★★
()
Ответ на: комментарий от alex1101

Это вообще не так, даже близко.

Цэ – это типичный ЯП высокого уровня, основная идея создания которого – простота компилятора, плюс несколько синтаксических конструкций под систему команд PDP-11.

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

Чем сишка на современных архитектурах отличается от того же паскаля? Исключительно разнообразными знаками препинания вместо английских слов. Ну и тоннами UB, конечно.

quwy
()
Ответ на: комментарий от quwy

основная идея создания которого – простота компилятора,

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

Neuromagus
()
Ответ на: комментарий от seiken

Подобные требования MISRA актуальны для систем, которые заранее рассчитываются на конкретные пиковые нагрузки, конфигурируются статически и в которых не нужен malloc

Самое смешное то, что во время разработки Си почти все системы были такими. То есть, ЯП на самом деле разработан для однозадачных микрокомпьютеров (которые тогда были миникомпьютерами), а sbrk был вспомогательным вызовом для отдельных программ, работавших с большим данамическим блоком (или двумя блоками) данных.

byko3y ★★★★
()
Ответ на: комментарий от yax123

Для меня термины «опасность» и «дерьмо» несколько ортогональны. Одно из другого не следует.

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

Дальше. Что такое «подавляющая масса современного кода»?

Хотя бы ядро Linux, под управлением которого работает лоровский сервер и компьютер, которым ты сейчас пользуешься. По гитхабовской статистике выходит, что только 0.8 процента кода написано на асме. Это с учетом того, что ядро поддерживает не только x86 и там присутствуют ассемблерные вставки для многих других архитектур. в ядре NetBSD, как я подозреваю, процент ассамблерного кода еще меньше, разработчики изначально ставили цель добиться максимальной портируемости кода. В прикладном софте вставки на асме делаются, как правило, с целью выполнения оптимизаций, которые компилятор делать не умеет. Это всякая математика. Логику никто на асме не пишет.

Насчет уникальных возможностей. Наверно тут в удачном уровне абстракции от железа

Чем он такой удачный? Как, к примеру, сишные недомассивы вместо массивов в любом нормальном языке помогают разработке под эмбедед? Не говоря уже о том, что Си – далеко не единственный язык, работающий на голом железе. Есть еще ада, форт, раст. Даже на лиспе писали операционные системы, если не ошибаюсь. И на джаве банковские карты программировали. А хаскель, который компилируется в HDL, которым «прошивается» FPGA – он сильно абстрагируется от железа, или нет?

Сишка сильна своей идеей

Что это за идея такая, и чем она сильна? А компиляторы реализуют стандарт Си. В который за 30 лет не завезли даже строки.

hateWin ★☆
()
Ответ на: комментарий от quwy

Там указатели, тут указатели. Там блоки памяти, тут блоки памяти. По-моему, одно и то же по сути, хотя синтаксически разница немалая.

alex1101
()
Ответ на: комментарий от yax123

Насчеть «мусора» и «морочит голову», опять завышенные ожидания?

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

byko3y ★★★★
()
Ответ на: комментарий от yax123

Код пишет кожанный мешок, а он не может рассуждая на уровне std::cout думать к какому ассму это приведет

Кожаный мешок может попросить компилятор показать ассемблерный листинг для данного высокоуровневого кода. Кожаный мешок может добавить в компилятор оптимизации под конкретный микроконтроллер/семейство микроконтроллеров. В крайнем случае кожаный мешок может сделать вставку на асме.

hateWin ★☆
()
Последнее исправление: hateWin (всего исправлений: 1)
Ответ на: комментарий от firkax

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

Светлое будущее, которое никогда не наступит? Так же крестовики грезили идеями о том, что компиляторы C++ вот-вот научатся оптимизировать всё то, чего они до сих пор не научились оптимизировать (а без оптимизаций код на C++ очень медленно ползает by-design).

byko3y ★★★★
()
Ответ на: комментарий от yax123

Ты там выше говорил про «языки», во множественном числе, еще что-то кроме раста есть?

Так привел уже. Даже компиляторы хаскеля в HDL для последующей заливки на FPGA существуют. У джавы есть версия для эмбедеда. Есть операционная система, написанная на обероне.

hateWin ★☆
()
Ответ на: комментарий от hateWin

Не надо путать возможность и активную эксплуатацию в проде. Это я про HDL на хаскеле (хоте не спорю, идея красивая).

Жаба на эмбедеде. В чем сила жабы? И сколько из ее сильных сторон используется на симках и прочих картах? Ноль целых, хрен десятых.

ОС на обероне. Она где-то эксплуатируется для чего-то полезного кроме как просто быть запущенной ради лулзов?

yax123 ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)