Доступны (http://php.net/archive/2015.php#id2015-08-06-4) корректирующие выпуски языка программирования PHP 5.6.12, 5.5.28 и 5.4.44, в которых устранены двенадцать уязвимостей и исправлена порция ошибок (http://php.net/ChangeLog-5.php). Большая часть уязвимостей может привести к отказу в обслуживании и проявляется в дополнениях (SPL, GD, SOAP, ODBC и OpenSSL). Уязвимость также выявлена в коде работы с директориями (https://bugs.php.net/bug.php?id=70002временными). Не обошлось и без ставших привычными уязвимостей в функции сериализации данных (unserialize) - 69793 (https://bugs.php.net/bug.php?id=69793) и 70121 (https://bugs.php.net/bug.php?id=70121).Одновременно сообщается о приближении ветки PHP 5.4 к концу цикла поддержки (http://php.net/supported-versions.php) (последний выпуск ожидается в сентябре или октябре), а также переводе ветки PHP 5.5 на стадию финального сопровождения, на которой прекращено исправление ошибок общего плана и устраняются только уязвимости.
URL: http://php.net/archive/2015.php#id2015-08-06-4
Новость: http://www.opennet.me/opennews/art.shtml?num=42745
> двенадцать уязвимостей и исправлена порция ошибокСколько читаю новости каждый раз по *нацать или больше УЯЗВИМОСТЕЙ и куча ОШИБОК. Пользоваться PHP - себя не уважать.
Спасибо за комментарий! Ваше мнение очень важно для нас!
Это не мнение, а результат полученный анализом фактов последних новостей связанных с выпуском PHP.Пользоваться PHP могут только те кто может спокойно жить по принципу "жрать что приходится". Но я ведь не ущемляю ваше право выбора, как и не ущемляю право людей копаться в помойках.
Результат является вскукареком безработного, выучившего с горем пополам сишку и завидующего успешным java и php разработчикам.
> Результат является вскукареком безработного, выучившего с горем пополам сишку и завидующего успешным java и php разработчикам.Конечно. Успокаивайте себя этим несколько раз на дню. Я разрешаю.
Сколько можно уже делать высеров насчет PHP? Да, обычный шаблонизатор. Да без поддержки потоков рашньше был. Сегодня вполне себе годный язык. Для быстрой разработки сайтов и быстрого деплоя. Есть и достоинства и недостатки. Что за притеснение по языковому признаку. А ответка тоже не ахти. За что Вы так на java или с++ они вам не конкуренты разные совершенно рынки. И да рынок фундаментальной разработки в России страдает, так как пользователи пока не готовы к заказам сложнее сайтов, но это не проблема программистов, а проблема рынка... От того страдают программисты
Типа в других программах ошибки никогда не находят
во многих находят. но интенсивность очень разная. вспомним тот же флэш.
Если ПХП и Флэш - программы, то ХТМЛ - язык программирования.
А вот и гладиолус :)
> Если ПХП и Флэш - программы,flash-плеер вполне себе программа
> то ХТМЛ - язык программирования.
рекомендую найти толкового психотерапевта и не пугать окружающих загибами своего воображения
> Если ПХП и Флэш - программы, то ХТМЛ - язык программирования.php написан на с, чем вам не программа? Ах да, забыл, нет окошек! :D
> во многих находят. но интенсивность очень разная. вспомним тот же флэш.
покажите мне "сложную" программу, которая используется на миллионах хостов и без "почти" уязвимостей
> покажите мне "сложную" программу, которая используется на миллионах хостов и без "почти" уязвимостейЕсли бы в nginx, apache, openssh, vsftpd и других нормальных программах закрывали бы через каждые несколько недель по *надцать УЯЗВИМОСТЕЙ и куче ОШИБОК, то нормальный люд давно бы взвыл и выкинул бы к чертям собячим такой мусор.
PHP спасает только то что нормальный люд не пользуется им, это для всяких неосиляторов, недопрограммистов и школьников. Лично я не понимаю как можно пользоваться такой хренью в которой за нескоько месяцев закрыли полсотни уязвимостей и не меньше ошибок. Сразу возникают вопросы о качестве исполнения: сколько там их еще осталось и сколько новых уязвимостей сделали пока закрывали старые? Спасибо, но пользоваться этим я не буду никогда.
В таких случаях предлагайте альтернативу, чтобы быть конструктивным.
Accelerate your development with Lucee: http://lucee.org/
> Если бы в nginx, apache, openssh, vsftpd и других нормальных программах закрывали бы через каждые несколько недель по *надцать УЯЗВИМОСТЕЙ и куче ОШИБОК, то нормальный люд давно бы взвыл и выкинул бы к чертям собячим такой мусор.Откройте глаза. А потом откройте ченджлоги nginx, apache, openssh, vsftpd или любого другого крупного проекта и посмотрите на количество багфиксов.
> Спасибо, но пользоваться этим я не буду никогда.
Держите нас в курсе.
да когда ж они все исправят наконец
> Если бы в nginx, apache, openssh, vsftpd и других нормальных программах закрывали бы через каждые несколько недель по *надцать УЯЗВИМОСТЕЙ и куче ОШИБОК, то нормальный люд давно бы взвыл и выкинул бы к чертям собячим такой мусор.т.е. в nginx apache, openssh, vsftpd ошибок нет? Странно что на том же RHEL выходят постоянные обновления на них. Вот если бы там, среди этих 12, было RCE или повышения привилегий, то можно было с пеной у рта кричать что похапэ решето. А так ни о чем
Вы действуете не честно: речь не о том что есть ошибки или нет ошибок, речь идет О СУММАРНОМ КОЛИЧЕСТВЕ УЯЗВИМОСТЕЙ И ОШИБОК за несолько месяцев и в PHP вопрос идет вопрос на СОТНИ. И где в этих проектах закрытые сотни проблем? Хуже PHP я пока ничего не знаю (flash даже не рассматриваю, т.к. это лишь решение под браузер который уже почти выбросили).
> речь идет О СУММАРНОМ КОЛИЧЕСТВЕ УЯЗВИМОСТЕЙ И ОШИБОК за несолько месяцев и в PHP вопрос идет вопрос на СОТНИ.Количество - не единственный показатель. Вы сначала попробуйте эксплуатировать хотя бы одну из этих уязвимостей, на каком-нибудь реальном проекте, тогда и поговорим. Или может приведете пример, когда бы ошибка в самом PHP привела к массовому взлому сайтов? Реальность такова, что большинство этих багов находят в API, которым или пользуется 3,5 человека, или для воспроизведения бага требуется сочетание каких-нибудь нереальных условий.
> И где в этих проектах закрытые сотни проблем?
Да в любом крупном проекте. http://nginx.org/en/CHANGES - каждый месяц по нескольку багфиксов. И что? Ну давайте в других языках посмотрим: https://docs.python.org/3/whatsnew/changelog.html - что, большая разница? Короче говоря, умерьте свой капслок. И ещё: http://www.opennet.me/opennews/art.shtml?num=15991
>> речь идет О СУММАРНОМ КОЛИЧЕСТВЕ УЯЗВИМОСТЕЙ И ОШИБОК за несолько месяцев и в PHP вопрос идет вопрос на СОТНИ.
> Количество - не единственный показатель.Истинно так. Поэтому надо не тупо таращиться на количество багфиксов, а сравнивать количество CVE. И тут внезапно выясняется, что flash и ослик делают всех как стоячих.
> среди этих 12, было RCE или повышения привилегий, то можно было
> с пеной у рта кричать что пoхапэ рeшето. А так ни
> о чемНу вот в семeрoчке (а это всего-то какая-то маргинaльная ОСь) 125 RCE дырок http://www.cvedetails.com/product/17153/Microsoft-Windows-7....
а в пыхe всего 110 http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74
Профит и секурность, да :)
Правда, даже в ядре пингвина, которое по слухам немножечко больше, настчитывают в два раза МЕНЬШЕ RCE дырок.И да, я в курсе что источник не очень точный, однако при таких циферках плюс минус десяток дыр уже особой роли не играют :)
приятно видеть адекватов среди анонимов.
PHP так спроектирован, он старается уметь все что нужно и не нужно. И вот такой кодовой базой сложно управлять
Вы нас обманываете. Мы знаем историю PHP, поэтому знаем из чего он "вырос" и то что он никак не был спроектирован. А если принять во внимание что закрывают по десятки уязвимостей и столько же ошибок, то поднимается вопрос кто пишет такой низкосортный код.
К слову об "экосистеме" PHP и его авторах из http://www.opennet.me/opennews/art.shtml?num=42237 :> некорректное устранение уязвимости CVE-2006-7243
GCC 4.9.1
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED...Тоже ничего.
По делу:#70012 Exception lost with nested finally block
Хитрая хрень. Неправильный проброс исключения через вложенные finally. Даже с трудом представляю реальный кейс для такой конструкции.#69793 Remotely triggerable stack exhaustion via recursive method calls
Вот нифига не "remotely". Десериализовать untrusted-данные - это стрельба себе по ногам, пора бы уже запомнить.#69892 Different arrays compare indentical due to integer key truncation
LOL.> Уязвимость также выявлена в коде работы с директориями. -
#70002 (TS issues with temporary dir handling)
Package: Apache2 related, OS: Windows 2008 R2 - pfff, ваще пофиг.Пара незначительных исправлений в CLI. Целая пачка в GD - вот это неприятно, там и утечка памяти, и сегфолт, и переполнение стека.
Есть OpenSSL-related баги, но не понял, насколько они значительные.Баг в SOAP снова связан с десериализацией. Кто-нибудь, расскажите - зачем сериализовать объекты SoapClient?
SPL - тоже самое, unserialize.