The OpenNET Project / Index page

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

Уязвимости в PHP и PHPMailer

08.12.2018 10:36

В опубликованных на днях корректирующих обновлениях PHP 5.6.39, 7.0.33, 7.1.25 и 7.2.13 устранена неприятная уязвимость (CVE-2018-19518) в штатном PHP-дополнении IMAP, выявленная ещё в октябре. Уязвимость позволяет атаковать web-приложения для работы с электронной почтой или обойти системные ограничения доступа к функциям, выставляемые через опцию disable_functions в php.ini.

В случае запрета вызовов, подобных exec, system, shell_exec и passthru, уязвимость даёт возможность выполнить произвольный shell-код, в случае когда злоумышленники могут загрузить свой PHP-код на сервер (например, для продолжения атаки после эксплуатации уязвимостей в плагинах для загрузки пользовательских файлов). Уязвимость также может применяться для атаки на webmail-клиенты, позволяющие установить произвольное имя imap-сервера и передающих его в вызов imap_open без дополнительной проверки.

Суть проблемы в том, что функция imap_open, через которую осуществляется открытие соединения с IMAP-сервером, позволяет указать дополнительные параметры для обращения к почтовому ящику по сети. Возможно обращение к почтовому ящику на удалённом хосте не только с использованием протокола IMAP, но и по SSH (вызывается команда rsh, но в большинстве дистрибутивов она перенаправлена на ssh). SSH можно передать дополнительные параметры, в том числе через указание опции "-oProxyCommand=" можно определить команду для запуска прокси. Вместо прокси можно указать любой код, который будет выполнен при вызове функции imap_open. Для блокирования уязвимости в новых выпусках по умолчанию отключено обращение imap_open по rsh/ssh (imap.enable_insecure_rsh=false).

Концептуальный прототип эксплоита:


   $server = "x -oProxyCommand=echo\tZWNobyAnMTIzNDU2Nzg5MCc+L3RtcC90ZXN0MDAwMQo=|base64\t-d|sh}";
   imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError: ".imap_last_error());

Кроме того, раскрыты сведения об уязвимости (CVE-2018-19296) в PHPMailer, популярной библиотеке для организации отправки электронных писем из приложений на языке PHP, число пользователей которой оценивается в 9 миллионов (используется в WordPress, Drupal, 1CRM, SugarCRM, Yii и Joomla). Уязвимость позволяет организовать выполнение кода через подстановку ссылки на phar-файл в составе пути, например, при отправке письма с вложением или через манипуляции с параметрами DKIM. Устраняющее проблему исправление включено в состав релиза PHPMailer 6.0.6.

Полученный файл перед отправкой на email проверяется при помощи функции file_exists(), которая автоматически выполняет десериализацию метаданных из файлов Phar (PHP Archive) при обработке путей, начинающихся с "phar://", что позволяет применить технику атаки "Phar deserialization". Организовав загрузку специально оформленного Phar-файла под видом вложения, злоумышленник может добиться выполнения своего кода на сервере. Так как функция file_exists() определяет MIME-тип по содержимому, а не по расширению, возможна передача phar-файла под видом картинки (например, phar-файл будет разобран, если его передать как evil.jpg). Похожая уязвимость недавно была выявлена в phpBB.

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Неосмотрительное использование плагина jQuery-File-Upload делает многие сайты уязвимыми
  3. OpenNews: Уязвимость в движке для создания форумов phpBB
  4. OpenNews: Уязвимость, позволяющая удалённо выполнить код на сервере PHP-репозитория Packagist
  5. OpenNews: Критическая уязвимость в PHPMailer, применяемом в WordPress, Drupal и Joomla
  6. OpenNews: В PHPMailer выявлена ещё одна критическая уязвимость, вызванная недоработкой в PHP
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: php
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (91) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Blind Vic (ok), 11:09, 08/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >  устранена неприятная уязвимость

    Бывают приятные уязвимости?

     
     
  • 2.5, commiethebeastie (ok), 11:31, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +16 +/
    В айфонах которые.
     

  • 1.2, пох (?), 11:11, 08/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    то-то я удивлялся, чего это php_imap после установки не включается автоматически, как это происходит с любым нормальным модулем. Видимо, кто-то когда-то заглядывал в его прекрасный код и сделал выводы...

    что же, ждем новую серию ssh'ных червяков - теперь через PHPmailer и imap-через-ssh впридачу... время безумных гуанокодеров :-(

     
     
  • 2.3, annual slayer (?), 11:28, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    зато можно сделать бложик с комментиками!
     
  • 2.49, Онаним (?), 11:26, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну согласись, передавать юзеринпут в параметры модуля имап (да и в любые другие вызовы) без предварительной валидации - это идиотизм. Так можно и в GD "уязвимость" найти, если туда параметры $widht / $height для скейлинга без проверок передавать. Пара десятков запросов на 19200 x 10800 - и сервер счастлив.
     
     
  • 3.55, пох (?), 13:15, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Пара десятков запросов на 19200 x 10800 - и сервер счастлив.

    воркер просто обломится об out of memory, и ничего интересного не произойдет.

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

    А у тебя в коде невидимый и нерегулируемый лимит непонятно для чего.

    А вот запуск ssh вместо imap - это как-то, на мой взгляд, за гранью добра и зла. Но вполне в духе авторов пехепе.

     
     
  • 4.61, Онаним (?), 13:36, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1. Зависит от контекста. Окей, подбираем значения под размер памяти, и дальше уже обламывается в OOM весь контекст. Плюс ещё ресурсы CPU на обсчёт этого дела нужны.

    Согласись, допустим в генераторе thumbnails логично проверить размерчик, который хочет пользователь, не?

    2. Что значит невидимый и нерегулируемый? Добавляем tunables в конфигурацию, дальше желающие пострелять себе в ногу thumbnail'ами на 19200x10800 смогут легко это сделать. Но это будет их личная проблема.

    3. Запуск ssh из imap - это к аффтарам libc-client, пхп тут не особо при чём.

     
     
  • 5.65, пох (?), 16:59, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ну хз - вот были генераторы во времена дисплеев 800x600 - генерили превьюшки с п... текст свёрнут, показать
     
  • 4.62, Онаним (?), 13:39, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Суть в том, что пых, как и сишечка, кодера от выстрела себе в ногу не защищает никак. Совсем-совсем.

    И списывать на язык собственно нежелание валидировать user input (что есть нарушение одного из основных правил безопасности при программировании, тащем-то) смысла нет.

     

  • 1.4, Аноним (4), 11:29, 08/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пора на WT?
     
  • 1.7, Аноним (7), 12:29, 08/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Дыра с phar так и осталась нерешенной. Suhosin вам не поможет, только смена языка разработки.
     
     
  • 2.12, пох (?), 12:50, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    фффпринципе, полагаю, там хватит однострочного патча в легко находимом месте кода.
    Но вот сколько и чего при этом поломается...

     
  • 2.32, Аноним (32), 19:28, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нахрен он его вообще распаковывает? Чтобы проверить файлы "унутре"? file_exists должен проверять, а файл-то exists? При phar'е тупо ругаться на гавно. Но это не про php. У нас функция должна всё за всех и принимать параметры в любом порядке! Один url_fopen чего стоит.
     
     
  • 3.51, пох (?), 12:52, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Нахрен он его вообще распаковывает? Чтобы проверить файлы "унутре"?

    да.
    во всяком случае семантика такая. А что это нахрен никому не надо - авторов не беспокоило.

     
  • 2.47, Онаним (?), 11:22, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы передаёте поданное пользователем имя файла ("phar://...") в файловые операции над локальной ФС?
    У меня для вас плохие новости.
     
     
  • 3.52, пох (?), 13:01, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    да, передаем, потому что этот файл создан пользователем и имеет придуманное этим... текст свёрнут, показать
     
     
  • 4.56, Онаним (?), 13:18, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не надо хранить в базе то, что надо хранить в ФС. Но вот 100% валидации пользовательских данных никто не отменял.

    Если не хочется валидировать - значит не надо использовать: загруженному файлу присвоили внутренний ID, а оригинальное имя файла записали в БД или файл метаданных.

    Если же валидировать - валидировать полностью. Передали что-то, отличное от валидного имени файла - в баню. А то вам так и ../../../config/database_password.php для чтения передадут, и вы это благополучно сжуёте.

     
     
  • 5.70, пох (?), 18:15, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    anon 1025 mkdir phar anon 1026 touch phar test jpg anon 1027 ls -... текст свёрнут, показать
     
     
  • 6.71, Онаним (?), 18:43, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В данном случае невалиден мозг, разрешивший передавать аж целые каталоги в юзеринпуте.
     
     
  • 7.74, пох (?), 18:46, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    понятно все с вашими мозгами, гражданин пхп-обезьян.

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

    в общем, если до истории с phar у меня были какие-то сомнения что php не виноват, дело в разработчиках, то теперь я убежден что наоборот, разработчики и их любимая среда идеально соответствуют друг-другу.

     
  • 4.57, Онаним (?), 13:21, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это может понадобиться, когда ты используешь phar:// для доступа к собранным в один пакет данным приложения.  PHP, внезапно, это не только фронтендики для интернетико-магазинчиков.

    То же, что кто-то вдруг в наличии символа / в переданном ЮЗЕРОМ _имени файла_ проблемы не видит - это строго его ментальные проблемы.

     
     
  • 5.66, пох (?), 17:04, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Это может понадобиться, когда ты используешь phar:// для доступа к собранным в один пакет
    > данным приложения.

    и зачем оно вдруг имеет расширение .jpg?
    Отдельный вопрос - зачем вы используете апи для работы с файловой системой для работы с _исполняемым_кодом_? (ладно бы phar был просто архивом, это было бы относительно безобидной фичей языка)

    > То же, что кто-то вдруг в наличии символа / в переданном ЮЗЕРОМ

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

     
     
  • 6.72, Онаним (?), 18:44, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Будем проверять все конкретные расширения? Сегодня жпг, завтра гиф, послезавтра мп10?
    Не проще сразу изолироваться от возможных ошибок, храня юзерские имена отдельно от контента? А то юзер может захотеть ../../../etc/passwd похранить нечаянно, тоже будем?
     
     
  • 7.76, пох (?), 18:49, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Будем проверять все конкретные расширения?

    да. Очевидно, что если файл имеет расширение .jpeg, а внутри postscript - это хуже чем ошибка, это преступление.

    То есть это явная и недвусмысленная попытка взломать ваш чудо-сайтик с вероятностью 99%, и еще один оставим таки уникально-жопорукому юзеру, которуму лучше заблокировать акаунт до выяснения, чем подвергать риску остальных.

    И тем более надо отказываться выполнять исполняемый код, не имеющий правильного оформления в виде имени файла.

    Но нет, вы будете накручивать проверки на проверки, а потом опа, магия - .jpg исполняется тремя разными способами, спешите видеть чудо!

     
  • 7.84, пох (?), 19:31, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А то юзер может захотеть ../../../etc/passwd похранить нечаянно, тоже будем?

    а, кстати, почему нет, может он бэкап своего контейнера выложил? Разумеется, ниже ../../../backup/

    запретим пользоваться относительными путями?

    или все же может перестанем десериализовывать .jpeg при проверке его существования?

    с моей точки зрения выбор между этими двумя вариантами очевиден.

    с точки зрения разработчиков языка - тоже, но почему-то это разные выборы.

     
     
  • 8.98, Онаним (?), 09:27, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В имени файла, переданном пользователем типовому публичному web-приложению, вооб... текст свёрнут, показать
     
  • 6.73, Онаним (?), 18:46, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > юзер его не передает  - юзер выбирает путь, в удобной менюшечке интуитивно приятного интерфейса

    И вот тут ты очень правильно попал: в этом случае выбранное валидируется согласно этой самой менюшечке при любом доступе. Не просто берём переданный с потолка путь и открываем, а сравниваем на предмет присутствия в этой менюшечке. Не присутствует - в баню.

     
     
  • 7.78, пох (?), 18:54, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > а сравниваем на предмет присутствия в этой менюшечке

    функцией file_exists, да?

    (менюшечка была в форме, сейчас нам POST пришел - с параметрами заполненными с этой менюшечки...или не этой...хехе. Зашифруем всю форму и отправим вместе с постом, на предмет детальной проверки (еще pgp подписать не забудьте), так мыслит типичный *хороший* php-кодер?)

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

     
     
  • 8.88, Онаним (?), 20:15, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Менюшечка из libastral so Если нет, то описатель этой менюшечки есть сервер-сай... текст свёрнут, показать
     
     
  • 9.91, пох (?), 23:00, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ну ок, храни ее вечно - пока пользователь то ли нажмет submit, то ли передумает,... текст свёрнут, показать
     
     
  • 10.92, Онаним (?), 09:09, 10/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, правда PHP - очень удачная обёртка в виде небольшого рантайма с динамическо... текст свёрнут, показать
     

  • 1.8, Аноним (8), 12:35, 08/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >However, the unserialize is triggered for the phar:// wrapper in any file operation.

    Это - не уязвимость. Это - бекдор.

     
     
  • 2.11, Аноним (8), 12:47, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Извиняюсь, невнимательно прочитал. Это не уязвимость и не бэкдор. Это странный дизайн функций, задействующий фильтры через модификацию строк вместо ООП.
     
     
  • 3.41, Аноним (41), 04:43, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Функция может проверить содержится до файл в архиве или на фтп, что удобно
    Несомненно эта возможность является бэкдором
     
  • 2.14, Аноним (7), 13:08, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Там ведь можно еще заюзать udp:// tcp:// stream:// и tls:// верно?
     
  • 2.48, Онаним (?), 11:23, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это не бэкдор, это очень удобный механизм. К сожалению, в кривых руках, привыкших делать file_exists($_GET['file']) или $db->query("SELECT * FROM xyz WHERE abc = '{$_GET['abc']}'") он становится уязвимостью...
     
     
  • 3.86, Аноним (86), 20:08, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ага. я сам язык ниучём неуноват.
     
     
  • 4.87, Онаним (?), 20:15, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А никто вам защиту от выстрела в ногу не гарантировал )
     
     
  • 5.89, Аноним (86), 22:15, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Слово "гарантировал" в разработке ПО не используется. Поэтому аргумент не засчитывается.

    Разворачивать не стану, всё равно мой пост по политическим причинам сотрут и вы его не увидите.

     

  • 1.15, Аноним (15), 14:05, 08/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Интересно было бы узнать, где и с чем работают все эти немногочисленные хейтеры php и systemd.
     
     
  • 2.16, Аноним (7), 14:14, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
     
     
  • 3.17, Vitaliy Blats (?), 14:34, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.

    И шо, уже есть нормальные известные проекты на этом?)

     
     
  • 4.20, Аноним (20), 16:05, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Есть. Только никто не признаётся, на чём его проект, а то мамкины хацкеры, если узнают, перестанут бомбить их сайты типовыми эксплойтами для PHP, скачанными из сети. А это такой источник лулзов - вы даже не представляете!
     
     
  • 5.22, пох (?), 16:17, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а то мамкины хацкеры, если узнают, перестанут бомбить их сайты типовыми эксплойтами для 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/ckeditor/plugins/filema)

     
     
  • 6.24, Аноним (24), 16:48, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ROP Gadget в твою вордпреску, скомпилят как модуль ядра и подгрузят.
     
  • 6.31, Аноним (31), 18:58, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > ror, node ... в жанге

    Это все варианты, которые вам известны?

     
     
  • 7.34, пох (?), 21:49, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    не, это что я сходу у себя в логе нашел, помимо coldfusion'а и миллиона...чего это за зомбонет, я забыл, из хоменасов-то, весной появился? Судя по .cgi - на прекрасной сишечке ;-)

    жабы вот не видно что-то - то ли с regex неугадал, то ли не сезон, пакованный лог лень шерстить

     
     
  • 8.39, Sw00p aka Jerom (?), 01:10, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    поищи че нить такое 24 7B 28 23_memberAccess 5B 22allowStaticMethodAccess 22... текст свёрнут, показать
     
     
  • 9.43, пох (?), 09:28, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а, точно, cpyt-c же ж Не, такие продвинутые ко мне редко ходют, им проще подава... текст свёрнут, показать
     
  • 5.23, Vitaliy Blats (?), 16:39, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть. Только никто не признаётся, на чём его проект, а то мамкины
    > хацкеры, если узнают, перестанут бомбить их сайты типовыми эксплойтами для PHP,
    > скачанными из сети. А это такой источник лулзов - вы даже
    > не представляете!

    Значит нету. Что в принципе и требовалось доказать.
    Почти все фронтенды пишутся на PHP, потому что он одновременно отвечает сразу нескольким требованиям - легкости (а значит программисты на нем более дешевле), распространенности (а значит в сети много информации о нем), поддержке (а значит он может работать на чем угодно), относительной скорости работы (хотя для фронтенда она особо и не нужна), универсальности (а значит к нему написано много плагинов и фреймворков).

    Почти все конторы где работает больше пяти анонимусов, выставляют требования к проекту чтоб он РАБОТАЛ, чтоб он обошелся ДЕШЕВЛЕ, опционально чтоб его потом могло поддерживать более чем три человека на всю страну. Требований "чтоб был написан только на Ruby" я еще не видел за 10 лет работы в этой сфере.

    Разумеется ты конечно начнешь приводить аргументы типа "Ruby удобнее", "Python читабельнее", "Go секюрнее", но PHP не зря стал таким распространенным обогнав Perl, и чтобы ТВОЙ язык стали считать нормальным - он не должен быть удобнее, или читабельнее, или секюрнее. Он должен быть лучше одновременно во всем и сразу.

     
     
  • 6.29, Аноним (31), 18:51, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > чтоб он РАБОТАЛ

    Угу. "Чтоб он РАБОТАЛ" так, как нужно заказчику не только на момент приёмки от "студии веб-дизайна", но и через месяц, и через год. А когда "проект" впихивает юзерам малварь, сливает налево базу пользователей, майнит крипту на оплаченных заказчиком мощностях и т.д. - это не называется "чтоб он РАБОТАЛ".

     
     
  • 7.36, пох (?), 21:54, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    через год этот заказчик уже банкрот и сдает квартиру, благо ипотеку выплатил в жырном 2008м, когда деньги падали с неба даже в совершенно бестолковые руки.

    так что пусть помайнит - домен и хостинг оплачены со скидкой за двухгодичную разовую оплату, все равно пропадают.

     
  • 7.42, Аноним (41), 08:26, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Так не бывает. Поддерживать и исправлять уязвимости нужно постоянно и на любом языке.
     
     
  • 8.64, Аноним (64), 14:13, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Дык отож Только одно дело раз в день по диагонали просматривать письма от log a... текст свёрнут, показать
     
  • 6.37, User (??), 22:51, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >(а значит программисты на нем более дешевле),

    "более дешевле", да... ПыХаПэ-культура в двух словах, ага. Портрет явления, тскзть.
    За PHP Марьванна двойки не ставит - погнали, посоны!!!111

     
  • 6.85, Sw00p aka Jerom (?), 19:46, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>Почти все фронтенды пишутся на PHP

    фронтенды на пхп не пишут :)

     
  • 4.27, Аноним84701 (ok), 17:47, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
    > И шо, уже есть нормальные известные проекты на этом?)

    Если вы ничего не слышали о CloudFlare, GitHub, dl.google и Netflix, то у меня для вас неприятные новости.

     
     
  • 5.44, пох (?), 09:38, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
    >> И шо, уже есть нормальные известные проекты на этом?)
    > Если вы ничего не слышали о CloudFlare, GitHub, dl.google и Netflix, то
    > у меня для вас неприятные новости.

    окей, любитель приятных новостей - ни в какой из этих я работать не хочу, они тупые, жадные, и даже 401k matching от этих не дождешься (ну, может, если предъявить справку что ты - Оно, будет оплата препаратов, но мне как-то без надобности). Еще есть варианты, или это все?

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

     
     
  • 6.59, Аноним84701 (ok), 13:28, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > окей, любитель приятных новостей - ни в какой из этих я работать  не хочу, они тупые, жадные, и даже 401k matching от этих не дождешься (ну, может, если предъявить справку что ты - Оно,

    Держите нас в курсе! Нам ведь (почти) интересно!

    > заметим, что тут еще и ловкая подмена темы - спрашивали о проектах,
    > доступных для эксплуатации кем-то, а вы вывалили домашние поделки для работы

    Заметим, что тут еще и ловкая подмена темы на тему о подмене темы.
    Вся ветка, полностью:
    >>>> где и с чем работают все эти немногочисленные хейтеры php и systemd.
    >>>ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
    >> И шо, уже есть нормальные известные проекты на этом?)
    > Если вы ничего не слышали о CloudFlare, GitHub, dl.google и Netflix, то у меня для вас неприятные новости.

    "спрашивали о проектах, доступных для эксплуатации кем-то, а вы вывалили домашние поделки [...]"
    Мне вот интересно, вы когда нибудь научитесь читать целиком, по возможности глазами (и заодно отвечать на написаное другими, а не придуманное вами)?

     
     
  • 7.67, пох (?), 17:07, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ну ок, так и запишем - "в основном - нигде, основная ниша - внутренняя кухня аж трех громадных ентер-прайсов с сотными тысяч одних курьеров и вообще специфическими задачами и подходами к их решениям, то есть для обычных смертных == нигде"

     
  • 4.40, НяшМяш (ok), 02:45, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    github.com ?
     
  • 3.19, Аноним (19), 16:00, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Иными словами - в основном, нигде.
     
     
  • 4.25, Аноним (24), 16:50, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Пыхапистам виднее, ведь эти мамкины разработчики уже всему научены.
     
     
  • 5.26, Vitaliy Blats (?), 16:56, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Пыхапистам виднее, ведь эти мамкины разработчики уже всему научены.

    Если язык для своего понимания, требует какие-то особые скиллы и особую уличную магию, он УЖЕ НА СТАРТЕ не нужен.

    Пока мамкины разработчики пишут продукты, хорошие или не очень, ты изучаешь достоинства языка. Хе.

     
     
  • 6.30, Аноним (31), 18:53, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если разработчик не имеет хотя бы минимальной подготовки и набора скиллов, он УЖЕ НА СТАРТЕ не нужет.
     
     
  • 7.33, Анонн (?), 19:31, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Если разработчик не имеет хотя бы минимальной подготовки и набора скиллов, он УЖЕ НА СТАРТЕ не нужет.

    Осторожнее, эта братия при сильном негодовании не только бананами закидать может!


     
  • 7.35, пох (?), 21:52, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    как это не нужен? А кто мне будет за пиццот рублев чинить сдохший битрикс? Мне что, самому мараться?

     
     
  • 8.63, Аноним (64), 13:45, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ып ып ып ыбуэээ ... текст свёрнут, показать
     
     
  • 9.80, пох (?), 18:57, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    буэ свое можешь откладывать сколько влезет, только не на мой столик - мне чтоб з... текст свёрнут, показать
     
  • 3.38, vedronim (?), 23:06, 08/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это все, что ты смог нагуглить о языках?
     
     
  • 4.50, Аноним (7), 12:15, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Erlang/Ruby -> +Elixir
    + Crystal
    Nim
    Elm
    Dlang
    Haskell
    Scala
    Kotlin
    Swift
    Ponylang
     
  • 2.90, Аноним (86), 22:18, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > немногочисленные хейтеры php

    Определение слова "хейтер" и статистику по многочисленности - в студию.

    А то есть подозрение, молчек, что ты балабол.

     

  • 1.45, Онаним (?), 11:09, 09/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уязвимость выглядит как дерьмо, и реально дерьмо, но причина таковой - передача юзеринпута в различные вызовы без валидации.

    Кодер, помни: если ты забираешь что угодно ($server) с юзеринпута и фигачишь в вызовы библиотек (imap_open) без проверки на соответствие формата и валидность (в данном случае - доменное имя и возможно :порт) - в программировании тебе не место, да и руки видимо надо экстренно выпрямлять.

     
     
  • 2.53, пох (?), 13:09, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Кодер, помни: если ты забираешь что угодно ($server) с юзеринпута и фигачишь в вызовы
    > библиотек (imap_open) без проверки на соответствие формата и валидность

    проверку как производить будем - высунем окошко и будем ждать модератора-человека, чтоб одобрил? Иначе где гарантия, что код, используемый при этих проверках, сам не попытается выполнить передаваемые аргументы, как вот с file_exists (это ведь тоже была проверка на валидность, казалось бы, вполне нормальная - если бы функция не имела ложного названия)?

    Может все же где-то в консерватории поправить, а? Например, в $server принимать только и исключительно - server, а любые дополнительные параметры протокола передавать дополнительными аргументами? Не, не модно, не молодежно, мы любим прекрасные псевдо-uri ?

     
     
  • 3.58, Онаним (?), 13:23, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > проверку как производить будем

    В данном конкретном случае - регэкспом. Валидный формат доменного имени вполне себе описан. Никаких посторонних символов типа / в переданном пользователем $server для imap_open быть не должно.

    Попали опять не желающие проверять пользовательский ввод, впрочем, они попадают на любых языках, в любых ОС и всегда.

     
     
  • 4.69, пох (?), 17:16, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ну и зачем, зачем тогда вы накрутили в imap_open какие-то другие операции с этим $server без явного указания ?

    Кому оно надо, если от юзера мы такое не принимаем, спрашивается?

    очередной ненужный и опасный оверинжиниринг, прикрываем регекспами, как всегда.

    валидный формат доменного имени в эпоху юникодного мусора в dns - нечто уму непостижимое, если что. Я хз как его на валидность проверять (разьве что развернув сперва в punicode)

     
     
  • 5.75, Онаним (?), 18:48, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А затем, что у imap_open овердохера применений. И накрутили не совсем в пхп, а в либц-клиенте.

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

     
     
  • 6.81, пох (?), 19:03, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А затем, что у imap_open овердохера применений.

    честно говоря, применение в виде imap over rsh мне представляется требующим при сборке -DIWANNATHISSHITFULLMOUTH и еще пятнадцати рандомных чисел в правильной последовательности.

    применение в виде imap over rsh replaced by ssh - ну, может быть, какому-то ретрограду (считающему еще и ssh достаточно безопасным и надежным способом доступа к удаленному серверу без всякого основания) и надо, но скорее всего он mutt через вручную сконфигуренный туннель запустит, а ЭТО вообще ни один нормальный человек не использует.

    очередной типовой оверинжиниринг - ну ок, на сей раз не в php, видимо.

    > Если может быть только хостнейм

    а вдруг не только? Овердохераж  применений, вон, разработчики старались, сколько неведомой фигни туда затолкали, может и эта кому-то нужна (смешно если так сфейлится код, реально валидирующий инпут, но автор счел rsh допустимым инпутом - "вдруг кому-то очень-очень понадобится")

     

  • 1.46, Онаним (?), 11:17, 09/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что же до пыхмейлера - 250+ кб кода, чтобы банально сформировать и отправить MIME - пользующиеся этим счастьем ссзб и должны страдать :)
     
     
  • 2.54, пох (?), 13:10, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    где посмотреть на твои 25 строк кода, делающих то же самое? (exec metamail не катит)
     
     
  • 3.60, Онаним (?), 13:30, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Широкой публике - нигде.
    Чекнул у себя Email.php - 344 строки кода, 13.5 кб. Умеет mail(), SMTP (со STARTTLS), автоматически создаёт text/plain вложение из HTML, умеет аттачменты. Из того, что умеет PHPMailer - не умеет инлайн изображения (возложено на приложение), не умеет DKIM-подпись, не умеет OAuth и POP3-before-SMTP. Но это не стоит 200 кб.
     
     
  • 4.68, пох (?), 17:12, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну молодец, возьми с полки пирожок. Судя по отсутствию у тебя желания публиковать этот код - в нем есть, хехе, ньюансы.

    dkim и pop скорее всего реализуются банальными встроенными средствами (раз уж у нас imap внезапно сам без спросу лезет в ssh, то уж тут-то, поди, один лишний флажок поставить) так что, полагаю, дело все же не в этом.

     
     
  • 5.77, Онаним (?), 18:52, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Насчёт "скорее всего" по DKIM и POP - нет, в пхпмейлере там всё ногами, то есть руками. При этом им зачем-то приходится заголовки обратно разбирать при формировании, что добрую долю оверблоута добавляет.
     
     
  • 6.82, пох (?), 19:07, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    так его писали десять лет назад, если не больше - там еще много чего руками, что в php5.2 было только руками и можно. Понятно что пора уже напрячься и почистить... ну я чо, я менеджеров пнул, кодеры уже в пятницу выбежали с лопатами, няхай шкрябают.

    а в самопальном коде под 7.2+ скорее всего обойдется, но вряд ли это повод гордитьтся что уложился в одну переменную вместо тысяч строк кода. Просто это уже сделали за тебя (и не факт что хорошо ;-)


     
  • 5.79, Онаним (?), 18:57, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну и да, никаких "нюансов", влияющих на функционирование, там нет.

    Просто с поветрием современных оверблоутных PSR'ов с композерами, 100500 классами в 3 строчки, неймспейсами на каждый чих и прочими прелестями публиковать "чистые" олдскульные либы (1 либа/класс - 1 полностью реализованный функционал) бессмысленно.

    PHPMailer кстати ещё в этом плане тоже пока держится, там всего пяток файлов, которые надо вгрузить.

     
     
  • 6.83, пох (?), 19:09, 09/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ну фиг знает - если код хороший - есть смысл его выложить, один использовавший вместо пхпмэйлера - минус один (а может и десяток) источник спама и попыток хакнуть, тоже неплохо.

     
  • 6.94, Gemorroj (ok), 12:57, 10/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    да трендишь 100%, наверняка там вагон и телега багов будет с юникодом каким-нибудь и проч.
    и еще у тебя так же наверняка будут уязвимости. ты же ничего не знал про уязвимости в imap_open и утащил к себе 100500 строк сишного кода в виде php интерпретатора, чтобы "сформировать и отправить MIME".
     
     
  • 7.95, ваш КО (?), 14:55, 10/12/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    imap_open не имеет прямого отношения к отправке почты, которой занимается PHPMailer или его самодельная замена в 300 строк

     
  • 7.97, Аноним (97), 15:33, 10/12/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всё куда проще, я $_GET в вызовы не передаю, предварительно не обработав во все поля. Ни одна библиотека от криворукости не застрахует.
     

  • 1.93, Gemorroj (ok), 12:51, 10/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    новость об уязвимостях написали, а об релизе пхп 7.3 нет. совпадение? не думаю)
     
     
  • 2.99, Аноним (99), 12:26, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > новость об уязвимостях написали, а об релизе пхп 7.3 нет. совпадение? не
    > думаю)

    Вы рандомом что-ли новости для чтения выбирайте? Новость про PHP 7.3 была за день до новости про уязвимости.
    https://www.opennet.ru/opennews/art.shtml?num=49732

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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