информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Сетевые кракеры и правда о деле ЛевинаПортрет посетителяСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Google закрывает безлимитные Photos 
 Имя компании как средство XSS-атаки 
 Утекший код XP и Windows Server... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / RSN / архив / 2012 / январь
2012
главная
январь
февраль
март
апрель
май
июнь
июль
август
сентябрь
октябрь
ноябрь
декабрь





Фундаментальная проблема в 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) [5089]
назад «  » вперед

аналогичные материалы
Oracle выпустила срочный патч для Identity Manager // 12.11.17 14:56
Очередной ежеквартально-рекордный патч от Oracle // 25.04.17 18:08
Oracle убивает браузерную Java // 28.01.16 13:21
Ежеквартальный рекордный патч от Oracle // 20.01.16 17:12
Ежеквартальный патч от Oracle // 21.10.15 14:47
Скандальная неделя // 14.08.15 22:11
Ежеквартальный патч от Oracle // 14.04.15 23:37
 
последние новости
Google закрывает безлимитные Photos // 11.11.20 22:12
Имя компании как средство XSS-атаки // 30.10.20 17:01
Утекший код XP и Windows Server удалось собрать // 01.10.20 01:40
Дела виртуальные // 30.09.20 22:36
Простое пробивание рабочего/провайдерского NAT с помощью Tailscale // 20.08.20 03:02
400 уязвимостей в процессорах Snapdragon // 08.08.20 08:08
Яндекс неуклюже оправдался за установку Теледиска // 29.07.20 17:09

Комментарии:

чего за связанные базы такие? RAC? там вроде пока 16 нод... 19.01.12 21:32  
Автор: vasya Статус: Незарегистрированный пользователь
<"чистая" ссылка>
>На одиночной базе даже это не вызвало бы проблем, но в сочетании с множественными связанными базами (а у крупных
>организаций число подобных серверов может идти на сотни) теоретически недостижимый лимит вдруг оказывается не столь
>недостижимым.
чего за связанные базы такие? RAC? там вроде пока 16 нод максимум.
Database Links, не знаю, какая тут традиция перевода 19.01.12 21:41  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>


http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm
<добавить комментарий>


анонимность клоуны конференции спам уязвимости .net acrobat activex adobe android apple beta bgp bitcoin blaster borland botnet chrome cisco crypto ctf ddos dmca dnet dns dos dropbox eclipse ecurrency eeye elcomsoft excel facebook firefox flash freebsd gnome google gpl hp https ibm icq ie intel ios iphone java javascript l0pht leak linux livejournal mac mcafee meltdown microsoft mozilla mysql netware nginx novell ny open source opera oracle os/2 outlook password patch php powerpoint pwn2own quicktime rc5 redhat retro rip router rsa safari sco secunia server service pack shopping skype smb solaris sony spyware sql injection ssl stuff sun symantec torrents unix virus vista vmware vpn wikipedia windows word xp xss yahoo yandex youtube



Rambler's Top100
Рейтинг@Mail.ru



  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach