The OpenNET Project / Index page

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



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

"Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к файлам вне рабочего каталога"  +/
Сообщение от opennews (??), 05-Авг-22, 17:52 
В HTTP-сервере muhttpd, применяемом преимущественно в маршрутизаторах и точках доступа, выявлена уязвимость (CVE-2022-31793), позволяющая неаутентифицированному атакующему через отправку специально оформленного HTTP-запроса загрузить произвольные файлы, насколько это позволяют права доступа, под которыми выполняется HTTP-сервер (во многих устройствах muhttpd запускается с правами root). Например, атакующий может получить доступа к файлам с паролями, настройками беспроводного доступа, параметрами подключения к провайдеру и закрытыми ключами...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57601

Ответить | Правка | Cообщить модератору

Оглавление

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


1. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +4 +/
Сообщение от Аноним (1), 05-Авг-22, 17:52 
Не уязвимость, а канал доступа. Красиво, вряд ли только сейчас нашли. Это примерно как у многих сайтов ластик в интернет вывешен или VNC без пароля, только лучше.
Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +2 +/
Сообщение от Аноним (3), 05-Авг-22, 17:58 
А писали бы на единственной безопасном и быстром языке Carbon, то уязвимость они бы все равно нашил куда вставить.
Ответить | Правка | Наверх | Cообщить модератору

9. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +7 +/
Сообщение от Аноним (-), 05-Авг-22, 18:36 
Что-то подсказывает что лажаться с обработкой путей кодеры будут одинаково, хоть на брейнфаке.
Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  –5 +/
Сообщение от Аноним (16), 05-Авг-22, 18:55 
Чтобы не лажаться с обработкой путей, нужна capability-based security model. Но unix-way - это продолжать жрать кактус.
Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +4 +/
Сообщение от Аноним (41), 05-Авг-22, 23:09 
> нужна capability-based security model

которую изобрели в unix системах

Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 06-Авг-22, 00:22 
> Чтобы не лажаться с обработкой путей, нужна capability-based security model.

В линухе оно даже есть. Как и контейнеры позволяющие довольно эффективно отрезать сервер в его загон когда выйти довольно проблематично.

Пара нюансов?
1) У вон тех может быть инновационный кернел типа 2.6.32 где наиболее эффективных фич конечно же нет. Оно было в каком году вообще? Я даже и не помню этого уже.
2) Насколько там всем было на безопасность - намекает пуск вебсервака под рутом. Думаете вон ТЕ станут заморачиватья чем-то более продвинутым? Плин, там фирмварь делана жоскими индусами которые рады по уши что доисторический CrapDK от вендора вообще что-то работающее выдал, все, узкоглазикам из *-link или чего там еще можно идти это продавать :)

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

57. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от YetAnotherOnanym (ok), 06-Авг-22, 09:49 
Правильно, пока ты будешь имплементировать свою продуманную архитектуру, санитизировать каждый пук, прилетающий извне и огораживать все компоненты капабилитями, вон те выкинут на рынок дешёвую поделку, сделанную по принципу "тяп-ляп и в продакшон". И твоя железка будет интересна только кучке гиков, которые имеют неприличную манеру совать нос под капот.
Ответить | Правка | Наверх | Cообщить модератору

64. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +1 +/
Сообщение от Аноним (64), 06-Авг-22, 21:24 
> Правильно, пока ты будешь имплементировать свою продуманную архитектуру, санитизировать
> каждый пук, прилетающий извне и огораживать все компоненты капабилитями, вон те
> выкинут на рынок дешёвую поделку, сделанную по принципу "тяп-ляп и в
> продакшон". И твоя железка будет интересна только кучке гиков, которые имеют
> неприличную манеру совать нос под капот.

Ну да, ну да, поэтому хомякам придется жить с д@рьмовыми железками где фирварь писана полоумными макакаами. Наслаждаясь червяками в интранете, а особо неудачливые и массажем почек от майора "потому что мсг был с твоего айпишника, с*ка!!!1111". А я пойду окучивать все же несколько менее хомякообразных, которые за каждый #$%ный цент все же не трясутся и лучше понимают что хотят. Так устроен этот мир: любую работу можно сделать быстро, дешево и качественно. Выберите любые 2 из 3.

Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от YetAnotherOnanym (ok), 06-Авг-22, 09:43 
Чтобы не лажаться с чем бы то ни было, надо думать головой. А владельцу бизнеса или лицу, принимающему решения - думать головой, чтобы наннимать разрабов, которые думают головой.
А на случай лажи, которую почему-то не получилось избежать - да, использовать в том числе и capability-based security model.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

90. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (90), 10-Авг-22, 17:06 
Странно, а я думал, что быстрый и безопасный это раст. Учу программирование строго по опеннету, если что.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

36. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  –1 +/
Сообщение от Аноним (36), 05-Авг-22, 21:53 
А вот ужасный сустемдэ своим сервисом изолировал бы юзерспейс!
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

47. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 06-Авг-22, 00:23 
Он 2 метра RAM жрет, а в том крапе всей оперативы 16..32 мега и ее впритык :)
Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +1 +/
Сообщение от Аноним (58), 06-Авг-22, 10:00 
Ты бы еще в докере предложил запустить.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

2. Скрыто модератором  +3 +/
Сообщение от anonym13 (?), 05-Авг-22, 17:57 
Ответить | Правка | Наверх | Cообщить модератору

4. Скрыто модератором  +/
Сообщение от Аноним (3), 05-Авг-22, 17:59 
Ответить | Правка | Наверх | Cообщить модератору

6. Скрыто модератором  +1 +/
Сообщение от Аноним (6), 05-Авг-22, 18:14 
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

7. Скрыто модератором  +/
Сообщение от Аноним (7), 05-Авг-22, 18:23 
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

15. Скрыто модератором  +/
Сообщение от Аноним (15), 05-Авг-22, 18:48 
Ответить | Правка | Наверх | Cообщить модератору

19. Скрыто модератором  +2 +/
Сообщение от Аноним (19), 05-Авг-22, 18:56 
Ответить | Правка | Наверх | Cообщить модератору

22. Скрыто модератором  +/
Сообщение от Аноним (22), 05-Авг-22, 19:02 
Ответить | Правка | Наверх | Cообщить модератору

24. Скрыто модератором  +1 +/
Сообщение от Аноним (19), 05-Авг-22, 19:10 
Ответить | Правка | Наверх | Cообщить модератору

27. Скрыто модератором  +/
Сообщение от Аноним (27), 05-Авг-22, 19:33 
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

31. Скрыто модератором  +1 +/
Сообщение от Аноним (31), 05-Авг-22, 20:04 
Ответить | Правка | Наверх | Cообщить модератору

37. Скрыто модератором  +1 +/
Сообщение от Аноним (27), 05-Авг-22, 21:55 
Ответить | Правка | Наверх | Cообщить модератору

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

8. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +14 +/
Сообщение от Аноним (8), 05-Авг-22, 18:30 
> разработчики подразумевали, что первый символ всегда "/"

Взоржал.

Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 05-Авг-22, 19:02 
Ужас какой! Вы прикрывайте дырки, а то имеет все кто хочит!
Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 05-Авг-22, 19:12 
Ну и дырыще!
Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  –1 +/
Сообщение от Аноним (-), 05-Авг-22, 19:43 
Вот тебе и дебиан!
Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  –1 +/
Сообщение от Аноним (48), 06-Авг-22, 00:27 
Нет такого пакета в этой репе! Сектор Б на барабане. Поздравляем, Вы - банкрот!
Ответить | Правка | Наверх | Cообщить модератору

32. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от BrainFucker (ok), 05-Авг-22, 20:16 
Даже и не знал что такой сервер вообще есть.
Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (33), 05-Авг-22, 20:27 
Эффективный опенсорс...
Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +2 +/
Сообщение от Аноним (34), 05-Авг-22, 20:51 
> muhttpd (mu HTTP daemon) is a simple but versatile web server written in portable ANSI C

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

Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +2 +/
Сообщение от Аноним (35), 05-Авг-22, 21:10 
Падаждите, а куда смотрели тысячи глаз? На три другие стены?
Ответить | Правка | Наверх | Cообщить модератору

38. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +3 +/
Сообщение от Sw00p aka Jerom (?), 05-Авг-22, 22:02 
вытекли :)
Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (41), 05-Авг-22, 23:12 
Они как раз и нашли эти уязвимости.
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

45. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +1 +/
Сообщение от Анонн (?), 06-Авг-22, 00:13 
Ахаха, ты серьезно?
"Проблема присутствует начиная с самой первой версии muhttpd ..." это с 2007 года (надеюсь, иначе вообще с 2002)!
Ответить | Правка | Наверх | Cообщить модератору

50. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (50), 06-Авг-22, 01:10 
Учитывая, что я вообще впервые слышу про такой веб-сервер, глаз там было по числу коммитеров умножить на полтора. :)
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

63. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (35), 06-Авг-22, 19:51 
Ну ты может и в первый раз слышишь, а его используют серьезные ынтерпрайз конторы типа "AT&T, Frontier и Windstream"
Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от karl93rus (ok), 05-Авг-22, 22:20 
На расте такой дыры не было бы?
Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  –2 +/
Сообщение от Аноним (40), 05-Авг-22, 22:35 
Слышал песню от группы Ленинград под названием Дорожная?
Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Онаним (?), 05-Авг-22, 23:18 
Растишка втуда где это используется без утрамбовки не залезет.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

52. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  –1 +/
Сообщение от Cucumber (?), 06-Авг-22, 05:17 
В расте такая болезненная работа с путями, что там даже никогда не заметили бы проблемы за мишурой из бесконечных кастов OSString в String, Path в PathBuf, ResultReadDir в ReadDir в IteratorResultDirEntry в IteratorDirEntry в DisplayDirEntryPathExt и обратно.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

53. Скрыто модератором  +/
Сообщение от Аноним (-), 06-Авг-22, 06:28 
Ответить | Правка | Наверх | Cообщить модератору

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

65. Скрыто модератором  +/
Сообщение от Аноним (-), 06-Авг-22, 21:45 
Ответить | Правка | Наверх | Cообщить модератору

66. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 06-Авг-22, 21:46 
> В расте такая болезненная работа с путями, что там даже никогда не
> заметили бы проблемы за мишурой из бесконечных кастов OSString в String,
> Path в PathBuf, ResultReadDir в ReadDir в IteratorResultDirEntry в IteratorDirEntry в
> DisplayDirEntryPathExt и обратно.

Интересно а в всем этом не будет новых бонусных вулнов как это уже было в их stdlib'е? :)

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

43. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Онаним (?), 05-Авг-22, 23:17 
muahahahttpd
Ну конечно "разработчики" эмбедовки тоже кони ещё те. С цирком.
httpd от рута - это прелесть просто.
Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +1 +/
Сообщение от Аноним (48), 06-Авг-22, 00:29 
Да это обычно обдолбаные узкоглазики которые койкак слабали вообще и скорее продавать.
Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (51), 06-Авг-22, 04:41 
Недырявый домашний роутер - это что-то вообще из области фантастики )
Хотите за 30 баксов и еще чтоб безопасно?
Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +1 +/
Сообщение от Sylvia (ok), 06-Авг-22, 08:06 
О существовании некоторых вебсерверов (и некоторого другого софта) узнаешь из сообщений об уязвимостях в них
Ответить | Правка | Наверх | Cообщить модератору

55. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от abu (?), 06-Авг-22, 09:23 
muhttpd? щито?
Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (58), 06-Авг-22, 10:01 
То что модератор удалил все комментарии про то что уязвимость очевидно вставлена намеренно лишь подтверждает этот факт.  
Ответить | Правка | Наверх | Cообщить модератору

61. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (61), 06-Авг-22, 18:20 
20 лет назад... иис... дежавю....
Ответить | Правка | Наверх | Cообщить модератору

62. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +1 +/
Сообщение от Аноним (62), 06-Авг-22, 19:19 
дайте угадаю,. следующая найденная там уязвимость будет
GET /../../../../../../../etc/passwd
?
потому что 'используя технику "DNS rebinding"' затруднительно пинуть именно "a/etc/passwd" - браузер надо еще както заставить такое выдать. А вот /../../../../../../../etc/passwd вообще не проблема...
Ответить | Правка | Наверх | Cообщить модератору

69. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (69), 07-Авг-22, 21:15 
> браузер надо еще както заставить

Настоящий хакер (крякер тем более) работает с сетью только через браузер.

Ответить | Правка | Наверх | Cообщить модератору

70. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Пароним (?), 08-Авг-22, 02:40 
Ты что, хакир, что ли?
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

67. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +1 +/
Сообщение от burjui (ok), 07-Авг-22, 04:49 
extern char **environ;

int clearenv(void) {
    /* We would like to free previously set environment variables here,
     * but at least FreeBSD 5.1 doesn't let us */
    /* Create empty environment */
    environ = malloc(sizeof(char*));
    if(environ) {
        *environ = NULL;
    }

    return 0;
}

Беллиссимо. Это не местные ыксперты писали, которые в новости про Rust бегают?

Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 08-Авг-22, 09:28 
А что тебе не нравится?
Ответить | Правка | Наверх | Cообщить модератору

72. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 08-Авг-22, 11:21 
Серьёзно? Местных сишников послушать - так они лучшие в мире и никогда не делают ошибок, а ты очевидных косяков не видишь :)

Во-первых, вместо этой портянки

environ = malloc(sizeof(char*));
if(environ) {
    *environ = NULL;
}

достаточно написать

environ = calloc(sizeof(char*), 1);

т.к. NULL в C - это просто ноль, приведённый к типу void*.

Во-вторых, тут как в анекдоте: вы или штаны наденьте, или крестик снимите. Зачем clearenv() возвращать int, если она всегда возвращает ноль? Тут уж или void clearenv(), или давайте возвращать ещё что-то кроме нуля.

В-третьих, если функция возвращает некие коды, неплохо бы их объявить, а не просто return 0. Вернуть ноль любой дурак может, а вот чтобы понять, что он значит в этой функции, нужно уже лезть в исходник,

В-чертвёртых, комментарий "Create empty environment" должен комментировать функцию, а не её внутренности. И вообще, он должен быть в заголовочном файле.

В общем, как-то так:

---- clearenv.h ----

#define CLEARENV_SUCCESS 0
#define CLEARENV_FAILURE -1

/* Create empty environment */
int clearenv(void);

---- clearenv.c ----

int clearenv(void) {
    /* We would like to free previously set environment variables here,
     * but at least FreeBSD 5.1 doesn't let us */
    environ = calloc(sizeof(char*), 1);
    return environ ? CLEARENV_SUCCESS : CLEARENV_FAILURE;
}

Ответить | Правка | Наверх | Cообщить модератору

73. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 08-Авг-22, 13:39 
Это всё, что ты перечислил, стилевые придирки. Которые совершенно нерелевантны для функции, назначение которой прозрачно из её имени, которая небось вызывается один раз и этот код выделен в функцию, только чтобы main почище был бы. Ты не читал аргументацию Кармака, почему DRY плох и почему его надо заменять на WET? Один из ключевых аргументов в том, что имея перед глазами два примера полезености куска кода, ты не можешь обобщить этот код и осмысленно выделить в функцию. Поэтому момент выделения в функцию надо откладывать как можно дольше, но за пределы WET откладывать может быть неудобно по другим причинам, поэтому WET. Здесь есть _одно_ использование функции, а значит осмысленно обобщить её не удастся. Зачем пытаться тогда совершить невозможное?

Что мне непонятно в этом коде, так это нахрена нужен malloc. Видимо исходной задумкой было освободить "груду" памяти, выкинув из неё environment, а когда не нашлось кроссплатформенного способа, кроме exec'а с пустым envp, они оставили то, что оставили. При этом функция может сделать так, чтобы environ==NULL, или чтобы он указывал в кучу... Неясно, зачем выделять память, если ок и норм сделать environ=NULL.

> В общем, как-то так:

Руки отрывать за такое. Столько писанины ради двух строк функции. Это корпоративный подход, который приводит к тому, что никому не нужного бойлерплейта оказывается больше, чем реально работающего кода. Достаточно один раз договориться, какое возвращаемое мы считаем успехом по-дефолту. Для такого C, который вокруг сисколлов бродит постоянно, я б, как и ты, выбрал -1, для обозначения фейла, и >=0 для успеха. Но я б не парился декларировать какие-то там дефайны: толку от них? Ну вот кроме упёртого следования стилю, который препод с тебя требует, какой смысл?

Если уж muhttpd готов работать при environ == NULL, то это делается так:

int clearenv() {
    environ = NULL;
    return 0;
}

Если не готов, и это отсутствие стали в хребте сделать exit(1) при обломе malloc, то:
int clearenv() {
    environ = malloc(sizeof(char**));
    if(environ == NULL) {
        fputs("Go buy some RAM, moron\n", stderr);
        abort();
    }
    *environ = NULL;
    return 0;
}

> т.к. NULL в C - это просто ноль, приведённый к типу void*.

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

> Зачем clearenv() возвращать int, если она всегда возвращает ноль?

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

> И вообще, он должен быть в заголовочном файле.

Нет. В заголовочных файлах должно быть только то, что используется из других "модулей". Те же функции, которые эффективно static функции, противопоказано совать в заголовочные файлы. Вот атрибут static на неё повесить не помешало бы. Но в принципе, какая хрень. muhttpd не firefox, у него сколько там символов на круг получается по всем .o файлам? Смысла нет заботиться о снижении их числа, компиляция всё равно околомоментальна.

Ответить | Правка | Наверх | Cообщить модератору

74. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 08-Авг-22, 14:55 
> Ты не читал аргументацию Кармака, почему DRY плох и почему его надо заменять на WET?

...
> Здесь есть _одно_ использование функции, а значит осмысленно обобщить её не удастся. Зачем пытаться тогда совершить невозможное?

Какое отношение всё это имеет к обсуждаемой функции? Какое обобщение? Я вообще об этом даже не заикался.

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

Вот вместо написания этих двух предложений лучше бы почитал стандарт и убедился. Люди уже гуглить обленились, дожили.

> Достаточно один раз договориться

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

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

Ответить | Правка | Наверх | Cообщить модератору

76. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 08-Авг-22, 20:04 
> Какое обобщение? Я вообще об этом даже не заикался.

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

Но это возможно только тогда, когда у тебя перед глазами есть несколько кусков кода, которые можно вынести в одну функцию и обобщить. Здесь же иная ситуация, код вынесен в функцию не для повторного использования, а для того, чтобы повысить читаемость, заменив сколько-то там строк кода на одну: clearenv(), которая сразу видно что делает. В этом случае нечего обобщать. Невозможно обобщать на одном примере.

Так понятнее стало?

> Вот вместо написания этих двух предложений лучше бы почитал стандарт и убедился.

Вот ещё. Делать мне больше нечего. Мне больше нравится ptr = NULL. Я не знаю почему, но в таких вопросах я привык доверять интуиции. Она не подводит, и избавляет от нужды читать долбаные стандарты.

> Ну и как там процесс идёт? Разработчики библиотек между собой уже договорились?

Речь идёт о договорённости действующих на данной программе. На большее у C возможностей нет. Из тех решений, которые возможны в C, нет одного, которое было бы приемлимо во всех случаях. Но на одну программу, тем более размера muhttpd вполне можно иметь договорённости. И _нужно_, все разумные люди это делают, пускай и неявно, без прописывания в CoC или куда они там пишут такие правила.

> я уже устал дискутировать

Ты ещё не начал. В смысле вот это твоё сообщение -- это первый ответ в дискуссии, предыдущее сообщение было лишь постулированием твоей позиции.

Усталось всегда возникает симптомом, когда сливаешь дискуссию.

Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 08-Авг-22, 23:27 
> Так понятнее стало?

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

> Вот ещё. Делать мне больше нечего.
> Я не знаю почему, но в таких вопросах я привык доверять интуиции.

Я искренне не понимаю: это такой тонкий троллинг, или ты на полном серьёзе сейчас кичишься своей безграмотностью в данном вопросе?

> Усталось всегда возникает симптомом, когда сливаешь дискуссию.

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

Ответить | Правка | Наверх | Cообщить модератору

81. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 09-Авг-22, 13:30 
> Нет, мне не стало понятнее, с чего вдруг ты вообще заговорил про обобщение и выделение в функции.

Я не знаю чем тут можно помочь. Могу ещё попробовать так: есть разные причины выделения кода в функцию, разные причины приводят к разным требованиям, которые предъявляются к функции, в частности и к разным стилям оформления функции. Скажем, зачем нужен документационный комментарий к static функции? Она всё равно не пойдёт в документацию, куда собирают внешние API.

Если это не помогает, то я сдаюсь. Я бессилен тебе что-либо объяснить. Может поймёшь, накопив опыта.

> Я искренне не понимаю: это такой тонкий троллинг, или ты на полном серьёзе сейчас кичишься своей безграмотностью в данном вопросе?

Грамотность переоценена. Вопрос в том, в состоянии ли ты написать надёжный работающий код или нет, а не в том, насколько ты грамотен или безграмотен. Мой подход позволяет мне писать код, который проходит все ревью, и потом просто работает. Насколько при этом я грамотен или безграмотен мне без разницы. И этот мой подход включает в себя отказ рыться в стандартах, если у меня есть сомнения, которые мне необходимо разрешить, я лучше с экспертом пообщаюсь, чем буду читать какой-то там стандарт. Если же я могу сомнения разрешить без эксперта и без стандарта, я их разрешу так. А если я могу обойтись без разрешения сомнений, написав ptr=NULL, то обойдусь без разрешения и напишу ptr=NULL, сэкономив кучу времени на этом.

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

Ответить | Правка | Наверх | Cообщить модератору

82. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 09-Авг-22, 13:45 
> Скажем, зачем нужен документационный комментарий к static функции?
> Она всё равно не пойдёт в документацию, куда собирают внешние API.

Намного короче и понятнее, чем предыдущие портянки текста. Более того, можно было сократить даже до одного предложения.

> Грамотность переоценена.
> Насколько при этом я грамотен или безграмотен мне без разницы.
> я лучше с экспертом пообщаюсь, чем буду читать какой-то там стандарт

А, ну понятно. Это "эксперты" вроде тебя, значит, комментят под новостями о Rust. Всё встало на свои места. А я и думаю, почему аргументы и факты не работают? Да потому что факты у них "переоценены".

Ответить | Правка | Наверх | Cообщить модератору

86. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (-), 09-Авг-22, 15:32 
> Намного короче и понятнее, чем предыдущие портянки текста. Более того, можно было сократить даже до одного предложения.

А, у тебя проблемы с длинными предложениями? Надо простые писать? Не осложнённые всякими деепричастными оборотами, так? И уж тем более не составные. Ок.

> А, ну понятно.

Нет. Ты опять не понял. Там опять были сложные предложения. Давай я тебе простыми изложу.

Инженерное дело -- это не о том, что ты наизусть помнишь. Инженерное дело о том, какую информацию ты можешь найти. И об умении опознать ситуацию, в которой надо искать.

Наизусть запоминать -- это уровень undergraduate студента. Потому что их академическая успешность измеряется способностью воспроизводить по памяти никому не нужные заученные знания.

/* Длинное предложение получилось, да? Давай я про инженеров скажу, там короче выйдет: */

Успешность инженера определяется не тем, как много стандартов он заучил. Успешность инженера определяется качеством произведённого им продукта.

> о Rust

Кто о чём, а опеннет о расте. Речь о C идёт, ты не заметил?

Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  –2 +/
Сообщение от Аноним (78), 09-Авг-22, 10:50 
> NULL в C - это просто ноль, приведённый к типу void*

Вообще нет. NULL - это не ноль. NULL - это именно специальное значение NULL, которое зависит от платформы. То, что в большинстве реализаций оно является нулём, не делает его нулём.

А с таким подходом ты можешь круто обосраться при переносе кода.

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

79. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 09-Авг-22, 13:10 
Понятно, здесь не умеют гуглить. Так и быть, сделаю это за вас:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

6.3.2.3 Pointers
An integer constant expression with the value 0, or such an expression cast to type
void *, is called a null pointer constant. If a null pointer constant is converted to a
pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function.

Надеюсь, никто не будет спорить с тем, что "целая константа со значением ноль" не зависит от платформы.

Ответить | Правка | Наверх | Cообщить модератору

83. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (69), 09-Авг-22, 13:50 
Теперь погугли, что делает calloc: кастует нулевые байты в нулевые указатели?
Ответить | Правка | Наверх | Cообщить модератору

84. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 09-Авг-22, 14:03 
Это уже все рамки разумного переходит.

Во-первых, кастовать не обязательно: "An integer constant expression with the value 0, OR such an expression cast to type void *". Во-вторых, найди мне в стандарте место, где говорится, что указатель, которому присвоили ноль, может по воле компилятора оказаться не нулевым.

Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (69), 09-Авг-22, 14:16 
Является ли блок из нулевых байтов "An integer constant expression with the value 0"?

Или (чтобы не было UB) надо сперва записать в блок по адресу "нулевой указатель", чтобы потом прочитать по этому адресу тот самый "нулевой указатель"?

Ответить | Правка | Наверх | Cообщить модератору

87. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 10-Авг-22, 14:03 
Знаешь, а ты прав. Я тут почитал доп. инфу и понял, что могут быть архитектуры, где null pointer не нулевой и не равен null pointer constant. При этом сравнение первого со вторым будет возвращать true, несмотря на фактически разные значения. И вообще, получается, что ты присваиваешь чему-то ноль, а там после этого не ноль. Пожалуй, это хорошо, что я уже давно не пишу на C - не только для пользователей, но и для моей психики.
Ответить | Правка | Наверх | Cообщить модератору

89. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (69), 10-Авг-22, 15:02 
Вот ты лучше расскажи своей логикой растомана. Почему, записывая массив байтов из нулей, хочешь из этого массива байтов прочитать (валидный) указатель? Раст позволяет такие вольности с преобразованиями типов?
Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 10-Авг-22, 20:46 
Вообще-то, это обычная логика. По-твоему, логично, что сущность с названием null pointer может быть не равна нулю? Почему-то null pointer constant всегда равна нулю, а null pointer - нет. Логично то, что можно получить не ноль, присвоив чему-то ноль в языке без перегрузки операторов? Логично то, что сравнение ненулевого значения с нулём возвращает true? Все смеются над JavaScript с его неявными преобразованиями, но кода это касаеться C - "это другое". Это не моя логика "неправильная", а в C логика не работает, потому что комитет стандартизации решил использовать ноль для обозначения невалидного указателя, а потом оказалось, что где-то нулевой адрес вполне легитимен, и теперь мы имеем терминологию, имеющую лишь косвенное отношение к реальности, и поведение компилятора, которое в народе называется ugly hacks. Но, конечно, это моя вина, что я не прочитал ВЕСЬ стандарт, а там наверняка где-то написано, что null pointer - это не всегда null. Ну и, конечно, всё-таки, лучше использовать специальную константу NULL и не выпендриваться, учитывая количество подводных камней в C.

Что касается Rust, там в 99.9% случаев вообще нет необходимости в сырых указателях, и код, аналогичный по смыслу clearenv(), будет написан совершенно иначе, примерно так:

use std::sync::Mutex;

pub enum ClearEnvError {
    MutexLock
}

pub fn clear_env() -> Result<(), ClearEnvError> {
    extern {
        static ENVIRON: Mutex<Vec<String>>;
    }

    unsafe { ENVIRON.lock() }
        .map(|mut environ| environ.clear())
        .map_err(|_| ClearEnvError::MutexLock)
}

Здесь есть и обработка ошибок и примитив синхронизации, необходимый для вызова функции из других потоков. Самое прекрасное - компилятор практически заставит всё это сделать, и чтобы накосячить, придётся дополнительно постараться.

Но если всё же понадобится иметь дело с сырыми указателями, то я просто прочитаю соответствующие главы документации и Rustonomicon, прежде, чем приступать к делу. И, конечно, споткнувшись в этой ветке на приколы с сишным понятием null pointer, на этот раз я буду читать доки внимательнее, хоть они и намного понятнее, чем стандарт C.

Ответить | Правка | Наверх | Cообщить модератору

88. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 10-Авг-22, 14:12 
Итак, после обсуждения ниже выяснилось, что в C, когда имеешь дело с указателями, ноль может стать не нулём, а не ноль может быть равным нулю. Простой язык, говорили они. Ну что же, получается, с calloc я сел в лужу, и код принимает такой вид:

int clearenv(void) {
    /* We would like to free previously set environment variables here,
     * but at least FreeBSD 5.1 doesn't let us */
    environ = malloc(sizeof(char*));
    if (environ)
        *environ = NULL;
    return environ ? CLEARENV_SUCCESS : CLEARENV_FAILURE;
}

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

75. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  –1 +/
Сообщение от Аноним (69), 08-Авг-22, 16:13 
Он как ыксперт по безопасным каракулям руст не разобрался в опасных каракулях си и увидел обнуление  после malloc, и хотел сказать, что ржавчина на серебряных пулях уничтожает таких монстров до полного обнуления.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

80. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от burjui (ok), 09-Авг-22, 13:15 
Очередной бессмысленный комментарий от очередного недалёкого анона. Бессмысленный он хотя бы потому, что оставлен уже после обсуждения того, что конкретно мне не нравится в коде. Я там факты привожу, почитай. Ты же умеешь читать код на C?
Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в HTTP-сервере muhttpd, открываяющая доступ к фай..."  +/
Сообщение от Аноним (68), 07-Авг-22, 18:03 
Ожидал всего что угодно, но такого. Они просто читают файл по относительному пути без каких либо проверок. Этот сервер писали школьники на уроках информатики?
Ответить | Правка | Наверх | Cообщить модератору

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

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




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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