| Summary: | libtiff new security issues CVE-2022-205[6-8] | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | major | ||
| Priority: | Normal | CC: | andrewsfarm, davidwhodgins, herman.viaene, nicolas.salguero, sysadmin-bugs, tarazed25 |
| Version: | 8 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA8-64-OK | ||
| Source RPM: | libtiff-4.2.0-1.5.mga8.src.rpm | CVE: | |
| Status comment: | |||
|
Description
David Walser
2022-07-15 19:48:46 CEST
David Walser
2022-07-15 19:49:02 CEST
Whiteboard:
(none) =>
MGA8TOO Suggested advisory: ======================== The updated packages fix security vulnerabilities: Divide By Zero error in tiffcrop in libtiff 4.4.0 allows attackers to cause a denial-of-service via a crafted tiff file. (CVE-2022-2056, CVE-2022-2057, CVE-2022-2058) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2056 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2057 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2058 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/4TSS7MJ7OO7JO5BNKCRYSFU7UAYOKLA2/ ======================== Updated packages in core/updates_testing: ======================== lib(64)tiff5-4.2.0-1.6.mga8 lib(64)tiff-devel-4.2.0-1.6.mga8 lib(64)tiff-static-devel-4.2.0-1.6.mga8 libtiff-progs-4.2.0-1.6.mga8 from SRPM: libtiff-4.2.0-1.6.mga8.src.rpm Status comment:
Patches available from Fedora =>
(none)
Nicolas Salguero
2022-07-18 10:44:26 CEST
CC:
(none) =>
nicolas.salguero MGA8-64 Plasma on Acer Aspire 5253 No installation issues. First followed wiki and noted that the command bmp2tiff isn't there. Why ???? Other commands listed there work well. Then followed bug 30228 Comment 2 and 3 More or less as in Len's test, the results of raw2tiff were not good. It generates a file, but its contents are like an old analogue TV were the line synchronization was disturbed, at least on the preview in dolphin, and gwenview crashes after showing the file for a second or so. My tests as in bug 30228 Comment 2 all worked OK, I will not repeat here. I have the impression that the problems with raw2tiff are not a regression, I'd rather have someone else (Len??) confirming this. CC:
(none) =>
herman.viaene OK Herman. This took a lot longer than expected. Checked a raw file conversion before updating: $ raw2tiff -w 2864 'KODAK C603 C643 Format 420 CCDI0001.RAW' test_before.tiff Image height is not specified. Height is guessed as 2152. tiffgt displayed a grey image rather than the original full colour image (checked with rawtherapee) and there was a check (plaid) pattern superimposed. The height should be 2144 pixels but I do not see an option in the help list. The man page indicates that the height would be calculated internally from file size minus header size in this case. Tried $ raw2tiff -p rgb -w 2864 'KODAK C603 C643 Format 420 CCDI0001.RAW' test_before.tiff Image height is not specified. Height is guessed as 2152. No show with tiffgt, nor with cmyk or cielab. Updated packages. $ raw2tiff -w 2864 'KODAK C603 C643 Format 420 CCDI0001.RAW' test_update.tiff Image height is not specified. Height is guessed as 2152. $ tiffgt test_update.tiff The update result looked exactly like the test_before image. So, whatever the problem is with raw2tiff (not excluding users) this is not a regression. CC:
(none) =>
tarazed25 Tried using a calculated image header size. $ raw2tiff -H 22912 -w 2864 'KODAK C603 C643 Format 420 CCDI0001.RAW' test_update.tiff Image height is not specified. Height is guessed as 2144. That is correct according to rawtherapee but there is no change in the appearance of the image so the check pattern is likely to be an artefact. Something to do with not specifying a colour model. Beyond my ken.
Herman Viaene
2022-07-21 09:05:07 CEST
Whiteboard:
(none) =>
MGA8-64-OK As a rider to earlier comments, display treats the test output as a monochrome image with normal dithering - no check overlay. $ urpmq --whatrequires lib64tiff5 | uniq | grep -i magick graphicsmagick imagemagick $ strace -o im.trace display test_update.tiff $ grep -i tiff im.trace openat(AT_FDCWD, "/usr/lib64/ImageMagick-7.0.10/modules-Q16HDRI/coders/tiff.so", O_RDONLY|O_CLOEXEC) = 4 openat(AT_FDCWD, "/lib64/libtiff.so.5", O_RDONLY|O_CLOEXEC) = 4 s Validating. Advisory in Comment 2. Keywords:
(none) =>
validated_update
Dave Hodgins
2022-07-25 20:05:08 CEST
CC:
(none) =>
davidwhodgins An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2022-0267.html Resolution:
(none) =>
FIXED |