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

Хер бы с ними со скриптами, ембеддед пострадаеть.

Блин, опять transmission пересобирать...

Очередной гвоздь в крышку гроба репутации сишки

Не пострадает. У сишки только такая репутация и есть.

Очень много чего пострадает. И поделом.

Ты попробуй это упертым сишникам объяснить. Будет же стандартная мантра про то, что все вокруг πдорасы и не умеют в Божественную Сишечку

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

Мейнтейнеры дистрибутивов оповещены, детали 11 октября.

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

Какое же убогое зрелище эта ваша сисюрити.

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

Может, но я почему-то думаю, что там опять переполнение

А я так и не понял зачем нужен курл. Ни разу им не пользовался.

А чем делать запросы в REST API?

Конечно не умеют. Это очень острый инструмент. Не умеешь не берись. Если надо, обмажся статическими анализаторами вместе с MISRA и живи спокойно.

Откуда запросы и какая разница какое там апи?

Тебе надо сделать HTTP запрос и получить ответ, твои действия?

telnet. И да, еще нужно научиться писать с клавиатуры запросы и читать ответы в формате SSL, но это так, мелочи

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

Только wget, только хардкор!

Во-первых, наверно не только http, а ещё и https иногда. Во-вторых, зависит от языка и платформы. В-третьих, для этого точно не нужен комбайн, который умеет ВСЕ протоколы.

Из того, что я делал:

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

2) всякое на пхп: file_get_contents() для простого (оно не поддерживает POST и не возвращает заголовки ответа), fsockopen() или stream_socket_client() для сложного (полный контроль)

3) на си под unix, http: если не нужен https то socket(), bind(), connect(), шлём запрос send() и читаем ответ recv()

4) на си под unix, https: вместо сокетных операций openssl-обёртка (я её засунул в отдельный процесс т.к. openssl дырявое, и наружу она видна как всё тот же сокет)

5) на си под оффтопик, https: include <winhttp.h>

MISRA

https://en.wikipedia.org/wiki/MISRA_C#Categorization

Avoiding using functions and constructs that are prone to failure, for example, malloc may fail

Ну-ну. За пределами эмбедеда это мало применимо. Где увидеть сишную реализацию, например, списков, не использующую malloc() или realloc()? Вот, авторам sway понадобились списки. И результат realloc() никто не проверяет. Тупо присваивают этот результат указателю на уже используемую память в куче. Это, скорее всего, не уязвимость, но sway тупо упадет с сегфолтом, если realloc() вернет NULL. А пользователь долго будет ковыряться в попытках понять, почему у него внезапно рухнул оконный менеджер

Наверняка пользовался косвенно, используя софт, слинкованный с libcurl.

А сам curl удобен чтобы делать запросы и получать ответы в CLI. Я часто юзаю (больше в скриптах), но могу представить, что он не каждому нужен.

Наверняка уязвимость задевает не только утилиту, но и либу, и вот это самое неприятное в данной новости.

Где-нибудь в HTTPS

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

curl поддерживает гораздо больше фич, методов аутентификации, компрессию. Curl - стандарт же факто, а wget удобен просто для скачивания файлов.

3. на си под unix, http: если не нужен https то socket(), bind(), connect(), шлём запрос send() и читаем ответ recv()

Ну т.е. переизобретаешь колесо, ну ОК.

Ну т.е. переизобретаешь колесо

Это не всегда плохо, особенно если в приоритете минимализм и контроль над кодом.

Avoiding using functions and constructs that are prone to failure, for example, malloc may fail

Ух ты, а я тоже malloc стараюсь избегать. Ну то есть - не фанатично его истребляю в ущерб функционалу, но если можно без него - делаю без него.

Где увидеть сишную реализацию, например, списков

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

но sway тупо упадет с сегфолтом

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

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

Блаблабла. Покажи мне списки без malloc()/realloc(), а блаблабла мне неинтересно

У тебя годный подход, но он идёт вразрез с современной экономической парадигмой, которая заключается в генерации говнища как можно быстрее

Ясен-красен лучше раскрыть не вместе с патчами и пакетами, а за неделю до них. --sarcasm

Наверняка пользовался косвенно, используя софт, слинкованный с libcurl.

Может быть, мимоходом. Основные потребители http - браузер и apt, они курл точно не используют. Ну и выше указанные способы обратиться к сайтам, которые я сам использую. Раньше использовал transmission (тут писали что он зависит), но он глючный и я перестал. Потом использовал qbittorrent вместо него, у него в ldd курла не вижу. Кто ещё может лезть на сайты (видимо тайком) - не знаю, но если выявлю такие проги (не важно, курлом или как, важно что тайком) то приму меры чтоб они это не делали.

А да забыл, yt-dlp - не знаю чем он качает, может там есть.

Тут палка об одном конце.

Если он упадёт с понятной ошибкой «out of memory» - будет не сильно лучше

Нет. Будет лучше. Будет сразу понятно, что произошло. И да, sway – это частный случай, это проект, код которого я изучал (хоть и поверхностно). Не всегда имеет смысл завершать работу из-за невозможности выделить дополнительную память. Но даже если продолжать работу бессмысленно, программа должна корректно завершатся. А не падать с сегфолтом.

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

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

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

Ну т.е. переизобретаешь колесо, ну ОК.

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

но он идёт вразрез с современной экономической парадигмой

Он идет в разрез с нормальным программированием и написанием качественного кода, а не с экономической парадигмой.

Осиль прочитать следующее предложение в моём комментарии и прекрати спорить со своими выдумками.

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

По старинке, телнетом или s_client и ручками, ручками, всё как диды завещали :)

Лучше осиль мой комментарий. Сегфолт при невозможности выделить дополнительную память – это признак говнокода. Мне насрать, что в конкретном примере со свайкой это может не иметь серьезных последствий.

И да, почему это вы с yax123 отмалчиваетесь на счет реализации списков без malloc()/realloc()? Примеры будут, или нет?

то результаты не оч похожи на качественный код

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

По-твоему, подход firkax позволит генерировать качественный код? copypaste-driven development и отрицание модульного программирования и переиспользования кода – это теперь best practices? Ну ок.

Ты всё-таки не осилил его прочитать. Если бы осилил, то увидел бы, что я полностью согласен, что лучше результат проверять и выдать осмысленное «out of memory» вместо сегфолта (на всякий случай: там дальше ещё есть текст, лучше всё-таки дочитай). Но ты прочёл одну фразу и начал фанатично спорить со своеё её интерпретацией, забыв про всё остальное.

Нет смысла использовать код, 90% которого тебе не нужны, иначе это и есть говнокодинг, по-моему.

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

Ааааааа, ору ) Т.е. malloc избегаешь и делаешь свою реализацию malloc? Типикал сишник с переизобретением криво-косо слепленных велосипедов для каждого проекта.

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

А потом мы удивляемся, что очередное чудо обосралось на самописном strsplit.

Вот тебе пример: .h .c.

Ещё раз уточню: это не «реализация списков просто так», это именно реализация конкретного списка (точнее, списка+хеш-таблицы) для конкретной задачи, без лишних абстракций.

В большинстве ЯП деление на ноль не приводит к уязвимости.

Мдя. Вы там все аутисты чтоле?

Никто не спорит с тем что Си очень опасен. Очень опасен. Но это не значит, что им нельзя пользоваться. Пользуйся, просто будь щепитилен.

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

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

Все остальное, это следствие завышенных ожиданий.

представь, что сишечка это как ассм присыпаный сахарочком

Зачем представлять, разве по факту это не так?

• xh
• любой другой HTTP-клиент твоего ЯП
• встроенный HTTP-клиент твоего шелла

Хотя я в курле ничего плохого не вижу.

Если для тебя это очевидно, это замечательно.

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

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

Очередной гвоздь в крышку гроба репутации сишки

В двух предыдущих тредах про уязвимости сишки «анализаторы» прибежали со своей серебрянной пулей, но очень быстро сдулись, когда им указали, насколько их «анализаторы» реально полезны. Жду очередной итерации.

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