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

"Переполнение буфера в curl и libcurl, проявляющееся при обращении через SOCKS5-прокси"	+/–
Сообщение от opennews (??), 11-Окт-23, 16:12
В утилите для получения и отправки данных по сети curl и развивающейся параллельно библиотеке libcurl выявлена уязвимость (CVE-2023-38545), которая может привести к переполнению буфера и потенциально к выполнению кода атакующего на стороне клиента при обращении при помощи утилиты curl или приложения, использующего libcurl, к HTTPS-серверу, подконтрольному злоумышленнику. Проблема проявляется только в случае включения в curl доступа через прокси SOCKS5. При прямом обращении без прокси уязвимость не проявляется. Уязвимость устранена в выпуске curl 8.4.0. Выявивший ошибку исследователь безопасности получил вознаграждение, размером $4660 в рамках инициативы Internet Bug Bounty на Hackerone... Подробнее: https://www.opennet.me/opennews/art.shtml?num=59909
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+2 +/–
Сообщение от Аноним (1), 11-Окт-23, 16:12
Нееет, хватит! Я уже устал ржать! - socksreq[len++] = (char) hostname_len; /* one byte address length */ + socksreq[len++] = (unsigned char) hostname_len; /* one byte length */ О мой глоб /_-
Ответить | Правка | Наверх | Cообщить модератору

	5. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+1 +/–
	Сообщение от anonymmm (?), 11-Окт-23, 16:29
	почему не uint8_t, если уж исправлять.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+1 +/–
	Сообщение от Аноним (1), 11-Окт-23, 16:31
	Возможно еще через 1315 дней можно будет получить еще 4к баксов)
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от ТОФУ (?), 11-Окт-23, 16:38
	Видимо, для поддержки легаси компиляторов. Вы удивитесь, но в некоторых опенсорс проектах можно найти поддержку даже ANSI C - C89, с кучей грязных хаков.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	44. Скрыто модератором	–1 +/–
	Сообщение от Аноним (44), 11-Окт-23, 18:01
	А как иначе? Вот у меня машина и ПО с 1999 года не обновлялись. А зачем, если всё работает? Я же не смузихлёб ради чиселок обновляться.
	Ответить | Правка | Наверх | Cообщить модератору

	59. Скрыто модератором	+5 +/–
	Сообщение от по (?), 11-Окт-23, 20:22
	а на работу на осле ездите? в метро пускают с ним?
	Ответить | Правка | Наверх | Cообщить модератору

	60. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 11-Окт-23, 21:14
	> а на работу на осле ездите? в метро пускают с ним? Ты небось из тех кто с самокатами и велами в метро прется, да? %)
	Ответить | Правка | Наверх | Cообщить модератору

	69. Скрыто модератором	+1 +/–
	Сообщение от пох. (?), 12-Окт-23, 07:39
	>> а на работу на осле ездите? в метро пускают с ним? > Ты небось из тех кто с самокатами и велами в метро прется, > да? %) ну не все же могут ездить на моноколесе - я бы вот и рад, но колени уже не выдержат этого б-ского цирка. С йешаком не пускают, требуют намордник. Вы зубы-то его видали, не говоря уже про другой орган?! Сами вот и пробуйте на него намордник надеть, а я в безопасном месте постою. Приходится ездить на самокате. (с велосипедом тоже не пускают, не знаю почему... может потому что мой весит около 800 килограмм, даже если передние колесики открутить...)
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (76), 12-Окт-23, 09:29
	потому что char всегда 1 байт
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	77. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (77), 12-Окт-23, 09:42
	>потому что char всегда 1 байт кто такое сказал? может очень нужеый ISO стандарт?
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (77), 12-Окт-23, 09:43
	*нужный
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+1 +/–
	Сообщение от пох. (?), 12-Окт-23, 20:00
	>>потому что char всегда 1 байт > кто такое сказал? может очень нужеый ISO стандарт? Вот самое мерзотное в языке Си - это как раз та непонятная муха, укусившая Ритчи, из-за которой он за каким-то совершенно неведомым хреном придумал эти char использовать не по назначению. Причем в bcpl БЫЛ тип byte. Как, ну как можно было так долбануться?
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	94. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от uis (??), 12-Окт-23, 18:15
	А указатель 4 байта. Слишком толстый троллинг.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	11. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (11), 11-Окт-23, 16:40
	Просто нужны проверки, статанализатор и божественные сишники (которые обитают только на опеннете, а в дикой природе не водяться).
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	32. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+2 +/–
	Сообщение от Анонимусс (?), 11-Окт-23, 17:24
	https://scan.coverity.com/projects/curl Что-то не сильно помогло.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+3 +/–
	Сообщение от Аноним (-), 11-Окт-23, 18:49
	> Просто нужны проверки, статанализатор и божественные сишники (которые обитают > только на опеннете, а в дикой природе не водяться). Автор сабжа так то вполне крутой и правильный сишник. А лоханулся он в общем то в процессе ... рефактора. Когда приделал логику резольвера к машине состояний - на что оно изначально расчитано не было вообще. Ну дальше логика и отъехала. p.s. а дебиан уже обновил эту штуку.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	57. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	–1 +/–
	Сообщение от пох. (?), 11-Окт-23, 20:06
	> Автор сабжа так то вполне крутой и правильный сишник. А лоханулся он > в общем то в процессе ... рефактора. Когда приделал логику резольвера > к машине состояний - на что оно изначально расчитано не было > вообще. Ну дальше логика и отъехала. а вот писал бы на нескучном язычке - не было бы проблемы с логи... waaaait... oh shi.... впрочем, не написал бы а начал бы переписывать - все б получилось. Но он почему-то не хочет. > p.s. а дебиан уже обновил эту штуку. а смысл? многие реально используют libcurl для хождения через socks5 на вредоносные сайты? проблема - яйца выеденного не стоила. новость от любителей хрустохайпа.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (-), 11-Окт-23, 21:20
	> а вот писал бы на нескучном язычке - не было бы проблемы с логи... waaaait... oh shi.... Думаешь, питоняша вообще в курсе что такое машина состояний? И тем более может написать мелкую шуструю не прожорливую либу которая проживет почти 3 десятка лет? У них как максимум получится наколенный шитец с периодом полураспада год. Может два, если очень повезло. > впрочем, не написал бы а начал бы переписывать - все б получилось. Но он почему-то не хочет. Догадывается о объеме работ и о том что серебряных пуль не бывает. А еще такой ЯП привлечет долбоклюев-комитеров в проект и CVE за ними не заржавеет. Вон на софт на расте уже сотни CVE есть - при том что этого софта еще поискать. > а смысл? многие реально используют libcurl для хождения через socks5 на вредоносные сайты? В моей конфиге в паре мест могло реально взять и у...ть, но по ряду организационных и технических проблем с этим возникли бы определенные сложности. Однако зафиксить для порядка надлежит. Самое стебное? А на самом древнем серваке, который я поленился с 10 демьяна перетащить вулна как раз и не получилось, там еще багованого кода не было. Тот редкий случай когда некромансер все же взял свое. > проблема - яйца выеденного не стоила. новость от любителей хрустохайпа. Да как сказать, автырь либы и сам не против пиара - чтоб побыстрее обновили. Безопасность бывает 2 уровней - high и нехай.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (67), 12-Окт-23, 02:43
	А как нескучный язык на этапе компиляции определит, что потом, во время работы курлу не прилетит урл длиннее 64 (кб или скок там)? Или просто внедрит то, что в ненавистных паскалях было уже десятилетия назад?
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	70. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от пох. (?), 12-Окт-23, 07:41
	> А как нескучный язык на этапе компиляции определит, что потом, во время > работы курлу не прилетит урл длиннее 64 (кб или скок там)? как всегда когда ему надо работать с данными из внешнего источника - unsafe { мамой клянус что бэзопастно! } > Или просто внедрит то, что в ненавистных паскалях было уже десятилетия > назад? просто пока будешь на нем писать стейтмашину - зае...шься бегать от борова и сдохнешь. Нет кода - нет увизгвимостей!
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (11), 12-Окт-23, 11:29
	Язык никак не определит, но переполнения буфера бы не было. Да, туда бы попал только обрезанный урл и это всё привело бы к ошибке, но это была бы просто ошибка в curl (в крайней случае курл бы просто упал), а не уязвимость с возможность запустить код.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	98. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (98), 12-Окт-23, 23:26
	Всего. Лишь. Ошибка. Всего. Лишь. Падение. Мда.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (1), 13-Окт-23, 10:09
	Всего. Лишь. Не выполнили чужой код. Хотя стоп, это уже не всего лишь.
	Ответить | Правка | Наверх | Cообщить модератору

	73. Скрыто модератором	+/–
	Сообщение от ivan_erohin (?), 12-Окт-23, 08:53
	> для хождения через socks5 на вредоносные сайты? детский сад. любой сайт может стать вредоносным.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	83. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (11), 12-Окт-23, 11:30
	Ты не смог в сарказм. А автор и правда матёрый сишник. И код у него настоящий, а не как у местных божественных сишников.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	52. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	–5 +/–
	Сообщение от пох. (?), 11-Окт-23, 18:56
	И пофиг что оно никогда бы не вызвало проблемы - если бы автор не банально запутался в _логике_ своей "стейт машины". щвятой хруст от этого конечно бы безусловно помог - хрен бы тот осилил написать стейтмашину попутно без конца бегая от безумного борова. Нет кода - нет и увизгвимостей, шах и мат неудачники.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	54. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	–2 +/–
	Сообщение от Аноним (1), 11-Окт-23, 19:20
	Какой громкий пук! Естественно, только "пох" знает, что мог или не мог автор. Вот это самомнение! Даже несмотря на то что сам автор говорит, что нескучный язычек помог бы решить эту проблему.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Ivan_83 (ok), 13-Окт-23, 00:02
	Когда включаешь в clang максимальные варинги он ещё и не такое начиает обругивать. Но это же надо потом тыщи варнингов отсмотреть и исправить... Поэтому никто не включает.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

7. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+2 +/–
Сообщение от Аноним (1), 11-Окт-23, 16:35
У автора фикса довольно интерсная статья https://daniel.haxx.se/blog/2023/10/11/how-i-made-a-heap-ove.../ . С неожиданными откровениями (нет) и выводами (да). Например про 1000чи глаз: Reading the code now it is impossible not to see the bug. Yes, it truly aches having to accept the fact that I did this mistake without noticing and that the flaw then remained undiscovered in code for 1315 days. It could have been detected with a better set of tests. Кто виноват: Yes, this family of flaws would have been impossible if curl had been written in a memory-safe language instead of C, but porting curl to another language is not on the agenda. И про, "что делать": The only approach in that direction I consider viable and sensible is to: - allow, use and support more dependencies written in memory-safe languages and - potentially and gradually replace parts of curl piecemeal, like with the introduction of hyper. (hyper написан на Rust)
Ответить | Правка | Наверх | Cообщить модератору

	46. Скрыто модератором	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 11-Окт-23, 18:32
	Растофанатик не умеет си и ругает его? Где-то я уже это видел. Плохому танцору вечно что-то мешает. Потом и раст будет мешать, помяните моё слово.
	Ответить | Правка | Наверх | Cообщить модератору

	48. Скрыто модератором	+1 +/–
	Сообщение от Аноним (1), 11-Окт-23, 18:35
	Чел пишет курл на сишке с 1996 года и не умеет в си? Ты совсем бо-бо? Может он просто знает хорошие и плохие стороны языка?
	Ответить | Правка | Наверх | Cообщить модератору

	49. Скрыто модератором	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 11-Окт-23, 18:44
	> Чел пишет курл на сишке с 1996 года и не умеет в > си? > Ты совсем бо-бо? Какая аналогия между тем, что он что-то пишет с 96 года и знанием? Полно антипримеров. > Может он просто знает хорошие и плохие стороны языка? Ну знал бы, добавил бы статический анализатор, асан, юбисан, тесты в конце концов Итд итп и нашёл бы уязвимость
	Ответить | Правка | Наверх | Cообщить модератору

	53. Скрыто модератором	+1 +/–
	Сообщение от пох. (?), 11-Окт-23, 18:58
	хорошая сторона - на си удалось написать curl, который использует пол-планеты (вторая-то половина просто вызывает встроенный в винду веб-клиент) плохая сторона - можно запутаться в собственной логике и написать не совсем работающий код (переписать причем - работавший). Безусловно от этого очень поможет нескучный язычок. Нет кода - нет проблемы.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

17. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
Сообщение от Аноним (17), 11-Окт-23, 16:48
Внедрено: Daniel S (4 Jan 2008) - Based on Maxim Perenesenko's patch, we now do SOCKS5 operations and let the   proxy do the host name resolving and only if --socks5ip (or   CURLOPT_SOCKS5_RESOLVE_LOCAL) is used we resolve the host name locally and   pass on the IP address only to the proxy. https://github.com/curl/curl/commit/2e42b0a252416803a90ea232... Не исправлено наряду с похожими: Apr 24, 2010 socks5: please static code analyzer ... The change of (char) to (unsigned char) will fix long user names and passwords on systems that have the char type signed by default. https://github.com/curl/curl/commit/7fb7f2413194e7f7a21716f8...
Ответить | Правка | Наверх | Cообщить модератору

	22. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+5 +/–
	Сообщение от Аноним (1), 11-Окт-23, 16:59
	Если я правильно нашел его линкедын, то он Professional C++ development for Unix и Technical Lead C++, а на момент написания бага Independent Computer Software Professional Это просто какой-то позор (с)
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (26), 11-Окт-23, 17:10
	Вполне определённый позор. Но, в то время было значительно хуже со статическими анализаторами (хотя и сегодня не каждый использует smatch) и дешёвых рантайм анализаторов вроде asan, которые можно было бы пофаззить, тоже не существовало. Я, конечно, не утверждаю, что автор что-то из этого умеет использовать и сегодня.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+2 +/–
	Сообщение от Анонимусс (?), 11-Окт-23, 17:15
	В какое "то время" O_o? Socks вмерджили в основную ветку курлс в феврале 2020 года "On February 14 2020 I landed the main commit for this change in master. It shipped in 7.69.0" Не, ну я понимаю, что сейчас время такое, что год за пять идет)))
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (17), 11-Окт-23, 17:41
	> В какое "то время" O_o? > Socks вмерджили в основную ветку курлс в феврале 2020 года > "On February 14 2020 I landed the main commit for this change > in master. It shipped in 7.69.0" 608 -    socksreq[len++] = (char) hostname_len; /* address length */ https://github.com/curl/curl/commit/4a4b63daaa#diff-78fe660c... 838 +       socksreq[len++] = (char) hostname_len; /* one byte address length */ https://github.com/curl/curl/commit/4a4b63daaa#diff-78fe660c...
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (17), 11-Окт-23, 17:58
	Кстати в плюсах не приняты такие касты. Там принят static_cast<>. Очень длинно и заставляет задуматься.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	80. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (76), 12-Окт-23, 10:31
	auto i = static_cast<int>(1);
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Neon (??), 15-Окт-23, 03:50
	В плюсах вполне можно кастовать в С-шном стиле.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	89. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (89), 12-Окт-23, 16:00
	Вы, уже свой позор начали ваять?
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

25. Скрыто модератором	–1 +/–
Сообщение от Бульдох (?), 11-Окт-23, 17:08
Сейчас этот башмачник скажет, что это не баг и он святой.
Ответить | Правка | Наверх | Cообщить модератору

	28. Скрыто модератором	+/–
	Сообщение от Аноним (11), 11-Окт-23, 17:14
	Не скажет. Этот "башмачник" реально умеет код писать (и написал). Это только местные боги сишечки багов не делают (потому, что код не пишут).
	Ответить | Правка | Наверх | Cообщить модератору

	34. Скрыто модератором	+2 +/–
	Сообщение от Аноним (34), 11-Окт-23, 17:28
	Ну баг и баг зато софт есть, а на другой языке нормального софта нет. Вы так бы и сидели в каменном веке поклоняясь своему языку, на котором ничего не написано.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	35. Скрыто модератором	+1 +/–
	Сообщение от Аноним (1), 11-Окт-23, 17:33
	Так для этого софта "который есть", автор сам хочет переписать бекенд на безопасный язык. И предлагает, та-дам, Rust! В его блог-посте про hyper (https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/) Сurl and its data transfer core, libcurl, is all written in C. The language C is known and infamous for not being memory safe and for being easy to mess up and as a result accidentally cause security problems. ... curl is a piece of “insecure” C code installed in some ten billion installations world-wide. ... With a backend library written in Rust , libcurl would lean on such a component to do low level protocol work and presumably, by doing this it increases the chances of the implementations to be safe and secure. Более того, он ведет подсчет, сколько багов получилось из-за дырявого языка Including the latest two CVEs reported for curl 8.4.0, the accumulated total says that 41% of the security vulnerabilities ever found in curl would likely not have happened should we have used a memory-safe language.
	Ответить | Правка | Наверх | Cообщить модератору

	58. Скрыто модератором	+1 +/–
	Сообщение от пох. (?), 11-Окт-23, 20:13
	> Так для этого софта "который есть", автор сам хочет переписать бекенд на но не может. > И предлагает, та-дам, Rust! "не рассматривается". А предлагает он - использовать вместо собственного кода - некую hrenь на хрусте. Уже кем-то написанную. Но не им. Следующий логичный шаг - а зачем нам теперь вообще curl? > curl is a piece of “insecure” C code installed in some ten > billion installations world-wide. > With a backend library written in Rust Вместо 10000000 останутся только линуксоподелки под две единственно-верных архитектуры. Зато безопастные. так и победим. отдельный привет всему софту который сейчас линкуется с крохотной libcurl, которую и используют-то в основном из-за ее компактности (и уже потом только - всеядности) а дальше внезапно получит в довесок пол-гига статического хлама из миллиона васянских крейтов.
	Ответить | Правка | Наверх | Cообщить модератору

	63. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 11-Окт-23, 21:28
	> А предлагает он - использовать вместо собственного кода - некую hrenь на > хрусте. Уже кем-то написанную. Но не им. Следующий логичный шаг - > а зачем нам теперь вообще curl? К вопросу о том как вежливо и политкорректно послать хрустиков жрать свое... это самое :))) > Вместо 10000000 останутся только линуксоподелки под две единственно-верных архитектуры. > Зато безопастные. так и победим. Ну как бы у сишки как ЯП есть довольно назойливые грабли с одной стороны - и е...чий ISO клавший на них болт - с другой. Все же инженерные проблемы надо решать, а не заметать под ковер. > отдельный привет всему софту который сейчас линкуется с крохотной libcurl, которую и > используют-то в основном из-за ее компактности (и уже потом только - > всеядности) а дальше внезапно получит в довесок пол-гига статического хлама из > миллиона васянских крейтов. Ну дык вот libcurl это и правда достаточно мелкая неинтрузивная либа. Если уж наезжать на кого так это openssl, по CVE в месяц стабильно просто, при том даже если им раст дать или что там, они не криптографы и вон там сертификат например нормально проверить не могли и какие-то совсем васянские серты стали катить за чистую монету. Ну и вот чем им поможет хруст? А ты соответственно введешь свои кренделя на сайте банка. Приколов.
	Ответить | Правка | Наверх | Cообщить модератору

	71. Скрыто модератором	+2 +/–
	Сообщение от пох. (?), 12-Окт-23, 07:45
	> Ну дык вот libcurl это и правда достаточно мелкая неинтрузивная либа. Если > уж наезжать на кого так это openssl, по CVE в месяц так его уже (дважды? Или больше - я сбился со счета уже этим васяноподелкам) переписькали? Правда, видимо, по прежнему ничего не работает, поскольку даже величайший гугель так и остался на своей ниправильной увизгвимой реализации на сях, где половина фич не работает потому что гугелю нинада, затобезопастна (нет кода - нет проблемы, традиционное решение же ж). Зато они переписькали какой-то ненужно-загрузчик каких-то ненужно-vm внутри ведроида. Ни один эксперт опеннета не смог понять даже что это за хрень и для чего она там - но все в восторге от невиданных узбеков.
	Ответить | Правка | Наверх | Cообщить модератору

	91. Скрыто модератором	+/–
	Сообщение от Аноним (91), 12-Окт-23, 16:32
	> 41% of the security vulnerabilities ever found in curl would likely not have happened should we have used a memory-safe language. Получается, 59% уязвимостей будут бережно воспроизведены и в Rust-коде. Но "дырявую Сишку" периодически аудируют пользующие её гугли, а безопасТному расту все доверятся не глядя и вообще перестанут уязвимости искать и находить.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	93. Скрыто модератором	+/–
	Сообщение от uis (??), 12-Окт-23, 18:08
	Интересно, сколько из уязвимостей можно закрыть fortified source и прочие настройки компилятора. Понятно, что все те 41% будут закрыты с -fsanitize=address
	Ответить | Правка | Наверх | Cообщить модератору

	95. Скрыто модератором	–1 +/–
	Сообщение от Аноним (1), 12-Окт-23, 18:46
	т.е если после смены языка уйдут 41% дыреней, этого мало? да ты просто зажрался! Я понимаю, что тебе не нравится когда унижают дыряшку, но что поделаешь жизнь такая. Каменный век закончился, не потому что закончились камни.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	97. Скрыто модератором	+/–
	Сообщение от Аноним (97), 12-Окт-23, 20:27
	> т.е если после смены языка уйдут 41% дыреней, этого мало? Какая разница сколько уйдёт? Главное, сколько останется. Если аудит регулярный, сколько он находит проблем (1-100) роли не играет, он находит их пачками - условно ВСЁ, что сейчас находится. Количество говорит лишь о качестве разработки, а не о безопасности кода. Найдут хотя бы одну - код уже потенциально небезопасный, на любом языке. И ведь найдут. Потому что, чем больше вносится изменений, тем выше риск ошибки. Даже если ты Раст-гуру с 4-мя глазами.
	Ответить | Правка | Наверх | Cообщить модератору

	100. Скрыто модератором	+/–
	Сообщение от Аноним (98), 12-Окт-23, 23:37
	>уйдут 41% дыреней И близко не стоит переписывания рабочего проекта на другой язык.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

55. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	–2 +/–
Сообщение от Аноним (55), 11-Окт-23, 19:54
Господи, когда же это кончится...
Ответить | Правка | Наверх | Cообщить модератору

	72. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от FF (?), 12-Окт-23, 08:01
	Без уязвимостей не будет развития
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+1 +/–
	Сообщение от Аноним (85), 12-Окт-23, 12:25
	Глупость, очевидно, что развитие будет только при устранении уязвимостей.
	Ответить | Правка | Наверх | Cообщить модератору

56. "Переполнение буфера в curl и libcurl, проявляющееся при обращении через SOCKS5-прокси"	+/–
Сообщение от Аноним (56), 11-Окт-23, 20:03
$4660 не за эксплуатацию уязвимости, а просто за переполнение? Не многовато ли?
Ответить | Правка | Наверх | Cообщить модератору

	65. "Переполнение буфера в curl и libcurl, проявляющееся при обращении через SOCKS5-прокси"	+/–
	Сообщение от Да ну нахер (?), 11-Окт-23, 21:43
	Для иностранцев четыря тыщи это наоборот же очень мало вроде? Я слышал там за четыре тыщи пустой main пишут, и то в неделю.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Переполнение буфера в curl и libcurl, проявляющееся при обращении через SOCKS5-прокси"	+2 +/–
	Сообщение от Аноним (67), 12-Окт-23, 02:45
	Этого хватит чтобы оплатить электричество, потреблённое компьютером и хотдог.
	Ответить | Правка | Наверх | Cообщить модератору

74. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	–1 +/–
Сообщение от Аноним (74), 12-Окт-23, 09:04
Что же получается, помимо указанной уязвимости? Если в качестве SOCKS5 используется TOR, то если длина URL > 256, имеет место обращение к DNS, следовательно, возможен деанон. Если, конечно, правилами файервола не запрещено прямое хождение в инет.
Ответить | Правка | Наверх | Cообщить модератору

	88. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (88), 12-Окт-23, 12:47
	Это неэксплуатабельно в интернете: DNS-имя не может быть больше 254 байт. Поэтому протокол SOCKS5 такие длинные имена и не поддерживает.
	Ответить | Правка | Наверх | Cообщить модератору

81. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
Сообщение от Аноним (81), 12-Окт-23, 11:28
>При длине имени хоста до 256 символов curl сразу передаёт имя в SOCKS5-прокси для резолвинга на его стороне, а если имя больше 255 символов переключается на локальный резолвер и передаёт в SOCKS5 уже определённый адрес. Вот так можно деанонимизировать пользователей Tor, из-за бэкдора в libcurl?
Ответить | Правка | Наверх | Cообщить модератору

	84. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	–1 +/–
	Сообщение от Аноним (11), 12-Окт-23, 11:37
	Любая потенциально возможная к эксплуатации уязвимост ьв сетевом софте может потенциально быть деанонимизирующей. Для тебя это новость?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (86), 12-Окт-23, 12:28
	Походу эта бырка была для кого надо дырка https://github.com/curl/curl/commit/fb4415d8aee6c1045be932a3... Для нужд кого надо кое-как на коленке вделали технологическое отверстие, да нечаянно уязвимость открыли в переполнении буфера. Так бы никто и не узнал, ибо исходники больших запутанных проектов со спагетти-подходом, особенно на необъектно-ориентированных языках вроде сишки, где накладные расходы на паттерны и чистый код превышают выгоду (нет бы на C++ всё переписать!), знает только их автор, а остальным в них копаться нет резона, но технологическое отверстие было вделано криво и инногда приводило к заражению крови, то есть к повреждению памяти, сепсису и смерти процесса. Кто-то был достаточно дотошным и раскопал. Пришлось извиняться и писать целый пост для отведения глаз, хотя ежу понятно, что в случае использования SOCKS5 если указанно DNS-запросы пускать через прокси - то надо так и делать, а не саботировать процесс. Это как если бы автозак для этапирования заключённого после 256 легоньких стуков изнутри по кузову по двери открывался и выпускал зэка вместо того, чтобы приводить к приходу конвоира с дубинкой.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+1 +/–
	Сообщение от Аноним (88), 12-Окт-23, 12:47
	Эта дырка неэксплуатабельна в интернете: DNS-имя не может быть больше 254 байт. Поэтому протокол SOCKS5 такие длинные имена и не поддерживает.
	Ответить | Правка | Наверх | Cообщить модератору

92. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
Сообщение от uis (??), 12-Окт-23, 18:04
Если сильно фапать на безопасность, можно просто собирать с hardened параметрами копмпилятора, а если фапать ещё упорнее, то с -fsanitize=address
Ответить | Правка | Наверх | Cообщить модератору

	101. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Аноним (98), 12-Окт-23, 23:40
	Не ты чо, проще еще один язык программирования выучить!
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Переполнение буфера в curl и libcurl, проявляющееся при обра..."	+/–
	Сообщение от Ivan_83 (ok), 13-Окт-23, 00:04
	Вы что то путаете. Санитайзер сборки они для отладки. Чтобы найти эту и подобные проблемы обычно достаточно включить все доступные варнинги и компилятор покажет все похожие места.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

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

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