vulnerabilities in standards

11 views
Skip to first unread message

Kurt Seifried

unread,
Feb 13, 2022, 6:48:47 PM2/13/22
to GSD Discussion Group
So I was doing some research into libjpeg-turbo and ran across:


"""
It is concerned with
two particular issues uncovered by the auditors. In examining the code, they were able to find
two scenarios under which they could make the JPEG library consume resources significantly
out of proportion to the size of the data being processed. While these were originally thought to be issues with the implementation, further investigation has revealed that they stem from the design of the JPEG format itself. The problems can be triggered using JPEG images which entirely conform to the spec, and the issues have been observed in multiple JPEG
implementations. This report explains those two issues in detail and provides advice to
application developers as to how to work around them if their applications are processing
untrusted input.
"""

Specifically:

LJT­01­003: CPU Overconsumption Using Extraneous Progressive Scans
LJT­01­004: Memory Overconsumption Using Large Images

Now I think these should get a GSD identifier, ideally against the specification (e.g. ISO/IEC 10918-1 | ITU-T Recommendation T.81) 

But what do we do about all the affected vendors (to say a lot of things implement jpeg processing software would be an understatement)? I feel like this is the log4j situation all over (1000+ vendors/products), a GSD in the multi-megabyte range is less than ideal, I suspect the best solution is to break it up into multiple GSD entries with relationship data (e.g. "child of") at least at a vendor/project level, possibly further if needed. 

I also feel like a major part of this would be having proper machine-readable data about what is affected (e.g. CPE/Purl/SWID/whatever) to make machine parsing possible, and obviously, we would want to provide a search capability longer-term (we technically already do via GitHub's search but you can't use operators and patterns easily). 

Kurt Seifried (He/Him)
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
Reply all
Reply to author
Forward
0 new messages