E assim se passaram 3 anos ... CPU - Critical Patch Updates

Olá,

Para quem não se lembra, hoje, em 6 de Abril de 2009, faz exatamente 3 anos que a Oracle lançou uma nota (Note 363848.1) no Oracle Metalink, atualmente conhecido como My Oracle Support, sobre uma vulnerabilidade de segurança que afeta todas as versões do Oracle 9i (9.2.0.1) até o Oracle 10g (10.2.0.3), mas que na verdade afeta todas as versões do seu banco de dados Oracle desde a versão 7.3. Essa vulnerabilidade permite que um usuário com o privilégio de SELECT nas tabelas base de outro usuário execute operações (UPDATE, DELETE e INSERT) à partir de uma VIEW. Há inclusive quem diga que não seja nem mesmo necessário criar uma view de banco de dados para executar estas operações DML's ...

Atualmente esta nota não está mais acessível ao público por razões de segurança. No mais, quero apenas salientar que minha intenção com este artigo não é a de ressuscitar um assunto do passado, mas a de ALERTAR todos os DBA's que ainda insistem em não aplicar as correções críticas (Critical Patche Updates) recomendadas pela Oracle nas versões de seus bancos de dados de produção. Digo isso porque tenho visto muitos bancos de dados Oracle por aí (8i/9i/10g) nas quais jamais foram atualizados ou tiveram quaisquer correções aplicadas em seu software.

Como primeira solução (workaround) para este problema, foi sugerido revogar da role CONNECT os privilégios de sistema CREATE VIEW e CREATE DATABASE LINK, assim como revogar das contas de todos os usuários de banco de dados o privilégio CREATE VIEW porventura concedida de forma desnecessária. Felizmente a correção definitiva para o problema veio através do Oracle Critical Patch Update - October 2006.

Para demonstrar tal vulnerabilidade, irei demonstrar abaixo utilizando o Oracle 10g release 2 (10.2.0.1), como é possível executar tais operações DML's em uma tabela de outro usuário através de uma view, tendo este usuário apenas os privilégios CREATE VIEW e CREATE SESSION. Por questões de ética, bom senso e segurança, não irei disponibilizar o código de criação da view:

C:\>sqlplus system/manager

SQL*Plus: Release 10.2.0.1.0 - Production on Seg Abr 6 08:13:12 2009

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a:
Oracle Database 10g Release 10.2.0.1.0 - Production

-- Criação do usuário USUARIO1
SYSTEM> create user usuario1 identified by usuario1 default tablespace users;

Usuário criado.

-- Criação do usuário USUARIO2
SYSTEM> create user usuario2 identified by usuario2 default tablespace users;

Usuário criado.

-- Concessão padrão para o USUARIO1
SYSTEM> grant connect,resource to usuario1;

Concessão bem-sucedida.

-- Concessão dos privilégios CREATE VIEW e CREATE SESSION para o USUARIO2
SYSTEM> grant create view, create session to usuario2;

Concessão bem-sucedida.

-- Conectando com o USUARIO1
SYSTEM> connect usuario1/usuario1
Conectado.

-- Criação de uma tabela para teste
USUARIO1> create table t1 (id number constraint pk_t1 primary key);

Tabela criada.

-- Criação de 10 registros na tabela T1 para realização da simulação
USUARIO1> insert into t1 select level from dual connect by level <= 10;

10 linhas criadas.

USUARIO1> commit;

Validação completa.

USUARIO1> select * from t1;

        ID
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10

10 linhas selecionadas.

-- Concessão de privilégio SELECT na tabela T1 para o USUARIO2
USUARIO1> grant select on t1 to usuario2;

Concessão bem-sucedida.

-- Conectando com o USUARIO2
USUARIO1> connect usuario2/usuario2
Conectado.

USUARIO2> select * from usuario1.t1;

        ID
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10

10 linhas selecionadas.

USUARIO2> delete from usuario1.t1;
delete from usuario1.t1
                     *
ERRO na linha 1:
ORA-01031: privilégios insuficientes

Podemos perceber acima que o usuário USUARIO2 realmente terá apenas o privilégio de SELECT na tabela T1 de propriedade do usuário USUARIO1. Portanto, qualquer comando (DELETE, INSERT, UPDATE) executado contra a tabela T1 falhará ocasionando assim o erro [ORA-01031: privilégios insuficientes]. A questão muda de figura à partir do momento em que o usuário USUARIO2 criar uma view um pouco maliciosa ...

USUARIO2> create view v_t1 as ([censurado]);

View criada.

USUARIO2> select * from v_t1;

        ID
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10

10 linhas selecionadas.

-- Deletando registros da tabela T1 à partir da view V_T1
USUARIO2> delete from v_t1;

10 linhas deletadas.

USUARIO2> commit;

Validação completa.

USUARIO2> select * from usuario1.t1;

não há linhas selecionadas

Podemos ver acima que o usuário USUARIO2 conseguiu deletar todos os registros da tabela T1 à partir da view V_T1, mesmo não tendo privilégios de DELETE na tabela T1 de propriedade do usuário USUARIO1.

USUARIO2> insert into usuario1.t1 values (1);
insert into usuario1.t1 values (1)
                     *
ERRO na linha 1:
ORA-01031: privilégios insuficientes

USUARIO2> insert into v_t1 values (1);

1 linha criada.

USUARIO2> update usuario1.t1 set id=2;
update usuario1.t1 set id=2
                *
ERRO na linha 1:
ORA-01031: privilégios insuficientes

USUARIO2> update v_t1 set id=2;

1 linha atualizada.

USUARIO2> commit;

Validação completa.

USUARIO2> select * from usuario1.t1;

        ID
----------
         2

Acima podemos perceber que o usuário USUARIO2 também conseguiu inserir e atualizar registros na tabela T1 à partir da view V_T1 mesmo não tendo privilégios de UPDATE e INSERT.