Opened 13 years ago
Closed 13 years ago
#1202 closed defect (invalid)
Read Access Violation in memcpy
Reported by: | John Villamil | Owned by: | |
---|---|---|---|
Priority: | critical | Component: | ffplay |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
This is a read access violation within a call to memcpy. An attacker has control over esi.
(21ed4.21e30): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
* ERROR: Symbol file could not be found. Defaulted to export symbols for C:\windows\syswow64\msvcrt.dll -
msvcrt!memcpy+0x250:
74dd9b60 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
0:002:x86> $<dbgcomm.txt
0:002:x86> r
eax=077b3f68 ebx=00000e38 ecx=00000046 edx=00000000 esi=077b3e50 edi=02ea2178
eip=74dd9b60 esp=02e8fab0 ebp=02e8fab8 iopl=0 nv up ei pl nz ac po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010212
msvcrt!memcpy+0x250:
74dd9b60 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
0:002:x86> !load winext\msec.dll
0:002:x86> !exploitable
Exploitability Classification: PROBABLY_EXPLOITABLE
Recommended Bug Title: Probably Exploitable - Read Access Violation on Block Data Move starting at msvcrt!memcpy+0x0000000000000250 (Hash=0x23671766.0x0d446b3f)
This is a read access violation in a block data move, and is therefore classified as probably exploitable.
0:002:x86> q
quit:
This was tested on the shared build from 2012-04-09 found at http://ffmpeg.zeranoe.com/builds/
PoC file can be downloaded from the following url:
http://w.rdtsc.net/ffmpegmkv/ProbablyExploitable/memcpyReadAV.zip
Thanks,
John Villamil
Change History (3)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Hello, I cannot reproduce this issue, it might have been a freak occurrence.
comment:3 by , 13 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Thank you for clarifying.
Note that ffplay has the disadvantage of depending on an external library, that is a reason why bug reports against ffmpeg are preferred.
The sample does not crash here and valgrind does not report any problems.
Is the problem also reproducible with a static ffmpeg build? A static ffplay build? (Or one with debug symbols?)
Does the sample crash on windows with "ffmpeg -i 246770RA_missing_timestamps.mkvtest869.mkv -f null -" or ffplay 246770RA_missing_timestamps.mkvtest869.mkv ?
If yes, please provide a backtrace, consider using a non-stripped binary.