https://bugs.winehq.org/show_bug.cgi?id=45104
Bug ID: 45104 Summary: OOB read in gdiplus Product: Wine Version: 3.7 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs@winehq.org Reporter: robert.gawlik@rub.de Distribution: ---
Original submitted report can be found here: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/1764719
(*) Out-of-bounds read in dlls/gdiplus/metafile.c:2528 (last commit: dd2624a24fba400bf59b9396e496d16c43d399d9):
The parameters data, dataSize and recordType are completely user controlled and flow into a memcpy() call in line 2528. If the length of data is less than dataSize, then this results in an out-of-bounds read.
2461 GpStatus WINGDIPAPI GdipPlayMetafileRecord(GDIPCONST GpMetafile *metafile, 2462 EmfPlusRecordType recordType, UINT flags, UINT dataSize, GDIPCONST BYTE *data) 2463 { .... 2471 2472 if (recordType >= 1 && recordType <= 0x7a) 2473 { 2474 /* regular EMF record */ 2475 if (metafile->playback_dc) 2476 { 2477 switch (recordType) 2478 { .... 2520 default: 2521 { 2522 ENHMETARECORD *record = heap_alloc_zero(dataSize + 8); // <== dataSize is completely user controlled 2523 2524 if (record) 2525 { 2526 record->iType = recordType; 2527 record->nSize = dataSize + 8; 2528 memcpy(record->dParm, data, dataSize); // <== data is user controlled, memcpy performs OOB read 2529 2530 if(PlayEnhMetaFileRecord(metafile->playback_dc, metafile->handle_table, 2531 record, metafile->handle_count) == 0) // (record is user controlled => source of many vulnerabilities) 2532 ERR("PlayEnhMetaFileRecord failed\n");
If you need more information (EMF trigger file, etc.) let me know!
https://bugs.winehq.org/show_bug.cgi?id=45104
Jens Reyer jre.winesim@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jre.winesim@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45104
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- It's up to caller to provide valid size on input, how do you propose to fix this?
https://bugs.winehq.org/show_bug.cgi?id=45104
--- Comment #2 from Vincent Povirk madewokherd@gmail.com --- That would be true if it were an application calling GdipPlayMetafileRecord with input that would have a similar issue on Windows. However, the launchpad bug seems to indicate this happens internally to GDI+ when drawing an EMF file.
https://bugs.winehq.org/show_bug.cgi?id=45104
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=45104
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|gdiplus |gdi32
--- Comment #3 from Vincent Povirk madewokherd@gmail.com --- EnumEnhMetaFile doesn't give enough information for our callback to determine whether the size we get is valid. I think gdi32 should not enumerate the record in this case.
https://bugs.winehq.org/show_bug.cgi?id=45104
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
--- Comment #4 from Vincent Povirk madewokherd@gmail.com --- I sent a couple of patches to get this started: https://www.winehq.org/pipermail/wine-devel/2018-May/126667.html https://www.winehq.org/pipermail/wine-devel/2018-May/126668.html
I think that only addresses this bug. Figuring out proper size checking and object index checking for all the records is going to be more involved.
https://bugs.winehq.org/show_bug.cgi?id=45104
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #5 from Fabian Maurer dark.shadow4@web.de --- Since the patches are accepted, is this issue fixed?
https://bugs.winehq.org/show_bug.cgi?id=45104
Michael Cronenworth mike@cchtml.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@cchtml.com
--- Comment #6 from Michael Cronenworth mike@cchtml.com --- Are bugs 45104, 45105, and 45106 going to be backported into the stable branch?