Many many years ago I saw someone using an image hoster which only checked mime type, and not filename. That's the important bit after all right? Uploading an image as image.php worked, and if the exif comment contained php code, it ran.
Exif Smuggling (2025)
21–30 of 32 posts
Re: Exif Smuggling (2025)
#22is this within the category of normal steganographic encodings and packers, or does it have the ability to execute itself? you can encode anything as anything. I am interpreting it's a slightly interesting tool to fool signature based detection, but isn't something like running a weird machine in an external decoder.
Re: Exif Smuggling (2025)
#23It isn't necessary to use Exif to embed arbitrary data inside an image. Could as well use PNG extra chunk, JFIF app marker, or simply append data to the end of the file. It would be more interesting to devise a method that survives all extra data stripping and re-encoding, perhaps taking advantage of deterministic encoders, assuming they don't randomize pixel data on purpose. In other words: turning the image data st…
Do you mean steganography?
[deleted]
Re: Exif Smuggling (2025)
#24Oh, that's clever. It's not just hiding the payload in the Exif, it's hiding the fact that the payload came from the network at all, by reading it from the browser cache (presumably after embedding the image into a page the user visited). So you have a package that doesn't include (directly) malicious code or make network calls, yet it can still run malicious code from the network. This is much better than simple obf…
More than that; the trigger code can sit passively and just check the cache for whatever payloads may come its way.
I suppose image sanitizers come soon to browsers. Only sanitized images will be cached; anything the browser can't make sense of will be thrown away.
Re: Exif Smuggling (2025)
#25Earlier quoted context omitted.
Isnt this the principle behind synthid?
Maybe if you look at it from far away enough. Watermarking tries to resist image data manipulation. Smuggling data is concerned with preservation of bytes. Though if we're executing arbitrary code on the target anyway, ways of embedding data in an image are vast, including watermarking/steganography.
Steganography has rather obvious size limits if you want the image continue looking innocent. EXIF data is way less limited.
Re: Exif Smuggling (2025)
#26Oh, that's clever. It's not just hiding the payload in the Exif, it's hiding the fact that the payload came from the network at all, by reading it from the browser cache (presumably after embedding the image into a page the user visited). So you have a package that doesn't include (directly) malicious code or make network calls, yet it can still run malicious code from the network. This is much better than simple obf…
More than that; the trigger code can sit passively and just check the cache for whatever payloads may come its way. I suppose image sanitizers come soon to browsers. Only sanitized images will be cached; anything the browser can't make sense of will be thrown away.
ComfyUI embeds workflows in the EXIF data. It's very handy. Would be a little sad if they stripped that out but there are alternatives.
I suppose if it's only cached images and not manually downloaded images it wouldn't be bad. It'd probably break some website somehow though.
Re: Exif Smuggling (2025)
#27[deleted]
Re: Exif Smuggling (2025)
#28Why is this a link to a random fork that has no commits, rather than the original?
GitHub star farming, I'm guessing?
Re: Exif Smuggling (2025)
#29Oh, that's clever. It's not just hiding the payload in the Exif, it's hiding the fact that the payload came from the network at all, by reading it from the browser cache (presumably after embedding the image into a page the user visited). So you have a package that doesn't include (directly) malicious code or make network calls, yet it can still run malicious code from the network. This is much better than simple obf…
More than that; the trigger code can sit passively and just check the cache for whatever payloads may come its way. I suppose image sanitizers come soon to browsers. Only sanitized images will be cached; anything the browser can't make sense of will be thrown away.
Exif is only the most convenient method here - you can use steganography hide arbitrary data right in the image content itself. Sanitizing would that would mean messing with how images look.
Re: Exif Smuggling (2025)
#30Many many years ago I saw someone using an image hoster which only checked mime type, and not filename. That's the important bit after all right? Uploading an image as image.php worked, and if the exif comment contained php code, it ran.
More than that, you need to check the file is a valid image, not just the mime type. I remember a host that let me upload an aspx file as a jpg and it allowed me to execute it and browse their entire file system until I found the SQL Server and network administrator passwords in a text file.
The passwords were both "internet".