views:

190

answers:

3

I am writing a discussion board software that will have "avatar" images for the users. I want to resize any picture that gets uploaded to a reasonable size. I could easily do that with System.Drawing but that is relying on GDI+ which has hat security problems before. The problem is that the images are untrusted. So I thought of using a fully managed lib to solve that problem because managed code cannot escape the sandbox (of course it can, but only if the code is user-supplied which it is not in my case). So does anybody know of a managed image parser library for JPEG, BMP, PNG and GIF? If some format is missing than I will have to live with that.

Edit: Paint.NET also relies on GDI+.

You might be interested in the discussion below, too.

+1  A: 

Well, what do you prefer? Do you want to use a library that has been put to the test by billions of hack attacks, found wanting but patched up? Or do you prefer some obscure library that hasn't been exposed to such attacks? Yet.

There is zero security in obscurity.

Hans Passant
Managed code is invulnerable to buffer overruns. I expect to get exactly 0 vulnerabilities by using a fully managed parser. It might have bugs but they will deterministically result in an exception.
usr
Erm, no, the image decoders are 100% unmanaged code. In *all* libraries.
Hans Passant
I am looking for a completely managed image parser. Somebody must have done this... I am not sure if GDI+ works in medium trust and a managed parser would. Maybe somebody has created it.
usr
You are not going to find one, image codecs are written in C. C code is *not* insecure by design, it is merely more likely to be exploitable because of a bug. Existing codec code is secure by virtue of it being exposed for so long. Replacing that code with managed code would make it *less* secure. As well as quite slow. For examples how managed code is not secure by design look for exploit stories of Flash and Java, popular attack targets.
Hans Passant
Flash and Java can be attacked because the attacker controls the code (in the browser). I do not allow to upload .NET assemblies to my server. I do not see any way an attacker could exploit my managed image codecs. He can make them crash but not corrupt memory. I consider this to be quite secure in contrast to unmanaged code. No mistake a programmer can make does lead to a security hole.
usr
The reason I am so paranoid about security in this case is that an attacker can actually take over the server by uploading forged images. Last time an exploit existed for GDI+ there were easy to use tools to embed any .exe inside of an image.
usr
"There is zero security in obscurity." Actually it is non-zero because the obscurity is like a password - you have to know it in order to succeed in your hacking attempts. And cracking it can be time-consuming.
usr
+3  A: 

What about VintaSoftImaging.NET? It's a fully-managed .NET library that can resize/resample various image formats (and much more).

It's certainly not the case that all image libraries have unmanaged code--image decoders are written in whatever language the author feels like writing them in. And some do feel like writing them in a managed language; for example, there's also LibTiff.NET and LibJpeg.NET, both 100% managed code. Those are strictly codec libraries though, and won't do any resizing.

Dave Huang
Great answer, thanks. It is enough to have the codec managed IMHO as I can then copy the decoded bits back to System.Drawing.Bitmap and resize and save as usual. Exploits commonly occur in the decoder-part of the stack which now cannot happen anymore (at all).
usr
+1  A: 
Will
A very good answer. I won't be doing that because I first would have to find out how to correctly sandbox a process. I deemed it too much work (for now).
usr