0day.today - Biggest Exploit Database in the World.
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earn
GOLD
Administration of this site uses the official contacts. Beware of impostors!
We DO NOT use Telegram or any messengers / social networks!Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Contact us
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Avast - Authenticode Parsing Memory Corruption
Author
Risk
[Security Risk Medium
]0day-ID
Category
Date add
CVE
Platform
Source: https://code.google.com/p/google-security-research/issues/detail?id=668 The attached PE file causes memory corruption in Avast, it looks related to authenticode parsing. (474.c0c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=128be364 ebx=30303030 ecx=12555e70 edx=128bd032 esi=30303030 edi=00000000 eip=740b4454 esp=10cedfa8 ebp=12555e70 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 aswCmnBS_74080000!StreamHashClose+0x7dd4: 740b4454 8b06 mov eax,dword ptr [esi] ds:002b:30303030=???????? 0:080> ub aswCmnBS_74080000!StreamHashClose+0x7dc5: 740b4445 55 push ebp 740b4446 56 push esi 740b4447 57 push edi 740b4448 33ff xor edi,edi 740b444a 8be9 mov ebp,ecx 740b444c 85db test ebx,ebx 740b444e 7447 je aswCmnBS_74080000!StreamHashClose+0x7e17 (740b4497) 740b4450 8b742418 mov esi,dword ptr [esp+18h] 0:080> dd esp+18 L1 10cedfc0 30303030 # It looks like this address was a parameter, lets skip up a frame and see where it comes from 0:080> kvn 3 # ChildEBP RetAddr Args to Child.............. WARNING: Stack unwind information not available. Following frames may be wrong. 00 10cedfb4 740b483e 30303030 30303030 a00be921 aswCmnBS_74080000!StreamHashClose+0x7dd4 01 10cedfe8 740c37e7 12481a88 00cf0400 00000008 aswCmnBS_74080000!StreamHashClose+0x81be 02 10cee028 740aa2f5 12481a90 00001730 00030408 aswCmnBS_74080000!asw::root::CGenericFile::seekreadin+0xf7 0:080> .frame /c 1 01 10cedfe8 740c37e7 aswCmnBS_74080000!StreamHashClose+0x81be eax=128be364 ebx=30303030 ecx=12555e70 edx=128bd032 esi=30303030 edi=00000000 eip=740b483e esp=10cedfbc ebp=73e1dca8 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 aswCmnBS_74080000!StreamHashClose+0x81be: 740b483e 8bf8 mov edi,eax 0:080> ub. aswCmnBS_74080000!StreamHashClose+0x81aa: 740b482a 0000 add byte ptr [eax],al 740b482c 0001 add byte ptr [ecx],al 740b482e 0000 add byte ptr [eax],al 740b4830 00ff add bh,bh 740b4832 7044 jo aswCmnBS_74080000!StreamHashClose+0x81f8 (740b4878) 740b4834 8bce mov ecx,esi 740b4836 ff7040 push dword ptr [eax+40h] 740b4839 e802fcffff call aswCmnBS_74080000!StreamHashClose+0x7dc0 (740b4440) # The parameter comes from eax+40: 0:080> dd eax+40 L1 128be3a4 30303030 # What is that address? 0:080> !address @eax Mapping file section regions... Mapping module regions... Mapping PEB regions... Mapping TEB and stack regions... Mapping heap regions... Mapping page heap regions... Mapping other regions... Mapping stack trace database regions... Mapping activation context regions... Usage: Heap Base Address: 128b8000 End Address: 128ea000 Region Size: 00032000 State: 00001000 MEM_COMMIT Protect: 00000004 PAGE_READWRITE Type: 00020000 MEM_PRIVATE Allocation Base: 12150000 Allocation Protect: 00000004 PAGE_READWRITE More info: heap owning the address: !heap 0x120000 More info: heap segment More info: heap entry containing the address: !heap -x 0x128be364 # It's a heap buffer, is it valid? 0:080> !heap -x 0x128be364 Entry User Heap Segment Size PrevSize Unused Flags ----------------------------------------------------------------------------- 128bd038 128bd040 00120000 122ef5e0 1408 - 3f LFH;busy. # Looks okay to me, where does that buffer come from? 0:080> .frame /c 2 02 10cee028 740aa2f5 aswCmnBS_74080000!asw::root::CGenericFile::seekreadin+0xf7 eax=128be364 ebx=30303030 ecx=12555e70 edx=128bd032 esi=30303030 edi=00000000 eip=740c37e7 esp=10cedff0 ebp=128be364 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 aswCmnBS_74080000!asw::root::CGenericFile::seekreadin+0xf7: 740c37e7 83c40c add esp,0Ch 0:080> ub aswCmnBS_74080000!asw::root::CGenericFile::seekreadin+0xe3: 740c37d3 0000 add byte ptr [eax],al 740c37d5 0000 add byte ptr [eax],al 740c37d7 8b464c mov eax,dword ptr [esi+4Ch] 740c37da 57 push edi 740c37db 0345e8 add eax,dword ptr [ebp-18h] 740c37de 50 push eax 740c37df ff7510 push dword ptr [ebp+10h] 740c37e2 e88bc70000 call aswCmnBS_74080000!BZ2_bzerr+0x1d62 (740cff72) 0:080> dd ebp-18 L1 128be34c 57d9ddea That is a really strange offset! And that DWORD appears in the input file at offset 316b3h: │000316a0 a8 65 18 e9 79 40 62 25-96 6e c7 c7 37 6a 83 21 |?e??y@b%?n??7j?!|... │000316b0 08 8e 41 ea dd d9 57 3f-1d 77 49 87 2a 16 06 5e |??A???W??wI?*??^|... │000316c0 a6 38 6a 22 12 a3 51 19-83 7e b6 00 00 31 82 04 |?8j"??Q??~? 1??|... This looks like broken authenticode parsing to me. Proof of Concept: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39530.zip # 0day.today [2024-12-24] #