Hi Tero, On Tue, Oct 12, 2021 at 2:00 AM Tero Kivinen via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Tero Kivinen > Review result: Has Issues > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > This document request webp image format media registration and its security > considerations section do mention some of the security issues (buffer overruns > and uninitialized data usage). Unfortunately graphics libraries have really bad > track record for security, simple search lists about 200-300 CVEs for all > widely used graphics formats (jpeg, png, gif), and even some for webp already > (for which there is reference in security considerations section). > > Those issues include integer overflows, resource exhaustion of memory and other > resources (file descriptors etc), extended resource usage (very long running > time), out-of-bounds writes for both to heap and stack, null pointer > references, very large image sizes, zero image sizes and zero width and/or > height images, information leaks from the decoder (memory layout, obtaining > potentially sensitive information), arbitrary memory writes, memory corruptions > etc. > > As graphics libraries are used in so many places and used in ways where they > can cause severe security issues both on clients (web browsers, email clients) > and servers (for example when automatically converting uploaded images from one > format to another format on servers) the security issues in them are > widespread, i.e., not only limited to the image processing applications > themselves. > > Adding the attack surface even more by adding yet another graphics format with > new libraries will make situation even worse. Also the traditionally graphics > libraries have not been written as being security sensitive, but in the modern > systems they are as integral to the security than the crypto libraries etc. > > Adding bit more warnings about those issues to the security considerations > section would be useful. > Thanks for the review. As you mention it can be tough to have an exhaustive list, but I can incorporate your suggestions into another draft after the last period is complete. I posted version 4 during this process, but learned that the doc should remain mostly stable for the period so I'll keep any edits local for now. > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
