BugTraq.Ru: Фундаментальная проблема в Oracle

Источником проблемы является счетчик 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, по-прежнему уязвимы.