В опубликованных (http://php.net/archive/2018.php) на днях корректирующих обновлениях PHP 5.6.39, 7.0.33, 7.1.25 и 7.2.13 устранена (http://php.net/ChangeLog-7.php#7.0.33) неприятная уязвимость (http://bugs.php.net/77153) (CVE-2018-19518 (https://security-tracker.debian.org/tracker/CVE-2018-19518)) в штатном PHP-дополнении IMAP, выявленная (https://antichat.com/threads/463395/#post-4254681) ещё в октябре. Уязвимость позволяет атаковать web-приложения для работы с электронной почтой или обойти системные ограничения доступа к функциям, выставляемые через опцию disable_functions в php.ini.В случае запрета вызовов, подобных exec, system, shell_exec и passthru, уязвимость даёт возможность выполнить произвольный shell-код, в случае когда злоумышленники могут загрузить свой PHP-код на сервер (например, для продолжения атаки после эксплуатации уязвимостей (https://www.opennet.me/opennews/art.shtml?num=49641) в плагинах для загрузки пользовательских файлов). Уязвимость также может применяться для атаки на webmail-клиенты, позволяющие установить произвольное имя imap-сервера и передающих его в вызов imap_open без дополительной проверки.
Суть проблемы в том, что функция imap_open, через которую осуществляется открытие соединения с IMAP-сервером, позволяет указать дополнительные параметры для обращения к почтовому ящику по сети. Возможно обращение к почтовому ящику на удалённом хосте не только с использованием протокола IMAP, но и по SSH (вызывается команда rsh, но в большинстве дистрибутивов она перенаправлена на ssh), которому можно передать дополнительные параметры, в том числе через указание опции "-oProxyCommand=" можно определить команду для запуска прокси. Вместо прокси можно указать любой код, который будет выполнен при вызове функции imap_open. Для блокирования уязвимости в новых выпусках по умолчанию отключено (https://github.com/php/php-src/commit/3a144d3f7f6bad308e2bf1...) обращение imap_open по rsh/ssh (imap.enable_insecure_rsh=false).
Концептуальный прототип эксплоита (https://github.com/Bo0oM/PHP_imap_open_exploit/blob/master/e...):
$server = "x -oProxyCommand=echo\tZWNobyAnMTIzNDU2Nzg5MCc+L3RtcC90ZXN0MDAwMQo=|base64\t-d|sh}";
imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError: ".imap_last_error());
Кроме того, раскрыты сведения об уязвимости (https://www.debian.org/security/2018/dsa-4351) (CVE-2018-19296 (https://security-tracker.debian.org/tracker/CVE-2018-19296)) в PHPMailer (https://github.com/PHPMailer/PHPMailer/), популярной библиотеке для организации отправки электронный писем из приложений на языке PHP, число пользователей которой оценивается в 9 миллионов (используется в WordPress, Drupal, 1CRM, SugarCRM, Yii и Joomla). Уязвимость позволяет организовать выполнение кода через подстановку ссылки на phar-файл в составе пути, например, при отправке письма с вложением. Устраняющее проблему исправление (https://github.com/PHPMailer/PHPMailer/commit/f1231a9771505f...) включено в состав релиза PHPMailer 6.0.6.
Полученный путь проверяется при помощи функции file_exists(), которая автоматически выполняет десериализацию метаданных из файлов Phar (PHP Archive), что позволяет применить технику атаки "Phar deserialization (https://blog.ripstech.com/2018/new-php-exploitation-technique/)". Организовав загрузку специально оформленного Phar-файла под видом вложения, злоумышленник может добиться выполнения своего кода на сервере. Так как функция file_exists() определяет MIME-тип по содержимому, а не по расширению, возможна передача phar-файла под видом картинки (напирмер, phar-файл будет разобран, если его передать как evil.jpg). Похожая уязвимость недавно была выявлена (https://www.opennet.me/opennews/art.shtml?num=49641) в phpBB.URL: https://www.openwall.com/lists/oss-security/2018/12/05/2
Новость: https://www.opennet.me/opennews/art.shtml?num=49746
> устранена неприятная уязвимостьБывают приятные уязвимости?
В айфонах которые.
то-то я удивлялся, чего это php_imap после установки не включается автоматически, как это происходит с любым нормальным модулем. Видимо, кто-то когда-то заглядывал в его прекрасный код и сделал выводы...что же, ждем новую серию ssh'ных червяков - теперь через PHPmailer и imap-через-ssh впридачу... время безумных гуанокодеров :-(
зато можно сделать бложик с комментиками!
Ну согласись, передавать юзеринпут в параметры модуля имап (да и в любые другие вызовы) без предварительной валидации - это идиотизм. Так можно и в GD "уязвимость" найти, если туда параметры $widht / $height для скейлинга без проверок передавать. Пара десятков запросов на 19200 x 10800 - и сервер счастлив.
> Пара десятков запросов на 19200 x 10800 - и сервер счастлив.воркер просто обломится об out of memory, и ничего интересного не произойдет.
если мы не знаем, что именно дальше будет делаться с этим изображением - лимит потребляемых ресурсов (а не косвенный третьей степени) - это единственное, что вообще можно сделать. Потому что вполне может быть, что через пять лет это не будет проблемой для сервера, а изображение именно такого размера пользователю для чего-то нужно.
А у тебя в коде невидимый и нерегулируемый лимит непонятно для чего.
А вот запуск ssh вместо imap - это как-то, на мой взгляд, за гранью добра и зла. Но вполне в духе авторов пехепе.
1. Зависит от контекста. Окей, подбираем значения под размер памяти, и дальше уже обламывается в OOM весь контекст. Плюс ещё ресурсы CPU на обсчёт этого дела нужны.Согласись, допустим в генераторе thumbnails логично проверить размерчик, который хочет пользователь, не?
2. Что значит невидимый и нерегулируемый? Добавляем tunables в конфигурацию, дальше желающие пострелять себе в ногу thumbnail'ами на 19200x10800 смогут легко это сделать. Но это будет их личная проблема.
3. Запуск ssh из imap - это к аффтарам libc-client, пхп тут не особо при чём.
> Согласись, допустим в генераторе thumbnails логично проверить размерчик, который хочет
> пользователь, не?ну хз - вот были генераторы во времена дисплеев 800x600 - генерили превьюшки с почтовую марку. Сейчас их приходится стирать к хренам, и генерить новые, потому что 800x600 это уже размер превьюшки, а не картинки.
А в эпоху 5" дисплеев 4k я вот хз какого размера должны быть тамбнейлы - очень может быть что и 4k много не будет.> Добавляем tunables в конфигурацию
сколько tunables мы туда добавим и какого она в итоге будет размера, если на всяк чих наздравствоваться?
Я еще могу понять, если размер превьюшки выбирается слайдером - воткнуть проверку соответствия диапазону слайдера присылаемых значений (если нет - нас пытаются поломать).но в целом это тоже достаточно бессмысленные телодвижения, когда нельзя четко определить, какой user input заведомо невалиден, а какой нет, и приходится на ровном месте рисовать новые и новые проверки.
пока программка простенькая - это будет прокатывать (если спрашивать отдельным диалогом для того же imap host/port/user/password - проверить просто. Если парсить урлы imap:// генеримые кем-то третьим - то, внезапно, все становится непонятно.)
и да, отдельный вопрос - сколько в мире настоящих серверов imap, реально требующих ssh для работы с ними и кто их странные пользователи?
по-моему, очевидно - overengineering - зло.
Суть в том, что пых, как и сишечка, кодера от выстрела себе в ногу не защищает никак. Совсем-совсем.И списывать на язык собственно нежелание валидировать user input (что есть нарушение одного из основных правил безопасности при программировании, тащем-то) смысла нет.
Пора на WT?
Дыра с phar так и осталась нерешенной. Suhosin вам не поможет, только смена языка разработки.
фффпринципе, полагаю, там хватит однострочного патча в легко находимом месте кода.
Но вот сколько и чего при этом поломается...
Нахрен он его вообще распаковывает? Чтобы проверить файлы "унутре"? file_exists должен проверять, а файл-то exists? При phar'е тупо ругаться на гавно. Но это не про php. У нас функция должна всё за всех и принимать параметры в любом порядке! Один url_fopen чего стоит.
> Нахрен он его вообще распаковывает? Чтобы проверить файлы "унутре"?да.
во всяком случае семантика такая. А что это нахрен никому не надо - авторов не беспокоило.
Вы передаёте поданное пользователем имя файла ("phar://...") в файловые операции над локальной ФС?
У меня для вас плохие новости.
да, передаем, потому что этот файл создан пользователем и имеет придуманное этим пользователем имя - идеи хранить в базе данных то, для чего изначально предназначена fs - засуньте себе туда, откуда у вас вывалилась прекрасная идея вместо файлов использовать всякую галиматью в любой функции, работающей с файлами, "зато как в винде!" (хотя винда хотя бы код не *исполняет* - это ваше уникальное достижение).А что его надо проверять еще и на "phar", а не только на ранее проверяемый миллион возможных в вашем прекрасном языке подстав - это вот ново, стильно и молодежно, кто-то был сверхосторожен и оно еще на этапе // улетит в помойку, а кому-то нужны были иерархии и в самих по себе // он проблемы не видел, и в двоеточиях тоже, это валидный символ.
А теперь расскажите, зачем вы вообще интерпретируете как phar (то же касается умничек из проекта ghostscript) то что не оканчивается на .phar, вместо возврата ошибки, и в каком реальном случае может понадобиться такая е..нина, кроме писания эксплойтов?
Не надо хранить в базе то, что надо хранить в ФС. Но вот 100% валидации пользовательских данных никто не отменял.Если не хочется валидировать - значит не надо использовать: загруженному файлу присвоили внутренний ID, а оригинальное имя файла записали в БД или файл метаданных.
Если же валидировать - валидировать полностью. Передали что-то, отличное от валидного имени файла - в баню. А то вам так и ../../../config/database_password.php для чтения передадут, и вы это благополучно сжуёте.
> Передали что-то, отличное от валидного имени файлаanon[1025] ~> mkdir phar:
anon[1026] ~> touch phar:/test.jpg
anon[1027] ~> ls -la phar://test.jpg
-rw-r--r-- 1 anon users 0 Dec 9 18:07 phar://test.jpg
что невалидного в данном имени файла?(сейчас начнется верчение ужом и классификация файлов на правильные и неправильные)
> А то вам так и ../../../config/database_password.php для чтения передадут, и вы это
> благополучно сжуёте.мы это можем (в отличие от вышеприведенного) проверить, причем двумя разными способами - честно распарсить путь (возможно - валидный, потому что все это происходит в ../../../../user-uploads/ !) или просто решить что parent-ссылки у нас запрещены - правильнее, безусловно, первое.
ну, разумеется, правильнее - в языке, где проверка существования файла не ведет к выполнению кода, а не в php.
потому что я не уверен что и нормализация перед проверкой (которая теоретически лечит первый пример) достаточна сегодня и всегда останется достаточной в свете новых макачьих изобретений.
ты можешь просто не знать о том, что именно альтернативно-одаренные разработчики сочли только вчера особым случаем, который надо обработать извращенным образом.
В данном случае невалиден мозг, разрешивший передавать аж целые каталоги в юзеринпуте.
понятно все с вашими мозгами, гражданин пхп-обезьян.юзер не должен передавать какие-то каталоги, пусть валит все в кучку, зато мы, виликие, безопасТно можем вместо путей использовать исполняемый код в файловом апи.
в общем, если до истории с phar у меня были какие-то сомнения что php не виноват, дело в разработчиках, то теперь я убежден что наоборот, разработчики и их любимая среда идеально соответствуют друг-другу.
Это может понадобиться, когда ты используешь phar:// для доступа к собранным в один пакет данным приложения. PHP, внезапно, это не только фронтендики для интернетико-магазинчиков.То же, что кто-то вдруг в наличии символа / в переданном ЮЗЕРОМ _имени файла_ проблемы не видит - это строго его ментальные проблемы.
> Это может понадобиться, когда ты используешь phar:// для доступа к собранным в один пакет
> данным приложения.и зачем оно вдруг имеет расширение .jpg?
Отдельный вопрос - зачем вы используете апи для работы с файловой системой для работы с _исполняемым_кодом_? (ладно бы phar был просто архивом, это было бы относительно безобидной фичей языка)> То же, что кто-то вдруг в наличии символа / в переданном ЮЗЕРОМ
юзер его не передает - юзер выбирает путь, в удобной менюшечке интуитивно приятного интерфейса, чтобы не валить все в одну помойку. В ваш код, разумеется, приедет имя файла с путем.
Не вижу ничего неправильного в этом.
Будем проверять все конкретные расширения? Сегодня жпг, завтра гиф, послезавтра мп10?
Не проще сразу изолироваться от возможных ошибок, храня юзерские имена отдельно от контента? А то юзер может захотеть ../../../etc/passwd похранить нечаянно, тоже будем?
> Будем проверять все конкретные расширения?да. Очевидно, что если файл имеет расширение .jpeg, а внутри postscript - это хуже чем ошибка, это преступление.
То есть это явная и недвусмысленная попытка взломать ваш чудо-сайтик с вероятностью 99%, и еще один оставим таки уникально-жопорукому юзеру, которуму лучше заблокировать акаунт до выяснения, чем подвергать риску остальных.
И тем более надо отказываться выполнять исполняемый код, не имеющий правильного оформления в виде имени файла.
Но нет, вы будете накручивать проверки на проверки, а потом опа, магия - .jpg исполняется тремя разными способами, спешите видеть чудо!
> А то юзер может захотеть ../../../etc/passwd похранить нечаянно, тоже будем?а, кстати, почему нет, может он бэкап своего контейнера выложил? Разумеется, ниже ../../../backup/
запретим пользоваться относительными путями?
или все же может перестанем десериализовывать .jpeg при проверке его существования?
с моей точки зрения выбор между этими двумя вариантами очевиден.
с точки зрения разработчиков языка - тоже, но почему-то это разные выборы.
В имени файла, переданном пользователем типовому публичному web-приложению, вообще не может существовать никаких путей. Хочешь выкладывать бэкап контейнера - выкладывай в tar.Если приложение не носит характер публичного web-приложения, там уже можно делать что угодно, понимая последствия.
> юзер его не передает - юзер выбирает путь, в удобной менюшечке интуитивно приятного интерфейсаИ вот тут ты очень правильно попал: в этом случае выбранное валидируется согласно этой самой менюшечке при любом доступе. Не просто берём переданный с потолка путь и открываем, а сравниваем на предмет присутствия в этой менюшечке. Не присутствует - в баню.
> а сравниваем на предмет присутствия в этой менюшечкефункцией file_exists, да?
(менюшечка была в форме, сейчас нам POST пришел - с параметрами заполненными с этой менюшечки...или не этой...хехе. Зашифруем всю форму и отправим вместе с постом, на предмет детальной проверки (еще pgp подписать не забудьте), так мыслит типичный *хороший* php-кодер?)
ну я смотрю, вы неплохо вертитесь ужом, придумывая все новые и новые интересные способы валидации того, что было бы вовсе не надо валидировать, используй ваш язык программирования нормальный апи.
Менюшечка из libastral.so? Если нет, то описатель этой менюшечки есть сервер-сайд, не надо ничего лишнего отправлять.
> Если нет, то описатель этой менюшечки есть сервер-сайд, не надо ничего лишнего отправлять.ну ок, храни ее вечно - пока пользователь то ли нажмет submit, то ли передумает, то ли пойдет пообедать.
в принципе, когда траффик был дорогой, мы так и делали.
но вообще-то опять же - хранить то что и так хранится в виде файловой системы только ради того чтоб ненароком не выполнить код при попытке проверить существование...
нет, ты правда считаешь ЭТО хорошим языком?
Да, правда. PHP - очень удачная обёртка в виде небольшого рантайма с динамической сборкой поверх тонны сишных библиотек. Удачнее не получилось, не получалось и не получается ни у кого уже лет 30.
>However, the unserialize is triggered for the phar:// wrapper in any file operation.Это - не уязвимость. Это - бекдор.
Извиняюсь, невнимательно прочитал. Это не уязвимость и не бэкдор. Это странный дизайн функций, задействующий фильтры через модификацию строк вместо ООП.
Функция может проверить содержится до файл в архиве или на фтп, что удобно
Несомненно эта возможность является бэкдором
Там ведь можно еще заюзать udp:// tcp:// stream:// и tls:// верно?
Это не бэкдор, это очень удобный механизм. К сожалению, в кривых руках, привыкших делать file_exists($_GET['file']) или $db->query("SELECT * FROM xyz WHERE abc = '{$_GET['abc']}'") он становится уязвимостью...
Ага. я сам язык ниучём неуноват.
А никто вам защиту от выстрела в ногу не гарантировал )
Слово "гарантировал" в разработке ПО не используется. Поэтому аргумент не засчитывается.Разворачивать не стану, всё равно мой пост по политическим причинам сотрут и вы его не увидите.
Интересно было бы узнать, где и с чем работают все эти немногочисленные хейтеры php и systemd.
ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
> ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.И шо, уже есть нормальные известные проекты на этом?)
Есть. Только никто не признаётся, на чём его проект, а то мамкины хацкеры, если узнают, перестанут бомбить их сайты типовыми эксплойтами для PHP, скачанными из сети. А это такой источник лулзов - вы даже не представляете!
> а то мамкины хацкеры, если узнают, перестанут бомбить их сайты типовыми эксплойтами для PHP,
> скачанными из сетискачают типовой эксплойт для поделок на ror, node и что там у вас еще за хлам, а, ну да, свежие баги в жанге забыли, и лулзы кончатся, начнутся поиски "как убрать чорного властелина с сайта".
вот, например, не-такие-как-все приходили:
/CFIDE/cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/filemanager.cfm" failed (2: No such file or directory)
(сорри, ребята, но нет у меня гармо... coldfusion'а - сюда вот идите, там есть: https://apps.wharton.upenn.edu/cf_scripts/scripts/ajax/ckedi.../)
ROP Gadget в твою вордпреску, скомпилят как модуль ядра и подгрузят.
> ror, node ... в жангеЭто все варианты, которые вам известны?
не, это что я сходу у себя в логе нашел, помимо coldfusion'а и миллиона...чего это за зомбонет, я забыл, из хоменасов-то, весной появился? Судя по .cgi - на прекрасной сишечке ;-)жабы вот не видно что-то - то ли с regex неугадал, то ли не сезон, пакованный лог лень шерстить
поищи че нить такое ))%24%7B%28%23_memberAccess%5B%22allowStaticMethodAccess%22%5D%3Dtrue%2C%23a%3D@java.lang.Runtime@getRuntime%28%29.exec%28%27{0}%27%29.getInputStream%28%29%2C%23b%3Dnew%20java.io.InputStreamReader%28%23a%29%2C%23c%3Dnew%20%20java.io.BufferedReader%28%23b%29%2C%23d%3Dnew%20char%5B51020%5D%2C%23c.read%28%23d%29%2C%23sbtest%3D@org.apache.struts2.ServletActionContext@getResponse%28%29.getWriter%28%29%2C%23sbtest.println%28%23d%29%2C%23sbtest.close%28%29%29%7D
а, точно, cpyt-c же ж. Не, такие продвинутые ко мне редко ходют, им проще подавай:GET /struts2-rest-showcase/orders.xhtml
а вот вообще прекрасное:
GET /struts-cookbook/processSimple.do;-)
кто там авторов безобидного js-аплоадера ругал за демо-скрипты без лишних проверок? Мощные жабисты, как видим, тоже не брезгуют. А админы ничерта не понимают в этой жабе, попросили их поставить, поставили.
> Есть. Только никто не признаётся, на чём его проект, а то мамкины
> хацкеры, если узнают, перестанут бомбить их сайты типовыми эксплойтами для PHP,
> скачанными из сети. А это такой источник лулзов - вы даже
> не представляете!Значит нету. Что в принципе и требовалось доказать.
Почти все фронтенды пишутся на PHP, потому что он одновременно отвечает сразу нескольким требованиям - легкости (а значит программисты на нем более дешевле), распространенности (а значит в сети много информации о нем), поддержке (а значит он может работать на чем угодно), относительной скорости работы (хотя для фронтенда она особо и не нужна), универсальности (а значит к нему написано много плагинов и фреймворков).Почти все конторы где работает больше пяти анонимусов, выставляют требования к проекту чтоб он РАБОТАЛ, чтоб он обошелся ДЕШЕВЛЕ, опционально чтоб его потом могло поддерживать более чем три человека на всю страну. Требований "чтоб был написан только на Ruby" я еще не видел за 10 лет работы в этой сфере.
Разумеется ты конечно начнешь приводить аргументы типа "Ruby удобнее", "Python читабельнее", "Go секюрнее", но PHP не зря стал таким распространенным обогнав Perl, и чтобы ТВОЙ язык стали считать нормальным - он не должен быть удобнее, или читабельнее, или секюрнее. Он должен быть лучше одновременно во всем и сразу.
> чтоб он РАБОТАЛУгу. "Чтоб он РАБОТАЛ" так, как нужно заказчику не только на момент приёмки от "студии веб-дизайна", но и через месяц, и через год. А когда "проект" впихивает юзерам малварь, сливает налево базу пользователей, майнит крипту на оплаченных заказчиком мощностях и т.д. - это не называется "чтоб он РАБОТАЛ".
через год этот заказчик уже банкрот и сдает квартиру, благо ипотеку выплатил в жырном 2008м, когда деньги падали с неба даже в совершенно бестолковые руки.так что пусть помайнит - домен и хостинг оплачены со скидкой за двухгодичную разовую оплату, все равно пропадают.
Так не бывает. Поддерживать и исправлять уязвимости нужно постоянно и на любом языке.
Дык отож!
Только одно дело раз в день по диагонали просматривать письма от log analyser'а и почитывать рассылку от разрабов в ожидании сведений об уязвимостях (а она чуть более чем полностью состоит из вопросов нубов "как мне сделать"), а другое дело когда каждый месяц надо что-то править, обновлять, накатывать, дампить-ресторить, и т.д.
>(а значит программисты на нем более дешевле),"более дешевле", да... ПыХаПэ-культура в двух словах, ага. Портрет явления, тскзть.
За PHP Марьванна двойки не ставит - погнали, посоны!!!111
>>Почти все фронтенды пишутся на PHPфронтенды на пхп не пишут :)
>> ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
> И шо, уже есть нормальные известные проекты на этом?)Если вы ничего не слышали о CloudFlare, GitHub, dl.google и Netflix, то у меня для вас неприятные новости.
>>> ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
>> И шо, уже есть нормальные известные проекты на этом?)
> Если вы ничего не слышали о CloudFlare, GitHub, dl.google и Netflix, то
> у меня для вас неприятные новости.окей, любитель приятных новостей - ни в какой из этих я работать не хочу, они тупые, жадные, и даже 401k matching от этих не дождешься (ну, может, если предъявить справку что ты - Оно, будет оплата препаратов, но мне как-то без надобности). Еще есть варианты, или это все?
заметим, что тут еще и ловкая подмена темы - спрашивали о проектах, доступных для эксплуатации кем-то, а вы вывалили домашние поделки для работы в огороженной сети с тыщами админов их постоянно подпирающих специально выпиленными костыликами.
> окей, любитель приятных новостей - ни в какой из этих я работать не хочу, они тупые, жадные, и даже 401k matching от этих не дождешься (ну, может, если предъявить справку что ты - Оно,Держите нас в курсе! Нам ведь (почти) интересно!
> заметим, что тут еще и ловкая подмена темы - спрашивали о проектах,
> доступных для эксплуатации кем-то, а вы вывалили домашние поделки для работыЗаметим, что тут еще и ловкая подмена темы на тему о подмене темы.
Вся ветка, полностью:
>>>> где и с чем работают все эти немногочисленные хейтеры php и systemd.
>>>ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
>> И шо, уже есть нормальные известные проекты на этом?)
> Если вы ничего не слышали о CloudFlare, GitHub, dl.google и Netflix, то у меня для вас неприятные новости."спрашивали о проектах, доступных для эксплуатации кем-то, а вы вывалили домашние поделки [...]"
Мне вот интересно, вы когда нибудь научитесь читать целиком, по возможности глазами (и заодно отвечать на написаное другими, а не придуманное вами)?
ну ок, так и запишем - "в основном - нигде, основная ниша - внутренняя кухня аж трех громадных ентер-прайсов с сотными тысяч одних курьеров и вообще специфическими задачами и подходами к их решениям, то есть для обычных смертных == нигде"
github.com ?
Иными словами - в основном, нигде.
Пыхапистам виднее, ведь эти мамкины разработчики уже всему научены.
> Пыхапистам виднее, ведь эти мамкины разработчики уже всему научены.Если язык для своего понимания, требует какие-то особые скиллы и особую уличную магию, он УЖЕ НА СТАРТЕ не нужен.
Пока мамкины разработчики пишут продукты, хорошие или не очень, ты изучаешь достоинства языка. Хе.
Если разработчик не имеет хотя бы минимальной подготовки и набора скиллов, он УЖЕ НА СТАРТЕ не нужет.
> Если разработчик не имеет хотя бы минимальной подготовки и набора скиллов, он УЖЕ НА СТАРТЕ не нужет.Осторожнее, эта братия при сильном негодовании не только бананами закидать может!
как это не нужен? А кто мне будет за пиццот рублев чинить сдохший битрикс? Мне что, самому мараться?
> битриксып... ып... ып... ыбуэээ....
буэ свое можешь откладывать сколько влезет, только не на мой столик - мне чтоб завтра сайт заработал, сделаешь - 500 рублей получишь.и ведь делают же ж :-(
Это все, что ты смог нагуглить о языках?
Erlang/Ruby -> +Elixir
+ Crystal
Nim
Elm
Dlang
Haskell
Scala
Kotlin
Swift
Ponylang
> немногочисленные хейтеры phpОпределение слова "хейтер" и статистику по многочисленности - в студию.
А то есть подозрение, молчек, что ты балабол.
Уязвимость выглядит как дерьмо, и реально дерьмо, но причина таковой - передача юзеринпута в различные вызовы без валидации.Кодер, помни: если ты забираешь что угодно ($server) с юзеринпута и фигачишь в вызовы библиотек (imap_open) без проверки на соответствие формата и валидность (в данном случае - доменное имя и возможно :порт) - в программировании тебе не место, да и руки видимо надо экстренно выпрямлять.
> Кодер, помни: если ты забираешь что угодно ($server) с юзеринпута и фигачишь в вызовы
> библиотек (imap_open) без проверки на соответствие формата и валидностьпроверку как производить будем - высунем окошко и будем ждать модератора-человека, чтоб одобрил? Иначе где гарантия, что код, используемый при этих проверках, сам не попытается выполнить передаваемые аргументы, как вот с file_exists (это ведь тоже была проверка на валидность, казалось бы, вполне нормальная - если бы функция не имела ложного названия)?
Может все же где-то в консерватории поправить, а? Например, в $server принимать только и исключительно - server, а любые дополнительные параметры протокола передавать дополнительными аргументами? Не, не модно, не молодежно, мы любим прекрасные псевдо-uri ?
> проверку как производить будемВ данном конкретном случае - регэкспом. Валидный формат доменного имени вполне себе описан. Никаких посторонних символов типа / в переданном пользователем $server для imap_open быть не должно.
Попали опять не желающие проверять пользовательский ввод, впрочем, они попадают на любых языках, в любых ОС и всегда.
ну и зачем, зачем тогда вы накрутили в imap_open какие-то другие операции с этим $server без явного указания ?Кому оно надо, если от юзера мы такое не принимаем, спрашивается?
очередной ненужный и опасный оверинжиниринг, прикрываем регекспами, как всегда.
валидный формат доменного имени в эпоху юникодного мусора в dns - нечто уму непостижимое, если что. Я хз как его на валидность проверять (разьве что развернув сперва в punicode)
А затем, что у imap_open овердохера применений. И накрутили не совсем в пхп, а в либц-клиенте.Ещё раз: не "прикрываем регекспами", а именно валидируем. Если может быть только хостнейм - валидируем регэкспом на соответствие. Если может быть только полтора сервера из менюшечки - проверяем присутствие. Передавать голый юзеринпут сторонней библиотеке без валидации опасно в любом языке и любом контексте.
> А затем, что у imap_open овердохера применений.честно говоря, применение в виде imap over rsh мне представляется требующим при сборке -DIWANNATHISSHITFULLMOUTH и еще пятнадцати рандомных чисел в правильной последовательности.
применение в виде imap over rsh replaced by ssh - ну, может быть, какому-то ретрограду (считающему еще и ssh достаточно безопасным и надежным способом доступа к удаленному серверу без всякого основания) и надо, но скорее всего он mutt через вручную сконфигуренный туннель запустит, а ЭТО вообще ни один нормальный человек не использует.
очередной типовой оверинжиниринг - ну ок, на сей раз не в php, видимо.
> Если может быть только хостнейм
а вдруг не только? Овердохераж применений, вон, разработчики старались, сколько неведомой фигни туда затолкали, может и эта кому-то нужна (смешно если так сфейлится код, реально валидирующий инпут, но автор счел rsh допустимым инпутом - "вдруг кому-то очень-очень понадобится")
Что же до пыхмейлера - 250+ кб кода, чтобы банально сформировать и отправить MIME - пользующиеся этим счастьем ссзб и должны страдать :)
где посмотреть на твои 25 строк кода, делающих то же самое? (exec metamail не катит)
Широкой публике - нигде.
Чекнул у себя Email.php - 344 строки кода, 13.5 кб. Умеет mail(), SMTP (со STARTTLS), автоматически создаёт text/plain вложение из HTML, умеет аттачменты. Из того, что умеет PHPMailer - не умеет инлайн изображения (возложено на приложение), не умеет DKIM-подпись, не умеет OAuth и POP3-before-SMTP. Но это не стоит 200 кб.
ну молодец, возьми с полки пирожок. Судя по отсутствию у тебя желания публиковать этот код - в нем есть, хехе, ньюансы.dkim и pop скорее всего реализуются банальными встроенными средствами (раз уж у нас imap внезапно сам без спросу лезет в ssh, то уж тут-то, поди, один лишний флажок поставить) так что, полагаю, дело все же не в этом.
Насчёт "скорее всего" по DKIM и POP - нет, в пхпмейлере там всё ногами, то есть руками. При этом им зачем-то приходится заголовки обратно разбирать при формировании, что добрую долю оверблоута добавляет.
так его писали десять лет назад, если не больше - там еще много чего руками, что в php5.2 было только руками и можно. Понятно что пора уже напрячься и почистить... ну я чо, я менеджеров пнул, кодеры уже в пятницу выбежали с лопатами, няхай шкрябают.а в самопальном коде под 7.2+ скорее всего обойдется, но вряд ли это повод гордитьтся что уложился в одну переменную вместо тысяч строк кода. Просто это уже сделали за тебя (и не факт что хорошо ;-)
Ну и да, никаких "нюансов", влияющих на функционирование, там нет.Просто с поветрием современных оверблоутных PSR'ов с композерами, 100500 классами в 3 строчки, неймспейсами на каждый чих и прочими прелестями публиковать "чистые" олдскульные либы (1 либа/класс - 1 полностью реализованный функционал) бессмысленно.
PHPMailer кстати ещё в этом плане тоже пока держится, там всего пяток файлов, которые надо вгрузить.
ну фиг знает - если код хороший - есть смысл его выложить, один использовавший вместо пхпмэйлера - минус один (а может и десяток) источник спама и попыток хакнуть, тоже неплохо.
да трендишь 100%, наверняка там вагон и телега багов будет с юникодом каким-нибудь и проч.
и еще у тебя так же наверняка будут уязвимости. ты же ничего не знал про уязвимости в imap_open и утащил к себе 100500 строк сишного кода в виде php интерпретатора, чтобы "сформировать и отправить MIME".
imap_open не имеет прямого отношения к отправке почты, которой занимается PHPMailer или его самодельная замена в 300 строк
Всё куда проще, я $_GET в вызовы не передаю, предварительно не обработав во все поля. Ни одна библиотека от криворукости не застрахует.
новость об уязвимостях написали, а об релизе пхп 7.3 нет. совпадение? не думаю)
> новость об уязвимостях написали, а об релизе пхп 7.3 нет. совпадение? не
> думаю)Вы рандомом что-ли новости для чтения выбирайте? Новость про PHP 7.3 была за день до новости про уязвимости.
https://www.opennet.me/opennews/art.shtml?num=49732