eEye Digital Security has issued a report listing 14 vulnerabilities in the libFLAC implementation. See http://research.eeye.com/html/advisories/published/AD20071115.html
Since Python Audio Tools uses many of its own routines to handle FLAC and its metadata, I've taken a close look at this report to ensure I haven't missed any vital errors. Fortunately, due to Python's design, the bulk of them simply do not happen barring any bugs in the Python interpreter and I shall explain why.
Vulnerabilities 1, 2, 3, 4, 7, 8, 9 and 12 rely on overflowing malloc(3) by assuming the FLAC decoder will allocate an excessive amount of memory at once prior to filling it. My implementation essentially passes that size argument to Python's read() function call, which doesn't implement large amounts of memory at once and cannot exceed the length of the file.
Vulnerabilities 5 and 6 rely on errors in image handling. Python Audio Tools actually ignores all image metadata fields except when displaying such information via the trackinfo executable or choosing filenames. The image data itself is fed to PyGTK which does the actual image rendering work. Unless PyGTK contains any image parsing vulnerabilities, invalid FLAC image metadata should cause no harm.
Vulnerabilities 10 and 11 exploit FLAC external file capabilities via the '-->' MIME type. Python Audio Tools does not support these (nor have I ever seen such files in the wild). It will not download any external files. I may implement this portion of the spec at some point, but it is currently nonfunctional and harmless.
Vulnerabilities 13 and 14 exploit FLAC's seektable. Since Python Audio Tools does not use FLAC's seektable in any way, one would be vulnerable only if there are some bugs in the "flac" executable itself.
I hope this will ease any fears anyone might have about Python Audio Tool's FLAC handling capabilities. But if anyone finds a possible exploit I may have missed, please contact me at once so I can fix the problem with timely bugfixes.
Log in to post a comment.