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] [day] [month] [year] [list]

From: mettlers at thehive.ch (Sascha Mettler)
Subject: avoid jpeg overflow problems using on the fly
 conversion?

Valdis.Kletnieks@...edu wrote:

>On Fri, 17 Sep 2004 23:03:10 +1200, Nick FitzGerald said:
>
>>nd, 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?
>>    
>>
No we don't, Nick is right. It still might be easier to deal with the 
problem on one gateway in a DMZ, given the fact that unfortunately it's 
not an option to get rid of IE and installing MS04-028 at my workplace 
can't be done as fast as I'd like.

And William's objection regarding the fact that it's an IE issue is once 
again correct, and once again we're an IE only shop and besides, it 
should be fairly easy to perform the actions based on the user-agent.

>There's also another sticky issue - it seems at least one release of AOL's
>"net accelerator" basically consisted of code that downgraded all the .JPG
>to a higher-compression (therefore more lossy) format.  Some questioned
>what this meant for places like corbis.com, who make money selling *high*
>quality images.  Applying type conversions like this is always fraught with
>unintended consequences... :)
>  
>
I'm not working for an ISP. We're already filtering most of the 
active-content and use whitelisting for javascript, java, activex and 
https. Employees tend to accept limitations customers wouldn't, simply 
because management sets a high priority on security. And there are 
isolated surf stations without those limitations on every floor.

>Bonus points for figuring out how to make the filtering work if the
>front-end points at an https: :)
>  
>
there are content scanners for https (microdasys, webwasher, partly 
proxomitron). of course you need to install a new trusted CA cert into 
IE's store and it's comparable to a mitm attack. but if it comes to the 
security of your internal data, it might be an option.

thanks for all your feedback. I admit that the whole concept of 
converting potentially evil stuff is not more than a quick'n'dirty 
workaround. A better solution would be to add content screening for 
"data"-files on the gateway. This could protect from future weaknesses 
on the client. I remember seeing a presentation at RAID2002 from two 
guys from the University of Vienna (TU Wien, don't remember their names 
sorry) where they talked about a filter which analyzes data towards 
consecutive valid opcodes for intel cpu's. Then using a threshold value 
for deciding whether the incoming data might be malicious code. That 
might be a more general approach than to add format validation checks 
for every file type.

regards
Sascha