The OpenNET Project / Index page

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



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

"Переполнение буфера в 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.ru/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 
Ответить | Правка | Наверх | Cообщить модератору

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

60. Скрыто модератором  +1 +/
Сообщение от Аноним (-), 11-Окт-23, 21:14 
Ответить | Правка | Наверх | Cообщить модератору

69. Скрыто модератором  +1 +/
Сообщение от пох. (?), 12-Окт-23, 07:39 
Ответить | Правка | Наверх | 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 
Ответить | Правка | К родителю #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 
Ответить | Правка | Наверх | Cообщить модератору

49. Скрыто модератором  +1 +/
Сообщение от Вы забыли заполнить поле Name (?), 11-Окт-23, 18:44 
Ответить | Правка | Наверх | Cообщить модератору

53. Скрыто модератором  +1 +/
Сообщение от пох. (?), 11-Окт-23, 18:58 
Ответить | Правка | К родителю #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 
Ответить | Правка | Наверх | Cообщить модератору

58. Скрыто модератором  +1 +/
Сообщение от пох. (?), 11-Окт-23, 20:13 
Ответить | Правка | Наверх | Cообщить модератору

63. Скрыто модератором  +1 +/
Сообщение от Аноним (-), 11-Окт-23, 21:28 
Ответить | Правка | Наверх | Cообщить модератору

71. Скрыто модератором  +2 +/
Сообщение от пох. (?), 12-Окт-23, 07:45 
Ответить | Правка | Наверх | Cообщить модератору

91. Скрыто модератором  +/
Сообщение от Аноним (91), 12-Окт-23, 16:32 
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

93. Скрыто модератором  +/
Сообщение от uis (??), 12-Окт-23, 18:08 
Ответить | Правка | Наверх | Cообщить модератору

95. Скрыто модератором  –1 +/
Сообщение от Аноним (1), 12-Окт-23, 18:46 
Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

97. Скрыто модератором  +/
Сообщение от Аноним (97), 12-Окт-23, 20:27 
Ответить | Правка | Наверх | Cообщить модератору

100. Скрыто модератором  +/
Сообщение от Аноним (98), 12-Окт-23, 23:37 
Ответить | Правка | К родителю #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 | Индекс форумов | Темы | Пред. тема | След. тема




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

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