5 ms·

>Re-encoding the image is a good idea to make it harder to distribute exploits. For example imaging the recent WebP vulnerability. And now your server which is

by mmsc 2y ago

>Re-encoding the image is a good idea to make it harder to distribute exploits. For example imaging the recent WebP vulnerability. And now your server which is doing re-encoding is pwned. Gotta segment the server doing that somehow, or use pledge, capsicum, or seccomp I guess.

afiori 2y ago
For video you might want to use the GPU, but for images this sounds like a good use case for Wasm
dpkirchner 2y ago
This is a pretty good use case for serverless endpoints, assuming the volume is pretty low.
- hamandcheese 2y ago
  Serverless + making sure the serverless function doesn't have any privileges. More often than not I see people use serverless in the name of security, and then give the function write access to prod resources.
- Hamuko 2y ago
  I've ran into a security issue where a serverless function had pretty large range of AWS access and a pentester was able to utilise that.
  - dpkirchner 2y ago
    That's a bad use case for serverless :)
- cyberpunk 2y ago
  Ideal use case for a cheeky OpenBSD machine... Not that OpenBSD is actually unhackable or anything, but I doubt many attackers would guess you're running imagemagick on OpenBSD in your image pipeline. I rather like it for such use cases; it has the added benefit that it never, ever seems to die. I found a 6.0 machine I setup doing some kind of risky Kafka processing that had an uptime of 6 years the other week (since migrated).
  - Moru 2y ago
    I had to reboot one of our servers last year, also just over 6 years. Reboot because physical move to another server hotel, not because it wasn't working :-) It is running imagemagic to optimize images, create different resolutions and reencode them. It's only open for us to upload manually from our customers though, they can't upload themselves. Input anything, output jpg, very easy to use.
forgotusername6 2y ago
Draw image to canvas in the browser. Read image from canvas. Upload. If you are completely paranoid you could then upload raw pixel data only and construct whatever image format you wanted server side.
- samus 2y ago
  The user could push the file to the endpoint directly without using the client-side functionality.
  - gopher_space 2y ago
    I think the idea is that a browser needs to do this conversion to display images, so you'd be writing a http client that will run server-side and process each uploaded file as if it were a http response. It'd need to be transmissible via screenshot at this point, right?
    - samus 2y ago
      By running a web browser on the server you are at square one again: running the encoder on the server, which is risky.
      - gopher_space 2y ago
        In this case isn't the browser decoding the image and drawing a bitmap? That sounds more like a critical vulnerability in e.g. Chrome. In my mind the chain of events looks like: - Alice uploads an image file to Bob's file server - Charlie's image converter server invokes a local browser with the address of the file on Bob's server, resulting in a .bmp (or .png? a little out of my element here) saved to Charlie's server. - Doris can now pull images from Charlie's server knowing they've been vetted by a major browser. Does that make sense?
        samus 2y ago
        Yes, which outsources the problem to Charlie. Charlie has to firewall and lockdown that browser as much as possible to reduce the risk of Alice pwning Charlie, else Charlie's server could (among other things) be made to taint all output files. Browsers are not magically immune, they also just call decoder libraries.
SkyPuncher 2y ago
We run these services on isolated machines.
- hypeatei 2y ago
  How isolated? If it's an image processing service then it can't live in a vacuum and needs to talk to something else at a certain point.
  - SkyPuncher 2y ago
    Only accept in-bound requests. Don't provided it with any special credentials. Someone might still be able to get an RCE on them and burn a bit of money, but they certainly wouldn't be able to move laterally.
remram 2y ago
Or WebAssembly: https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...

by mmsc 2y ago

afiori 2y ago

For video you might want to use the GPU, but for images this sounds like a good use case for Wasm

dpkirchner 2y ago

This is a pretty good use case for serverless endpoints, assuming the volume is pretty low.

hamandcheese 2y ago
Serverless + making sure the serverless function doesn't have any privileges. More often than not I see people use serverless in the name of security, and then give the function write access to prod resources.
Hamuko 2y ago
I've ran into a security issue where a serverless function had pretty large range of AWS access and a pentester was able to utilise that.
- dpkirchner 2y ago
  That's a bad use case for serverless :)
cyberpunk 2y ago
Ideal use case for a cheeky OpenBSD machine... Not that OpenBSD is actually unhackable or anything, but I doubt many attackers would guess you're running imagemagick on OpenBSD in your image pipeline. I rather like it for such use cases; it has the added benefit that it never, ever seems to die. I found a 6.0 machine I setup doing some kind of risky Kafka processing that had an uptime of 6 years the other week (since migrated).
- Moru 2y ago
  I had to reboot one of our servers last year, also just over 6 years. Reboot because physical move to another server hotel, not because it wasn't working :-) It is running imagemagic to optimize images, create different resolutions and reencode them. It's only open for us to upload manually from our customers though, they can't upload themselves. Input anything, output jpg, very easy to use.

forgotusername6 2y ago

Draw image to canvas in the browser. Read image from canvas. Upload. If you are completely paranoid you could then upload raw pixel data only and construct whatever image format you wanted server side.

samus 2y ago
The user could push the file to the endpoint directly without using the client-side functionality.
- gopher_space 2y ago
  I think the idea is that a browser needs to do this conversion to display images, so you'd be writing a http client that will run server-side and process each uploaded file as if it were a http response. It'd need to be transmissible via screenshot at this point, right?
  - samus 2y ago
    By running a web browser on the server you are at square one again: running the encoder on the server, which is risky.
    - gopher_space 2y ago
      In this case isn't the browser decoding the image and drawing a bitmap? That sounds more like a critical vulnerability in e.g. Chrome. In my mind the chain of events looks like: - Alice uploads an image file to Bob's file server - Charlie's image converter server invokes a local browser with the address of the file on Bob's server, resulting in a .bmp (or .png? a little out of my element here) saved to Charlie's server. - Doris can now pull images from Charlie's server knowing they've been vetted by a major browser. Does that make sense?
      - samus 2y ago
        Yes, which outsources the problem to Charlie. Charlie has to firewall and lockdown that browser as much as possible to reduce the risk of Alice pwning Charlie, else Charlie's server could (among other things) be made to taint all output files. Browsers are not magically immune, they also just call decoder libraries.

SkyPuncher 2y ago

We run these services on isolated machines.

hypeatei 2y ago
How isolated? If it's an image processing service then it can't live in a vacuum and needs to talk to something else at a certain point.
- SkyPuncher 2y ago
  Only accept in-bound requests. Don't provided it with any special credentials. Someone might still be able to get an RCE on them and burn a bit of money, but they certainly wouldn't be able to move laterally.

remram 2y ago

Or WebAssembly: https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...