BugTraq.Ru
Русский BugTraq
https://bugtraq.ru/rsn/?page=129

Russian Security Newsline
Хотите установить RSN на своем сайте?

Фундаментальная проблема в Oracle
dl // 18.01.12 17:46
В продолжение темы оракловых неприятностей InfoWorld публикует материал о проблеме, частично устраненной в последнем обновлении, но принципиально не исчезнувшей.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2012/01/05.html]

Источником проблемы является счетчик System Change Number (SCN), увеличивающийся при каждой операции над базой, и являющийся критичным для ее работы. Такие встроенные часы, идущие только вперед, причем для увеличения одной базой SCN другой нужны лишь самые базовые привилегии.

Проектировщики заложили вполне приличный запас в SCN, сделав его 48-битным. Верхней границы в 281,474,976,710,656 должно хватить надолго, но помимо этого, на SCN было наложено дополнительное ограничение - в каждый момент времени его значение не может превышать количество секунд, прошедших с 1.01.1980, умноженное на 16,384. Предполагалось, что баз, непрерывно живущих с 80 года, и проводящих по 16 тысяч транзакций в секунду, в природе не существует.

На практике же обнаружилось несколько ситуаций, в которых природу удавалось обойти:

1. Баг в бэкапе. Базы Oracle поддерживают так называемый hot backup, позволяющй с помощью команды ALTER DATABASE BEGIN BACKUP начать бэкап работающей базы. Ошибка в кодировании привела к тому, что после выполнения этой команды SCN начинал расти со страшной скоростью, не останавливаясь даже после команды END BACKUP. На одиночной базе даже это не вызвало бы проблем, но в сочетании с множественными связанными базами (а у крупных организаций число подобных серверов может идти на сотни) теоретически недостижимый лимит вдруг оказывается не столь недостижимым. Недавно исправленная уязвимость носит номер 12371955, "High SCN growth rate from ALTER DATABASE BEGIN BACKUP in 11g."

2. Саботаж. Описанная ситуация открывает новый вектор атак - пользователь, имеющий доступ к второстепенной базе, может накрутить SCN всех баз, входящих в систему.

До недавнего времени вся реакция от Oracle на описанную проблему сводилась к увеличению ограничения на SCN вдвое - коэффициент умножения секунд вырос до 32,768. Что любопытно, это увеличение само по себе могло и ухудшить ситуацию, если в системе встретятся два сервера, только один из которых пропатчен - у него SCN может превысить критичный уровень для второго, и они просто не смогут взаимодействовать.

Наконец, последние исправления включили некую защиту, названную по словам представителей Oracle прививкой (inoculation). Пока не вполне ясна ее эффективность, как и механизм ее работы, но стоит учесть, что исправление вышло только для последних версий. Все версии, более старые, чем 11.2.0.2.0 и 10.1.0.5, по-прежнему уязвимы.

Источник: InfoWorld
теги: oracle  |  обсудить  |  все отзывы (2)


Квартальные патчи Oracle: махнула ли компания рукой на безопасность своей базы?
dl // 18.01.12 16:55
Последнее квартальное обновление Oracle принесло 78 исправленных уязвимостей, лишь две из которых относятся к продуктам Oracle Database.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2012/01/04.html]
Это бьет предыдущий октябрьский антирекорд из 5 устраненных уязвимостей. В то же время в MySQL было исправлено 27 уязвимостей и 17 - в продуктах, унаследованных от Sun.

Конечно, некорректно говорить об ухудшении ситуации, ориентируясь на уменьшение числа исправленных ошибок - в конце концов, сама Oracle утверждает, что код Oracle Database Server достиг такой зрелости, что до обнаружения принципиально новых векторов атаки там практически нечего будет исправлять.

Однако представитель Application Security's TeamShatter с говорящим именем Alex Rothacker утверждает, что количество ошибок, о которых они сообщают Oracle, осталось на прежнем уровне, только вот исправлять их Oracle не торопится - возможно, после поглощения Sun на свой флагманский продукт уже не хватает времени.

Источник: InfoWorld, Oracle
теги: oracle, patch, mysql  |  обсудить  |  все отзывы (0)


Потенциальная массовая кража паролей в LiveJournal
dl // 15.01.12 13:46
Поначалу мне показалось, что симптомы похожи на внедрение постороннего кода в стили, используемые рядом аккаунтов (у себя, например, я этого не наблюдаю, но на многих лентах вылезает при просмотре из-под любого аккаунта).
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2012/01/03.html]
Скорее всего, все было еще проще - в чей-то пост был воткнут div во весь экран, и все, у кого он показался в ленте друзей, дружно перезашли и размножили его в вирусном стиле по своим друзьям, а те понесли знамя дальше. Так что хочется передать отдельный горячий привет ljшной фильтрации.

В результате при попытке просмотра ленты друзей пользователь получает страницу с характерной синей ljшной шапкой с формой для логина и продублированной ей же на девственно чистой белой странице (в отличие от обычной страницы входа, забитой всяким хламом). В формах в качестве action указан совершенно посторонний адрес. При просмотре кода страницы видно, что оригинальная лента друзей никуда не делась, а просто перекрыта слоем с этой явно фишинговой формой.

Указанный в форме адрес http://ohtoenequ1.getenjoyment.net/index.php к настоящему моменту уже как бы благополучно прилег, видимо, не выдержав толпы запросов, но до этого могло быть собрано очень немало паролей. С другой стороны, на заборе-то написать можно что угодно, и фишинговый скрипт запросто может выводить подобное сообщение в целях маскировки под ставшие традиционными ljшные падения. Так что нет оснований считать, что сбор паролей не продолжается.

Потенциальным жертвам (к которым относятся все, у кого происходили непонятые выбрасывания на форму с логином), разумеется, стоит немедленно сменить пароль, обращая внимание на содержимое адресной строки.

В качестве временной меры, позволяющей изголодавшимся юзерам добраться до содержимого своей ленты, можно просто добавить ?nohtml=1 к ее url.

Источник: msado lj
теги: livejournal  |  обсудить  |  все отзывы (0)


Windows-админам пора отвыкать от GUI
dl // 13.01.12 20:00
Не прошло и двадцати лет, как Microsoft решилась выпилить обязательный GUI из своей серверной системы: в готовящемся Windows Server 8 полная оболочка Server Graphical Shell будет отделена от Server Core, и ее включение предполагается опциональным.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2012/01/02.html]
Кроме того, ожидается промежуточная оболочка, Minimal Server Interface, в которой не будет работы с Internet Explorer, десктопом, Windows Explorer, Metro-style приложениями (страшная потеря).

Администраторам и разработчикам рекомендовано ориентироваться на PowerShell и клиентские приложения.

Лет десять назад такое было бы просто прорывом.

Источник: Microsoft Server and Cloud Platform Blog
теги: microsoft  |  обсудить  |  все отзывы (19)


Январские обновления от MS
dl // 10.01.12 22:45
Не успели (ну ладно, можно считать, успели) закончиться праздники, как подоспели семь новых бюллетеней от MS, один критический и шесть важных.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2012/01/01.html]
Критическое обновление закрывает уязвимость в Windows Media, приводящую к удаленному исполнению кода при открытии специально подготовленного медиафайла. Важные: обход SafeSEH, удаленное исполнение кода в Windows Object Packager и офисных файлах, содержащих внедренное приложение ClickOnce, эскалация привилегий в Client/Server Run-time Subsystem, утечка информации в SSL/TLS и библиотеке AntiXSS.

Источник: Microsoft Security Bulletin Summary
теги: microsoft, patch  |  обсудить  |  все отзывы (0)




««    «   121  |  122  |  123  |  124  |  125  |  126  |  127  |  128  |  129  |  130 >>  »    »»


Предложить свою новость



  Copyright © 2001-2025 Dmitry Leonov Design: Vadim Derkach