I have read that some image viewers were hacked by appropriately doctored images (in a format particularly suited for that? not sure about the details).
So, how could this threat be completely eliminated? For instance, suppose we make a viewer for the affected format written in managed code and have it convert images to a pure BMP (or something else so simple that its viewers cannot be hacked); would the problem go away? How about first convert to BMP and then introduce some pervasive minor random pixel alterations to better disrupt the possible hack?
Let's say this image sanitization converter would be incorporated into the firewall so that only "safe" sanitized images would, by default, end up loaded during regular browsing. Would this solve the problem? Or is my reasoning incorrect due to flawed understanding of the nature of image based exploits?
Your question, i think, boils down to whether the attack lives in the data or in the image. If it's in the data, then merely decoding the image and re-encoding with a known-good encoder it will ensure safety. If it's in the image, then you may need to alter the pixels.
The famous example of this was mishandling of JPEG comment fields with bad lengths, originally a bug in Netscape, but later independently introduced into Windows. This was very much a data rather than an image problem; the part of the data in question isn't even image data, it's metadata. If you decoded the image with a sandboxed decoder, perhaps detecting and recovering from the corrupt comment field, then re-encoded it with a friendly encoder, the result would be safe even for vulnerable decoders. Doing this naively would lead to a loss of quality; it is possible to losslessly transcode JPEGs, but it requires code to specifically do so.
My gut feeling is that image-level attacks are not possible, only data-level attacks. Image formats are well-enough specified, and fundamentally simple enough, that the content of the image really shouldn't affect the decoding process. I certainly can't prove that, though, nor really even argue for it.
Related
I just started at a new company and have been asked to do what I believe impossible, but I need confirmation on this. The website that my company has allows users to view images in extremely high resolution using SVGs. We've built a custom viewer for these images that allow you to zoom and scroll around the image and it works well. Because of this, the image format "needs" to remain SVG. However, we need to include a watermark to this image. The way we're doing this right now is passing the SVG and PNG watermark to the client, inserting the watermark into the SVG, and displaying it to the user. This is very obviously easily hacked as anyone with client-side experience knows (The dev team here is mostly older developers and don't have much web experience). Even if the raw SVG isn't intercepted, they can still just delete the watermark from the source. I've convinced my boss to make the watermark be injected on the server-side, so this leaves just the problem that SVGs are editable by the end-client.
What I want to know is if one of these two things are possible:
1) Is there another image format akin to SVG that could be used to keep this highly scalable image without loosing resolution, and without it being directly editable by an end-client? The only options that people seem to discuss for the web is JPG, GIF, PNG, and SVG. I've looked at Adobe Illustrator ".ai" files and EPS (Encapsulated PostScript) as other vector options, but I can't find anywhere if I can modify these images in PHP, which is key if I want to overlay a watermark in server-side code.
2) Is there a way to obfuscate the raw SVGs content so that the use can't go and manipulate it? I've seen SVGs that have <image ...> tags inside them with PNGs represented as long and complex strings before. Something like xlink:href="data:image/png;base64...". I was wondering if there's a way to display an SVG as this string, so that the data can't be directly manipulated. I'm sure there's an algorithm to reverse these, but so long as we're sticking with SVGs, I need to make this as secure as possible with as many hoops to jump through as possible if someone wants to steal the data.
Either way would be acceptable, as long as removing this watermark is more complex than just hitting F12 and removing the element inside the dev tools.
Is there another image format akin to SVG that could be used to keep this highly scalable image without loosing resolution, and without it being directly editable by an end-client?
SVG is a vector format, and to maintain extreme scalability, you need to stick with vectors, be it any format. However, in that case it will always be possible to remove the vectors that belong to your watermark. There are of course vector formats that are stored as binary, which would make it somewhat harder for an enduser to parse and edit, but those are not editable in PHP either, and are much less compatible. So you probably don't want to do this.
Is there a way to obfuscate the raw SVGs content so that the user can't go and manipulate it?
First, it will never be "secure" in the sense that as said above, it will always be possible to remove the watermark from a vector image. (Btw the only difference to bitmap formats like JPG is that content below the watermark in bitmap is actually missing, while in SVG it's still there.)
However, depending on how "good" you want this to be, you can do a few things. I think the "goodness" here means the effort needed to remove the watermark, and you can raise the bar relatively easily. You don't have to (and you probably can't reasonably) obfuscate the whole SVG.
One thing that comes to mind is that SVG is basically just XML, it consists of tags like <rect>, <line>, <circle> etc. The order of these tags doesn't matter much (mostly, with exceptions of course). So you could entwine the tags that draw your watermark pretty much randomly among existing tags. I mean really randomly, so different downloads would produce different results. If you do this well (eg. you find line tags to "hide" your watermark line tags, and so on), it will be hard to automatically remove the watermark, because it's all over relevant data that is your actual image. Of course, the watermark could still be visually in a corner, and this is already a weakness, anything drawn to a corner could possibly be removed automatically. And it will be easy to remove by hand with any decent editor I suppose. So it depends on what the purpose is.
But I still think this sort of thing could make it hard enough in many scenarios (and would be totally inadequate in others).
Could anyone please explain briefly the difference between JPEG and EZW? And why JPEG is more popular? Is JPEG always better than EZW or just in most of the cases?
Thank you very much!
EZW is a theoretical technique which can be used as one step in wavelet compression. It's not a complete image encoder, and can't be used on its own. As best I can tell, nobody has proposed any image formats which depend on EZW, so nothing uses it (to the best of my knowledge).
(As an aside, wavelet image compression techniques have generally proven unsuccessful.)
JPEG, by contrast, is a standard which encompasses all layers of an image compressor, including the DCT as well as everything surrounding it: color space, entropy coding, file format, metadata, etc. Unlike EZW, it's been a complete, usable standard since 1992.
as the title, I used to use .dds, it did work,now I use type of .png, can it generate mipmap? Here functions what I am using: glTexImage2D(…).Or maybe gluBuild2DMipmaps(…) a better choice?
DDS are an image format that contains precalculated mipmaps. As far as quality goes, precalculated mipmaps offer the best quality, since they can be downsampled offline with advanced filter kernels like Lancozs, without having to care about runtime efficiency.
PNG does not contain additional mipmap levels so you have to compute the mipmaps at runtime. You should however not use gluBuild2DMipmaps for this. For one this function is known to exhibit buggy behavior in certain conditions and furthermore it will unconditionally resample all images to power-of-2 dimensions, although since OpenGL-2 non power-of-2 dimensions are perfectly fine for texture images.
Instead you should load the base level image with glTexImage2D(…) and use glGenerateMipmap(…) (available since OpenGL-3) to build the mipmap image pyramid from there. If you don't use OpenGL-3, you can use the SGIS_generate_mipmap extension, if available.
However be advised that online mipmap generation may yield not as good results as offline generation.
Another possible approach would be the use of JPEG2000 images; the nature of JPEG2000 image encoding results in an image pyramid being readily available. OTOH JPEG2000 is very costly to encode and decode.
I'm putting together a mobile version of a webpage which consists entirely of client art. For the old-fashioned desktop version, I just used PNGs, but I really wanted to use SVG for mobile. SVGZ would be smaller and resolution independent, so it seemed like a perfect use case.
But the client is worried that, once his art is online in SVG, anyone could download the files and use his art illegally (he's had stuff he worked on pirated before, so he takes this pretty seriously.) This had never occurred to me until he brought it up, but the SVG would basically be his original source art.
I was wondering if there's any way to prevent the SVG files from being accessed by the user. As far I know this is impossible -- making the files available to the user-agent means making them available to the user -- but I wanted to ask around to be sure.
Thanks for any help.
No, this is impossible. If a web browser can request the files for display, then any computer anywhere can request the files and save the direct results.
Serving up intentionally degraded artwork (e.g. rasterization) is the only way to prevent people from having the originals. Of course, a determined thief could still re-trace the PNG and get a vectorized, resolution-independent close approximation of the original.
Your client could alternatively:
Include copyright comments in the source, proving ownership. (Yes, a thief could delete these.)
Include 'hidden' elements (0% opacity or placed under another item), proving ownership. (Yes, a thief could delete these.)
Use data steganography in the source SVG to watermark it (e.g. vary the decimal values in a path in a manner minor enough to not effect the result, but still embed custom data). (Yes, any thief suspecting this could lower decimal precision or transform all values in a manner that might remove this.)
Trust in the law to protect his works, or provide a recourse if they are stolen.
Trust in the goodness of most of mankind to not do this.
Decide that theft is the sincerest form of flattery, and not worry about it. :)
So, to simplify my life I want to be able to append from 1 to 7 additional characters on the end of some jpg images my program is processing*. These are dummy padding (fillers, etc - probably all 0x00) just to make the file size a multiple of 8 bytes for block encryption.
Having tried this out with a few programs, it appears they are fine with the additional characters, which occur after the FF D9 that specifies the end of the image - so it appears that the file format is well defined enough that the 'corruption' I'm adding at the end shouldn't matter.
I can always post process the files later if needed, but my preference is to do the simplest thing possible - which is to let them remain (I'm decrypting other file types and they won't mind, so having a special case is annoying).
I figure with all the talk of Steganography hullaballo years ago, someone has some input here...
(encryption processing by 8 byte blocks, I don't want to save pre-encrypted file size, so append 0x00 to input data, and leave them there after decoding)
No, you can add bits to the end of a jpg file, without making it unusable. The heading of the jpg file tells how to read it, so the program reading it will stop at the end of the jpg data.
In fact, people have hidden zip files inside jpg files by appending the zip data to the end of the jpg data. Because of the way these formats are structured, the resulting file is valid in either format.
You can .. but the results may be unpredictable.
Even though there is enough information in the format to tell the client to ignore the extra data it is likely not a case the programmer tested for.
A paranoid program might look at the size, notice the discrepancy and decide it won't process your file because clearly it doesn't fully understand it. This is particularly likely when reading data from the web when random bytes in a file could be considered a security risk.
You can embed your data in the XMP tag within a JPEG (or EXIF or IPTC fields for that matter).
XMP is XML so you have a fair bit of flexibility there to do you own custom stuff.
It's probably not the simplest thing possible but putting your data here will maintain the integrity of the JPEG and require no "post processing".
You data will then show up in other imaging software such as PhotoShop, which may not be ideal.
As others have stated, you have no control how programs process image files and therefore some programs may find the images valid others may not.
However, there is a bigger issue here. Judging by your question, I'm deducing you're practicing "security through obscurity." It's widely considered a very bad practice. Use Google to find a plethora of articles about the topic.