full-disclosure - [FD] Oracle DB: various issues related to malicious database gateways

Open Source and information security mailing list archives

Message-ID: <CA+i6_hW0DPCQhjVBfBwbMejakpYpH07YMPVKgXTPeqMbX+QusA@mail.gmail.com>
Date: Sun, 31 Jan 2021 05:40:48 -0500
From: Harrison Neal <hneal@...tdidibreak.com>
To: fulldisclosure@...lists.org
Subject: [FD] Oracle DB: various issues related to malicious database
	gateways

The Oracle CPU dated 2020 Jan 14 included patches for various issues
related to database links and gateways ("Oracle Heterogeneous Services").
Two vulnerabilities in particular might lead to privilege escalation,
denial of service, or code execution attacks against Oracle databases.

Attackers might look like either:

1 ) A malicious or compromised database user with at least the CREATE
[PUBLIC] DATABASE LINK privilege; the CREATE [ANY] PROCEDURE privilege is
helpful

2 ) A malicious presence on the network with the capability to perform
man-in-the-middle attacks between an Oracle database and a linked database
gateway

Easier vulnerability - CVE-2020-2510 (SQL injection):

1 ) Choose a function to be run by a privileged database user on the
vulnerable instance, or existing privileges permitting, create a malicious
AUTHID CURRENT_USER function for this purpose

2 ) When a database gateway is queried by the vulnerable instance, ensure
that the version number returned to the vulnerable instance includes a SQL
injection attack referencing the chosen function

Harder vulnerability - CVE-2020-2517 (heap buffer overflow):

1 ) On a vulnerable instance, spray the heap with Java int[1] arrays as
much as possible (there are typically configurable memory limits on Java
heap memory in Oracle databases), and make an educated guess as to memory
addresses that these arrays may occupy

2 ) In a separate session, query a malicious database gateway, which you
should ensure will return an overly long error message that overflows a
heap buffer and overwrites address pointers with your educated guess from
the prior step

3 ) If an array's length is successfully corrupted such that its bounds
would extend into subsequent array(s), and that corrupted array is still
usable (consider encapsulating array accesses in a try-catch), modify a
subsequent array to have a length of 0x40000000

4 ) Use the modified subsequent array as a write-what-where primitive

-HN

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives