naruto-lgtm opened a new pull request, #1486: URL: https://github.com/apache/poi/pull/1486
Repro: add two different images whose CRC32 matches (e.g. the bytes "plumless" and "buckeroo") to an XMLSlideShow; the second addPicture returns the first picture, so the second image is silently replaced by the first one's content. Cause: findPictureData treats a CRC32 match as identical data. CRC32 is trivial to collide on purpose (append four bytes to any image) and collides by chance in large decks. XSLFSlide.importContent copies every picture through addPicture, so when slides from an untrusted deck are merged into another, a crafted image can stand in for a picture that gets added later. Fix: on a checksum match, also compare the bytes, which is what XWPFDocument.findPackagePictureData already does. Real duplicates are still reused; the extra compare only runs on a checksum hit. HSLF is left as is: it compares the MD5 UID defined by the format, and its getData rebuilds the WMF placeable header, so a byte compare there would stop WMF duplicates from being deduplicated. Regression test added to TestXSLFSlideShow; it fails before the change. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
