23 октября 2008 в 0:58
Читаем и обновляемся.
Вкратце: исправлена уязвимость SA-2008-067. Для обновления с 6.5 достаточно заменить файлы Drupal новыми, либо применить патч http://drupal.org/files/sa-2008-067/SA-2008-067-6.5.patch. Обновления БД при переходе с 6.5 на 6.6 или с 5.11 на 5.12 не требуется (но апгрейд БД нужен если вы переходите с более ранних версий!).
Комментарии
Опередил однако;)
Базу при обновлении не трогает - и это хороше
Т.е. достаточно просто заменить файлы? или лучше все зделать как и при переходе с 6,4 на 6,5.? И если не сложно что в этот рас обновили? с английским у меня туго.
Заранее спасибо.
Сделать бекап не помешает в любом случае - пригодится.
Заменить файлы и запустить update.php. Я так делаю.
Если будет более подробная информация на русском, то заменим на главной более информативной статьей. У меня просто нет времени сейчас оформлять - переношу сайты с одного сервера на другой...
drupal.ru обновлён до 6.6.
Вот уж кто всегда на чеку!!!
Измененные файлы, больше ничего менять не нужно
update.php походу испольнять нет смысла
напрягают эти частые обновления. сколько, два дня назад был апдейт?
В 6.6 и в 6.5 не работают нормально Archive и DHTML Menu, а в 6.4 пахало
==
Чего то косячат.
Прикол!
Вот что бывает когда упустишь/забудешь/отвлечешься обновить базу после обновления системы:
Обновил базу и все стало на места.
Файлы обновлять нужно почаще, а в обновлении обычно написано - нужно ли запускать update.php !!!
Если вам пофиг безопасность - можно и не обновлять весь год
Первая бага конечно серьезная. Хотя я уверен что почти 90 процентов сидят на нэйм бейсед виртуал хостингах.
вторая еще раз показывает что будет если контроль за данными возлагать на программиста. Это еще учтем, что модули ядра в обязательном порядке проверяет секьюрити тим.
А так да, РЕШЕТО. Печально.
две недели прошло.
ошибки теперь ищут гораздо больше людей и с большим усердием
Речь как раз идет о том что безопасность не пофиг.
Вам никогда не приходилось заключать договора на изготовление портала где есть пункт о ВАШЕЙ финансовой ответственности в случае компромитации проекта?
Вот и выходит что использование друпала сомнительно в таких случаях. Лио использовать ТОЛЬКО ядро и ни одного модуля, вообще ни одного. А все делать своими руками.
Не факт, что в сделанном дыр не будет
Да. Но
Сделать это будет на порядок сложнее.
В случае со сторонним стандартным модулем у атакующего есть под рукой исходный код модуля. Что значительно упрощает поиск слабых мест.
Кроме того, не вполне мне понятен вот какой факт.
В друпале есть определенные рекомендации по формированию например sql запросов. И что удивительно, многие модуля ядра им не следуют, а если бы следовали то большинство sql injection не было бы. Как их секьюрити тим, которая якобы проверяет все, не обращает на это внимание?
Забавно потом читать в
This is because does not properly use the Drupal database API and inserts values from URLs directly into queries under these conditions.