28.04.2015 13:45
FreeLSD 10 3947 Источник
Wordpress опубликовал обновление WordPress 4.2.1.
Это критически важное обновление и всем пользователям популярной CMS Worpress рекомендуется обновиться.
Несколько часов назад команда получила информацию о XSS уязвимости, которая может быть использована злоумышленником, если на сайте включена возможность комментирования записей блога.
Уязвимость была обнаружена Jouko Pynnonen.

Уязвимость связана с тем, что если комментарий превысит стандартные для MySQL TEXT 64КБ, то будет будет усечен при внесении в базу данных.
Атакующий может оставить комментарий размером в 64KB, который попадает базу данных без проверок и может быть доступен читателям блога. Таким образом, если атакующий внедрит в такой комментарий JavaScript код, то он будет исполнен в браузере пользователя. В частности, если комментарий будет просмотрен администратором сайта, то злоумышленник может сменить пароль, создать новый аккаунт, загрузить файлы от имени администратора.

Видео-демонстрация уязвимости:


Рекомендуем всем обновиться.

Комментарии (10)


  1. berezuev
    28.04.2015 17:33
    #8397473

    Рекомендую еще немного сократить статью, и лучше запостить сюда: twitter.com


    1. Werdas
      28.04.2015 17:52
      #8397519
      +2

      Рекомендую


      1. FreeLSD Автор
        28.04.2015 18:01
        #8397533
        -5

        спс


  1. mcavalon
    28.04.2015 19:46
    #8397681

    Сообщество не любит wordpress :)


    1. FreeLSD Автор
      29.04.2015 00:42
      #8398103
      +1

      Выходит что так.


  1. nokimaro
    28.04.2015 22:35
    #8397951
    +1

    Посмотрел diff но так и не понял суть бага, точнее как оно может быть связано с длиной коммента?
    Если пользователь постит коммент, то его обработку (экранирование спец-символов) можно сделать до помещения в БД или после (при выводе).
    Предположим коммент обрабатывается до помещения в БД функцией типа htmlentities() (замена < и > на &lt; &gt;) и коммент не влазит в 64кб при записи в базу.
    Значит туда будет записан кусок текста, но текст должен быть обработан и отфильтрован ещё перед записью в БД и никаких «тегов» там остаться не должно.

    Фикс судя по DIFFу заключается в том что они проверяют длину данных в соответствие с типами полей в БД и если у вас коммент длинее 64Кб а поле MySQL TEXT то он не пройдёт.


    1. avdept
      28.04.2015 22:40
      #8397961

      Костыли на костылях костылями поганяют.


    1. nokimaro
      28.04.2015 23:02
      #8397991

      Разобрался. Дело в списке «разрешённых тегов» типа <a> и доп. атрибутах внутри тега. И фильтрация атрибутов у них не срабатывает корректно из-за «обрезания» данных.


      1. SantyagoSeaman
        28.04.2015 23:26
        #8398019
        +1

        Там вообще нет обрезки тегов. Все аргументы ескейптся с помощью мускульной функции. В базу попадает уже отъескепленный текст любого размера. И уже база делает отлуп превышения размерности.
        Коммит — очередной костыль, к XSS не имеющий никакого отношения.
        А это вообще шедевр

        public function escape_by_ref( &$string ) { 
    if ( ! is_float( $string ) ) 
        $string = $this->_real_escape( $string ); 
}

        Как, собственно, и весь ВП :)


  1. nikitasius
    29.04.2015 00:59
    #8398115

    Другое дело, что комменты часто отключены…