Хакеры используют новые приемы для взлома баз данных Oracle

Хм...
Дата: 07.03.2007 13:47:12
AI
Дата: 07.03.2007 13:50:25
Ничего не написано о том, что Д. Литчфилд предлагает взамен привилегий.
MacDuck
Дата: 07.03.2007 14:19:51
AI
Ничего не написано о том, что Д. Литчфилд предлагает взамен привилегий.


+
Эксперт считает, что по этой причине сейчас многие клиенты Oracle не торопятся устанавливать необходимые патчи.

И вовсе не по этой. Эксперты хреновы.
RA\/EN
Дата: 07.03.2007 14:28:29
До "экспертов" дошло через год про минимальные привилегии
softwarer
Дата: 07.03.2007 14:56:50
AI
Ничего не написано о том, что Д. Литчфилд предлагает взамен привилегий.

По сравнению с оригиналом изложение.... очень переврано. Я бы не стал ориентироваться на русский текст для каких-либо выводов.

Суть оригинальной статьи в следующем: достаточно выполнения следующих условий:

- есть пользователь А, функция которого уязвима к sql injection
- есть пользователь B, имеющий право на выполнение этой функции
- пользователь B имеет право на выполнение dbms_sql

для того, чтобы пользователь B мог воспользоваться любыми привилегиями пользователя А.

Из этого делается следующий вывод: учитывая, что dbms_sql по умолчанию грантуется public-у, любой уязвимости в подпрограммах "системных" пользователей достаточно для того, чтобы пользователь с CREATE SESSION ONLY получил полный контроль над системой.

Лично я бы прежде всего подумал над тем, а нафига каждому первому пользователю dbms_sql.
Timm
Дата: 07.03.2007 15:19:55
RA\/EN
Дата: 07.03.2007 16:13:27
Ааа... Понятно, что имелось ввиду.
Короче, если посмотреть в конец документа, то там увидим:
EXCEPTION WHEN OTHERS THEN
IF DBMS_SQL.IS_OPEN(CURSOR_NAME) THEN
DBMS_SQL.CLOSE_CURSOR(CURSOR_NAME);
END IF;
..
..
END;
Если разработчик не реализует такую конструкцию на уровне спинномозговых рефлексов, то о какой-либо безопасности его кода говорить не приходится - само существование такого разработчика уже предствляет бОльшую угрозу, чем возможные последствия атаки
orawish
Дата: 07.03.2007 16:15:32
softwarer
AI
Ничего не написано о том, что Д. Литчфилд предлагает взамен привилегий.

По сравнению с оригиналом изложение.... очень переврано. Я бы не стал ориентироваться на русский текст для каких-либо выводов.

Суть оригинальной статьи в следующем: достаточно выполнения следующих условий:

- есть пользователь А, функция которого уязвима к sql injection
- есть пользователь B, имеющий право на выполнение этой функции
- пользователь B имеет право на выполнение dbms_sql

для того, чтобы пользователь B мог воспользоваться любыми привилегиями пользователя А.

Из этого делается следующий вывод: учитывая, что dbms_sql по умолчанию грантуется public-у, любой уязвимости в подпрограммах "системных" пользователей достаточно для того, чтобы пользователь с CREATE SESSION ONLY получил полный контроль над системой.

Лично я бы прежде всего подумал над тем, а нафига каждому первому пользователю dbms_sql.

А я бы - ограничился логированием всего, что (потенциально) может содержать инъекцию.
softwarer
Дата: 07.03.2007 17:04:20
orawish
А я бы - ограничился логированием всего, что (потенциально) может содержать инъекцию.

Хм. Имеется в виду что-то типа warning-а при компиляции? Имхо задача проанализировать код таким образом очень нетривиальна.

В любом случае, говоря "я бы", я в первую очередь имел в виду то, что можно сделать прямо сейчас, и Oracle у себя, и каждый DBA у себя.
orawish
Дата: 07.03.2007 17:20:42
softwarer
orawish
А я бы - ограничился логированием всего, что (потенциально) может содержать инъекцию.

Хм. Имеется в виду что-то типа warning-а при компиляции? Имхо задача проанализировать код таким образом очень нетривиальна.

В любом случае, говоря "я бы", я в первую очередь имел в виду то, что можно сделать прямо сейчас, и Oracle у себя, и каждый DBA у себя.
Нет, не совсем.
Я имел ввиду - что может сделать для защиты (пассивной, конечно) само клиентское
приложение (т.е. само средство атаки). Ведь оно знает характер (а значит и степень потенциальной опасности) воздействия пользователя на 'статическую, часть' запроса.