The OpenNET Project / Index page

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

Уязвимость в Bugzilla, позволяющая получить доступ к закрытым обсуждениям Mozilla

18.09.2015 09:24

В Bugzilla, платформе для ведения базы данных ошибок, контроля за их исправлением и общего координирования процесса разработки, выявлена критическая уязвимость (CVE-2015-4499), дающая возможность завести привилегированный аккаунт, имеющий доступ к закрытой информации, например, к непубличным обсуждениям неисправленных уязвимостей. Эффект от указанной уязвимости напоминает раскрытую несколько недель назад атаку на Bugzilla, в результате которой злоумышленники получили доступ к информации о неисправленных уязвимостях в Firefox в результате перехвата пароля одного из пользователей.

Уязвимость уже устранена в выпусках Bugzilla 5.0.1, 4.4.10 и 4.2.15. Суть проблемы в том, что при сохранении в MySQL логин/email молча обрезается до 255 символов, так как столбец в БД имеет тип tinytext. Таким образом, атакующий может завести аккаунт с адресом "[email protected]", хвост ".site.com" которого будет за пределами 255 байт. Такой аккаунт пройдёт процедуру подтверждения (email с кодом подтверждения будет отправлен на необрезанный адрес), но будет сохранён в БД как "[email protected]", что позволит ему просматривать закрытые обсуждения. При заведении аккаунта Bugzilla автоматически добавит подложный аккаунт в группы, соответствующие правилам, заданным через регулярные выражения, например, в bugzilla.mozilla.org добавление в закрытые группы производится при наличии в email домена "mozilla.org".

  1. Главная ссылка к новости (http://blog.perimeterx.com/bug...)
  2. OpenNews: Взлом Bugzilla привёл к утечке информации о критических уязвимостях в Firefox
  3. OpenNews: Релиз свободной системы отслеживания ошибок Bugzilla 5.0
  4. OpenNews: В Bugzilla устранена опасная уязвимость, открывшая новый вид атак на web-приложения
  5. OpenNews: Проект Mozilla объявил о возможной утечке 97 тысяч аккаунтов тестового сервера Bugzilla
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/42983-bugzilla
Ключевые слова: bugzilla
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:15, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +16 +/
    Отличный баг!
     
     
  • 2.20, Аноним (-), 19:29, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну что, заспорим что ЭТИМ программистам никакой Rust не поможет?
     
     
  • 3.23, Обнимашки (?), 20:45, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Этим — нет.
    Но они ж не одни на свете живут.
     

  • 1.2, Аноним (-), 10:16, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    аплодирую програмистам
     
  • 1.3, Аноним (-), 10:35, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Помоему обрезать любые данные для того, чтобы они искуственно вместились в БД это как-то по колхозному. Если не влезает надо всегда генерить эксепшн и чтоб юзер знал, что данные не влезают и их надо бы сократить, а не молча проглатывать а бы что.
     
     
  • 2.5, Аноним (-), 11:11, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    MySQL
     
     
  • 3.9, Аноним (-), 11:26, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ничего плохого в этом не вижу

    А вот в том что надо знать хорошо базу которую используешь никогда не сомневался
    # cat /etc/my.cnf.d/my.cnf
    [mysqld]
    sql-mode="NO_BACKSLASH_ESCAPES,STRICT_ALL_TABLES,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
    innodb_strict_mode=on
    innodb_file_format=Barracuda
    innodb_large_prefix=on

    Решит все проблемы

     
     
  • 4.10, Нанобот (ok), 11:54, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >Решит все проблемы

    LOL

    Да, решит, тут ты, конечно прав. А ещё создаст новые проблемы, и их будет больше, чем было до "решения всех проблем". А если сделать такое на сервере с большим количеством разных баз, то решатор проблем рискует получить физические повреждения от пользователей.

     
  • 4.21, Аноним (-), 19:35, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Решит все проблемы

    Странно, проблему беженцев что-то плохо решает. FAIL.

     
  • 4.24, Обнимашки (?), 20:47, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Решит все проблемы

    Все проблемы решит проверять ввод.


     
     
  • 5.27, Аноним (-), 01:14, 19/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вы коммит то смотрели?

    Там проверка была вот такая:
    my $ret = ($addr =~ /$match/ && $email !~ /\P{ASCII}/ && $email =~ /^$addr_spec$/);

    стала вот такая:
    $addr =~ /$match/
    +        && $email !~ /\P{ASCII}/
    +        && $email =~ /^$addr_spec$/
    +        && length($email) <= 127)

    Вы хоть обпроверяйтесь от забывчивости, невнимательности и просто от того что схема БД может со временем менятся это не спасет. Правильный ответ уметь тюнить базу, чтоб она не обрезала данные если не может по какой либо причине сохранить, лучше пусть SQL error кажет.

     

  • 1.6, Аноним (-), 11:14, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >добавит аккаунт в группы, соответствующие правилам, заданным через регулярные выражения
    >регулярные выражения

    Повеселили, спасибо.

     
  • 1.7, Аноним (-), 11:16, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Забавно, а подтверждающий email отсылали по необрезанному?
     
     
  • 2.22, Аноним (-), 19:35, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да, в новости об этом написано.
     

  • 1.11, Аноним (-), 12:13, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    На Perl пишут только в Mail.ru и дилетанты!
     
     
  • 2.12, Анонимоус (?), 13:11, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, в приложениях на PHP такие баги не возможны
     
     
  • 3.16, йцу (?), 14:44, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да тут в общем-то неважно - Perl, PHP или брейнфак. Просто MySQL по-дефолту уж очень "всеяден" и вместо того чтобы ругнуться на попытку вставить слишком длинную строку тупо её обрезает.
     
  • 2.13, SysA (?), 13:41, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > На Perl пишут только в Mail.ru и дилетанты!

    Ага, то-то в трейдинг- и BI-компаниях дилетантов развелось!.. :)

     
  • 2.14, Аноним (-), 13:48, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это mysql молча текст обрезает
     
  • 2.18, Аналитик (?), 16:21, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Минусы за Perl или mailru?
     

  • 1.15, Ананем кто же еще (?), 14:32, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Mysql какой-то даунский, придумавшему тихенько портить данные вместо генерации ошибки надо оторвать руки. Это уже не первый такого рода баг который я вижу на опеннете, а сколько их еще есть
     
  • 1.17, Аноним (-), 15:11, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Некоторые пишут что тихое обрезание данных нормально. Только вот потерю введенных данных при таком раскладе можно заметить далеко не сразу. MySQL вообще много где неадекватно себя ведет. И самое странное некоторые подомные мелочи лежат в багтрекере десятилетиями.
     
     
  • 2.19, Sw00p aka Jerom (?), 16:37, 18/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    а как же ACID ?
     
  • 2.28, arisu (ok), 05:58, 20/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    а потому что не надо экономить на DBA. даже стадо хипстеров не заменит одного специалиста.
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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