| |
| 2.2, FilimoniC (ok), 11:07, 22/03/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Судя по сообщению, не было ничего внедрено "опасного". Только в credits'ы дописался.
Если бы атака прошла успешно, ее бы не стали афишировать, т.к. это бы дало почти абсолютную власть.
| | |
| |
| 3.29, szh (ok), 17:58, 22/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Только в credits'ы дописался
значит был получен доступ на запись в исходники, и туда могли вставить что угодно. Атака прошла успешно, независимо от того внедряли ли туда что-то еще.
| | |
| |
| 4.37, sllxxe (?), 14:59, 24/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
а если найдут всё-таки бекдор (который по сути был подсадной уткой), а реально нацеленный и очень замаскированный не найдут, то это заявление специально лишь спровоцирует на обновление с уже внедрённым не найденным кодом.
| | |
|
|
|
| 1.3, Аноним (-), 11:09, 22/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Последние известные уязвимости в DokuWiki устранялись год-полтора назад (а не пять лет назад, как сказано в заметке). Там были проблемы с проверкой ACL и ещё кое-что по мелочи. Лень искать ссылки в багтрекере, кому надо, найдут на http://bugs.dokuwiki.org/
| | |
| |
| 2.6, Аноним (-), 11:26, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Последние известные уязвимости в DokuWiki устранялись год-полтора назад (а не пять лет назад, как сказано в заметке). Там были проблемы с проверкой ACL и ещё кое-что по мелочи.
В том то и дело, что "по мелочи", дыр способных привести к выполнению php-скрипта не было уже очень давно.
| | |
|
| 1.4, Aman (ok), 11:17, 22/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 Ну как бы много желтого в новости (спецслужбы чего стоят), но суть правильная. И ничего удивительного. Сколько не говори - пых сплошная дыра и эксплойт, никто особенно не верит. Вообще даже без закладок, на "блекхэтах" месяцами висят дыры, эксплоиты и чаще всего "отказы в обслуживании", если в php закрывают их за 3 месяца, то уже хорошо.
А если обращаться с чем-то в Zend, так это вообще непередаваемо. Тотальный пофигизм и непроходимая тупость. Почти на любой мессадж - вам напишет какой-нибудь индус, предлагающий назвать свободное время, когда он может рассказать о прекрасных продуктах Zend'а.
| | |
| |
| 2.12, terr0rist (ok), 12:37, 22/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Тотальный пофигизм и непроходимая тупость
логично. Какой пых, такая и контора :)
| | |
|
| 1.5, turbofail (?), 11:26, 22/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
так им и надо, может прозреют
скрипт-кидди и дизайнеры/верстальщики/сеошники в контрибуторах - в этом весь PHP
| | |
| |
| 2.15, Aman (ok), 13:09, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Им по барабану, они от этого далеки. Прозревают админы и хостеры, которые думают, что с этим всем делать.
| | |
| 2.19, metallic (ok), 15:28, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Чем плох пхп и какая есть альтернатива, которая лучше и чем?
Иначе школотроль.
| | |
| |
| 3.21, Aman (ok), 15:45, 22/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Чем плох пхп
Ээээ... Прочтите новость.
>и какая есть альтернатива
Ревизия всего исходного кода. Переход на git (срочно). Нормальное отношение к безопасности проекта. Нормальное отношение к безопасности кода - своевременные фиксы, неигнарироание присылаемых патчей с секьюрити фиксами. Вообще неигнарирование сообщества, которое к тому же предлагало бюджеты (и было проигнарировано).
Вот такие дела.
| | |
| |
| 4.23, BlessMaster (?), 16:09, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Переход на git (срочно).
Ээээ... и что это поменяет? Или все взломщики мира страшно боятся этого слова?
В новости ни слова про недостатки самого ПХП. Есть лишь пара заявлений с жёлтоватым душком.
| | |
| |
| 5.27, Aman (ok), 17:01, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Контроль целостности файлов проекта. Как минимум. Как максимум - получение прав коммитера, не ставит автоматически центральную базу кода под угрозу. Секьюрити однако.
| | |
| |
| 6.38, BlessMaster (?), 17:13, 28/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Контроль целостности файлов проекта. Как минимум. Как максимум - получение прав коммитера,
> не ставит автоматически центральную базу кода под угрозу. Секьюрити однако.
svn и другие не позволяют контролировать целостность файлов?
По поводу центральной базы - но так её ж нет у гита - сравнение не совсем корректно. Если слияние производит человек, не знающий что он вливает в свою ветку - угроза ровным счётом та же. Но спорить, что гит удобней - не буду. С одной стороны уже прочитал про его возможности, с другой - ещё ни разу не использовал.
| | |
|
|
|
|
|
| 1.9, Aman (ok), 12:02, 22/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>интерпретатор используется в таких крупных проектах, как Facebook
Кстати, Facebook вроже ж использует свой собственный интерпретатор, который они сравнительно недавно открыли?
| | |
| |
| |
| 3.11, Aman (ok), 12:31, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Я с ним не работал, но по wikipedia понял, что все-таки не компилятор, а трансформатор. Переводит php код в оптимизированный c++, потом уже компилируется g++. То-есть интерпретатор php не используется.
| | |
|
|
| 1.17, non anon (?), 13:33, 22/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>ядро было собрано с усиливающими безопасность патчами GRSecurity.
Они усиливают не безопасность, а глючность и тормоза. Поэтому в мейнстрим их и не берут.
| | |
| |
| 2.18, deadless (ok), 15:18, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 вот тут некий paxuser с пеной у рта доказывал что только применяя grsecurity и hardened патчи можно защитить ядро, и вообще дальше взлома php скрипта хацкеры никуда не должны были пробраться.
Таким образом все эти grsecurity просто видимость безопасности? И тогда чем это лучше чем техники применяемые в OpenBSD?
Ну собсно эта новость и является ответом paxuser-у о реальной безопасности hardened ядер.
| | |
| |
| 3.30, non anon (?), 18:22, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>вот тут некий paxuser с пеной у рта доказывал что только применяя grsecurity и hardened патчи можно защитить ядро, и вообще дальше взлома php скрипта хацкеры никуда не должны были пробраться.
Реально защитить систему могут только своевременные обновления в сочетании с продуманной политикой контроля доступа (лучше всего мандатный контроль + контейнеры + правильные права/acl на файловой системе). А совсем для параноиков есть железобетонный метод - xen/kvm.
>И тогда чем это лучше чем техники применяемые в OpenBSD?
В опенке применяется, по сути, всего одна техника - предельное урезание функциональности. Меньше кода - меньше потенциальных дыр. В большинстве случаев такая практика не дает оптимального результата, т.к. людям не нужен мега-защищенный, но ничего не умеющий сервер.
Но путь, выбранный grsecurity - "больше глюков, больше паник, и враг не пройдет" - все равно выглядит гораздо менее привлекательно.
| | |
|
| 2.25, pavlinux (ok), 16:16, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 >>ядро было собрано с усиливающими безопасность патчами GRSecurity.
> Они усиливают не безопасность, а глючность и тормоза. Поэтому в мейнстрим их и не берут.
Бронежилет и каска не увеличивают безопасность если лежат в шкафу.
| | |
| |
| 3.31, non anon (?), 18:25, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Бронежилет и каска не увеличивают безопасность если лежат в шкафу.
grsecurity - это скорее не каска и жилет, а поллитра: выпил - и не боишься.
| | |
| |
| 4.35, Аноним (-), 12:28, 23/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Бронежилет и каска не увеличивают безопасность если лежат в шкафу.
> grsecurity - это скорее не каска и жилет, а поллитра: выпил -
> и не боишься.
руки надо иметь из правильного места. И да, RBAC еще никто не отменял. Запарка с правильной настройкой с лихвой компенсируется очень нехилым повышением безопасности. Собственно то же можно сказать и про SELinux, но он, в отличие от RBAC - ад и погибель, леденящий душу писец(я пробовал писать модули под него, плюнул и бросил)
| | |
|
|
|
| 1.22, BlessMaster (?), 16:05, 22/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Новость ровным счётом ни о чём. Кто-то где-то заявил, что он прописался в контрибуторы. Нам сообщают, что это изменение сразу откатили (то есть в стабильный релиз оно не попало).
Сервера взломаны якобы через уязвимость в DocuWiki (автор статьи вопросом не владеет, сплошные предположения). Как подняли права - опять же не в курсе. Спрашивается, при чём тут вообще PHP?
Третий вопрос: при чём здесь mod_php?
| | |
| |
| 2.26, uldus (ok), 16:23, 22/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Новость ровным счётом ни о чём. Кто-то где-то заявил, что он прописался
> в контрибуторы. Нам сообщают, что это изменение сразу откатили (то есть
> в стабильный релиз оно не попало).
Типичное отношение к безопасности разработчика на PHP. Фактически показано, что с кодом PHP и серверами проекта имели возможность сделать все что душе угодно. Но вам все одно - раз не встроили реальный троян и не стерли данные на серверах, бояться нечего.
> Сервера взломаны якобы через уязвимость в DocuWiki (автор статьи вопросом не владеет,
> сплошные предположения). Как подняли права - опять же не в курсе.
Проблема в том, что разработчики PHP всеми силами скрывают подобные факты и не отвечают на связанные со взломом вопросы. Поэтому остается видимо делать предположения.
> Спрашивается, при чём тут вообще PHP?
Есть очень важный факт - в основной рабочий репозиторий с кодом PHP добивили левый код. А если бы вместо "привет от Васи Пупкина" туда добавили хорошо продуманный бэкдор, который, уверяю вас, никто в рассылке PHP-dev даже бы не заметил ? Казалось бы, при чем тут PHP. При том, что разработчики PHP плюют и продолжают плевать как на безопасность кода, так и на безопасность инфраструктуры.
> Третий вопрос: при чём здесь mod_php?
mod_php от php неотделим, использование cli/fastcgi сборок скорее исключение из правил.
| | |
| 2.28, Aman (ok), 17:11, 22/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Новость ровным счётом ни о чём. Кто-то где-то заявил, что он прописался
> в контрибуторы. Нам сообщают, что это изменение сразу откатили (то есть
> в стабильный релиз оно не попало).
> Сервера взломаны якобы через уязвимость в DocuWiki (автор статьи вопросом не владеет,
> сплошные предположения). Как подняли права - опять же не в курсе.
> Спрашивается, при чём тут вообще PHP?
> Третий вопрос: при чём здесь mod_php?
Новость написана неважно, важно, что был "закоммичен" левый код, под логином одного из европеоидных коммитеров, кем то из Китая. Очень мило. Все остальное лирика, показывающее плохое и несовременное состояние инфраструктуры проекта.
Вообще чего ждать от php, если они бросают на произвол 5.2, при куче проектов не поддерживающих 5.3. Я бы понял, если бы они тянули 4 каких-то параллельных веток, а так.. Что хочу, то ворочу.
| | |
| |
| 3.32, ы (?), 00:49, 23/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
1) 5.3 вышел уже полтора года назад
2) в нем нет принципиальных несовместимостей с 5.2. Все, что ломает bc, описано в мане, и исправление даже проекта в сотни тысяч LOC займет пару дней (сам делал). При этом для кода, написанного не левой жопой (что редкость для похапе-прогромиздов, да) исправлений ваще не потребуется.
так что пострадают только те, кому пох*й.
| | |
| |
| 4.34, Aman (ok), 01:51, 23/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Это все в вакууме. Все что использую лично я - давно запилено на 5.3. Но у меня виртуальный хостинг и у кучи людей сайты не работающие с 5.3 и переделывать никто не собирается. Еще есть старые зазенденные скрипты (про дезенд, перепилку под 5.3 - тоже не тот случай). В итоге проблема для любого хостера. А еще некоторые веселые хостеры, могут ужить 5.2 и 5.3 на одном хосте, так что потом не жалуйтесь.
| | |
|
|
|
| 1.33, Vitold S (?), 01:06, 23/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Сам факт безответственного поведения PHP разработчиков допустивших использование какого-то кривого Wiki.
Собственно в PHP есть же различные SAFE и noexec ключи безопасности? Или я ошибаюсь?
| | |
|
