full-disclosure - avoid jpeg overflow problems using on the fly conversion?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: avoid jpeg overflow problems using on the fly
 conversion?

mettlers@...hive.ch wrote:

<<snip>>
> imho on the fly converting jpg to png should mitigate the risk of getting
> malicious jpeg's. while blocking jpeg for external mail might have a low
> impact, doing the same for http is not really an option. Installing
> MS04-028 in a larger environment might not be that easy either. Of course
> micro_proxy/png2jpg runs via (x)inetd and might not be performant enough
> to handle huge loads.

Ummmm -- why go to all this bother (and overhead)??

If you are prepared to consider format translation to avoid this type 
of threat, why not, istead, simply implement a "is there a comment 
field with an (invalid) size declaration of zero or one" sanity filter. 
Much less overhead (only has to scan the file for comment fields, 
rather than having to perform format translation) _AND_ provides an 
obvious way of dealing with "dodgy" JPEGs -- simply replace any that 
fail the sanity check with an image that contains a warning explaining 
why the original has not been allowed through (at least, it's simple if 
we ignore localization issues...).

And, your suggestion does not say what to do with "bad" JPEGs -- it 
seems you assume the JPG to PNG convertor will necessarily and 
"correctly" deal with such invalid input.  Do we really know that is a 
valid assumption?

Regards,

Nick FitzGerald