Критическая уязвимость в Lighttpd FastCGI

знамо хватит. Он у нас на 32M/ARM крутится.

у меня ARMe стоит boa, кто нибудь может прокоментировать,
что это за зверь?

> Не говорите чушь. Эта поделка на 170 килобайт не умеет даже kqueue и epoll.

А я не видел, чтоб в списке требований были kqueue и epoll. Спрашивался лёгкий вебсервер, но не lighttpd. Прикрутить kqueue и epoll в готовый код, на мой взгляд, гораздо проще, чем написать приличный вебсервер с нуля. И в чём смысл связывать размер кода с качеством? Чем больше, тем лучше, так что ли? Не помню, кто-то из гуру однажды сказал, что качественная софтина - это не та, в которую уже ничего добавить, а та, из которой уже нечего выбросить. А как вебсервер, mathopd просто замечателен, и на голову выше многих других по совокупности своих достоинств и недостатков.

> у меня ARMe стоит boa

Он был когда-то странной, игрушкой безымянной... Вроде что-то в нём есть, я в своё время тестировал, но бросил. Не оправдал он, усилий на него затраченных. И, если не ошибаюсь, дыры в безопасности были. Настройка странновастенькая. Правда, давно это было, ещё в прошлом тысячелетии ;)

>> Спрашивался лёгкий вебсервер, но не lighttpd.
>> Mathopd просто замечателен, и на голову выше многих других по совокупности своих достоинств и недостатков.
к сожалению, он не подходит как замена lighty/nginx, т.к.
- недостаточно производителен
- недостаточно функционален
- тот функционал что есть недостаточно гибок в настройке

Впрочем если всё это не требуется - то как лёгкий вебсервер он вполне приемлим :)

> - недостаточно производителен
>- недостаточно функционален
>- тот функционал что есть недостаточно гибок в настройке

Всё это общие фразы, ничего конкретного.
Он быстрее, чем апаче. Он совсем не намного медленнее lighttpd
(примерно на 20%). Он очень функционален для своих размеров.
Пирожки не печёт, кофе не варит - это да. И он достаточно гибок в
настройках. Что конкретно вы имели в виду? Огромный его плюс -
Mathopd можно поставить и забыть, а lighttpd периодически о себе
напоминает дырками, nginx - ошибками, типа "gateway чего-то там".

>Огромный его плюс - Mathopd можно поставить и забыть, а lighttpd периодически о себе напоминает дырками

"Принцип Неуловимого Джо"?

Кстати, на Секунии у Mathopd две ошибки (на секьюритилаб - три). У Lighttpd - 13 ошибок. У Apache - 416. У nginx - 0.

Можно ли делать хоть какие-то выводы? :)

какие есть еще есть webservers for embedded?
можно даже "одноконнектные". есть ли обзор по эток теме?

> "Принцип Неуловимого Джо"?

В последнюю очередь - да. У mathopd самый чистый, самый красивый и самый понятный код. Это отмечают все, кто хоть раз заглядывал в его сорцы. Любой спец по безопасности уже по одному этому признаку сразу даст +5 баллов при прочих равных условиях.

> Кстати, на Секунии у Mathopd две ошибки (на секьюритилаб - три).

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

> У nginx - 0.

Ему лет без году неделя. И здесь уже говорилось как минимум про одну ошибку в fastcgi. Плюс сорцы не читаемые.

В любом случае я надёжность ставлю выше скорости. Скорость - не проблема. Мощность железа удваивается каждые два года, и стОит оно копейки. Дорого время админов. Поэтому мой выбор - однозначно mathopd. Я его использую на всех своих проектах уже 8 лет. Вот и сделайте выводы...

> какие есть еще есть webservers for embedded?

Да вагон их и маленькая тележка. Опиши, какие задачи ставишь.

>Не знаю, о чём они, на моей памяти была только одна серьёзная много лет назад.

http://www.securitylab.ru/search/index.php?q=Mathopd&s.x=13&s.y=7

Первая уязвимость - ерунда. Чтоб ей сработать нужно открыть в
конфиге разрешение на показ dump-файлов. Это что-то типа дебага.
Уязвимость незачётная. Остальные две - как я и говорил были, но
много лет назад, когда nginx'a ещё в проекте не было.

> У mathopd самый чистый, самый красивый и самый понятный код.
> Это отмечают все, кто хоть раз заглядывал в его сорцы.

улыбнуло и заинриговало.

>Да вагон их и маленькая тележка. Опиши, какие задачи ставишь.

Надо програмировать железку
http://www.kip.uni-heidelberg.de/ti/DCS-Board/current/
arm linux, busy box, boa web server

- драйвер написан
- некий command line shell тоже
- хотелось бы написать ГУЙ доступный через web

> Первая уязвимость - ерунда.

Блин, сейчас посмотрел внимательно... а ведь по той ссылке на
securitylab.ru откровенная деза написана.

Сравните. На сайте олигофренов написано: "Уязвимость позволяет
локальному пользователю перезаписать произвольные файлы на
системе.".

А вот оригинальное объявление об уязвимости от автора mathopd:

"...could be exploited to append to arbitrary files writable by the server's
UID.". То есть, фактически, на рабочем сервере запись можно
сделать в файлы и каталоги, доступные для записи пользователю
'nobody' или 'www'. В нормальной системе таких файлов и каталогов
быть не должно... Журналюги переврали конкретно.

> хотелось бы написать ГУЙ доступный через web

Вопрос в том, что выбрать для написания гуя? CGI-скрипты. Boa вполне пригоден для запуска CGI-скриптов. Если нужно быстро, дёшево и лёгкое по ресурсам... из скриптовых языков я бы выбрал newlisp. Самое оно для такой системы. Ну, или perl на крайний случай. Php будет медленее, но ещё терпимо, python ещё медленнее, ruby совсем туго. Fastcgi на такой девайс ставить нецелесообразно по многим причинам.

>> nginx - ошибками, типа "gateway чего-то там".
Ничего личного, но Вы идиот или так, для дури прикидываетесь ?

>> Ему лет без году неделя. И здесь уже говорилось как минимум про одну ошибку в fastcgi. Плюс сорцы не читаемые.
5 лет - это без году неделя ?
Ошибка в fcgi - реализуема не менее сложно чем в mathopd, и по степени была менее критичной, прав на запись точно не давала :)

Местная ЛОРовская истерия по поводу нечитаемости сорцов nginx меня прям умиляет.
Просто для работы с ними иногда требуется мозг, как это не странно :)

раз уже вы так любите mathopd - может объясните почему в нём до сих пор нет современных средств обработки соединение ?
или то что он остановился на уровне инструментария 96 года - это плюс ?

Есть вообще по меньшей мере 3 вещщи которые мешают его массовому / нормальному использованию
- нет нормальной работы с fastcgi
- нет проксирования - а это прям очень облегчает жизнь апачу
- Alias'ы не поддерживают регэкспы, а знаяит не веб сервер конфигуриуется под задачи, а сайты переделываются под возможности веб сервера. Что иногда неприемлимо.

>> Мощность железа удваивается каждые два года, и стОит оно копейки.
Если придерживаться такой идеологии, то и mathopd не нужен :)
Скорость же дисков кстати вот никак не хочет удваиваться раз в два года :)

httpd из ucLinux (ELF = 18Kb)
thttpd (ELF=76Kb)
mini_httpd (ELF=41Kb)
встроенный в busybox, там тоже CGI есть.

а, ну и microhttpd конечно :)

> >> nginx - ошибками, типа "gateway чего-то там". Ничего личного, но Вы идиот или так, для дури прикидываетесь ?

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

> Ошибка в fcgi - реализуема не менее сложно чем в mathopd, и по степени была менее критичной, прав на запись точно не давала :)

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

> Просто для работы с ними иногда требуется мозг, как это не странно :)

Я бы добавил к этому - глубоко извращённый мозг.

> почему в нём до сих пор нет современных средств обработки соединение ?

А конкретнее?

> - нет нормальной работы с fastcgi

Из какого пальца высосано это утверждение? Неправда.

>- нет проксирования - а это прям очень облегчает жизнь апачу

Для проксирования существуют прокси... Удивительно, да? ;)

>- Alias'ы не поддерживают регэкспы, а знаяит не веб сервер конфигуриуется под задачи, а сайты переделываются под возможности веб сервера. Что иногда неприемлимо.

И прекрасно, что не существуют. Приучает к порядку. Все виртуальные хосты подчиняются единому правилу. А без порядка массовый хостинг превращается в огромную головную боль, что мы и наблюдаем у 90% провайдеров.

>> Я в курсе проблемы, но, честно говоря, мне абсолютно не интересны причины, почему так происходит. В данном случае я занимаю позицию стороннего наблюдателя, который фиксирует наличие проблемы, не вдаваясь в подробности.
Ей богу, лучшеб он (nginx) тупо мочал :) Чтоб на него не перносили чужие проблемы.
Mathopd в этом вопросе прощще - он не умеет проксировать :)

С ошибками значит определились - ни там ни там security-критичных небыло.

>> почему в нём до сих пор нет современных средств обработки соединение ?
>А конкретнее?
вам уже написали - epoll, kqueue

Про мозг не скажу, но временами, смотря на свои решения, с вами совершенно согласен. Впрочем для меня мощность имеющегося железа всегда основное ограничение, вот и приходится ...

>> Для проксирования существуют прокси... Удивительно, да? ;)
да, удивительно ! посоветуйте плиз как на тот же ip/порт что и mathopd повесить прокси ! И какой - чтоб был лёгкий и эффективный ? И без кеширования заодно, а то все прокси почемуто кеширующщие :)


Впрочем, если вам хватает возможностей mathopd - я только рад за вас !