Re: MIME types for image attachments

[Eric Wong <e@80x24.org>]

Leah Neukirchen <leah@vuxu.org> wrote:
> Hi,
> 
> I just noticed this on a plain public-inbox 1.6.0 installation:
> 
> https://inbox.vuxu.org/9fans/8F5F1B4BCF0E2F1DA17BDFBF06430DC7@abbatoir.fios-router.home/T/#u
> > [-- Attachment #2: Type: image/png, Size: 56860 bytes --]
> 
> However, when I click on it:
> 
> % curl -I https://inbox.vuxu.org/9fans/8F5F1B4BCF0E2F1DA17BDFBF06430DC7@abbatoir.fios-router.home/2-a.bin
> HTTP/1.1 200 OK
> Server: nginx/1.18.0
> Date: Sat, 07 Nov 2020 19:08:48 GMT
> Content-Type: application/octet-stream
> Content-Length: 56860
> Connection: keep-alive
> 
> Any reason this is not served as image/png?  I don't think serving
> image/* types is particularily dangerous, and it easily allows looking
> at attached images from the browser.

Several reasons off the top of my head (there may be more):

1) Image rendering libraries and complex graphics stacks increase
   attack surface.  IIRC libpng/libjpeg have both had problems with
   malicious data in the past, and could be in the future.

   From what I can tell, text-only stacks seem barely capable of
   displaying text without arbitrary code execution.  I'm not
   optimistic about something as complex as image rendering from
   untrusted sources.

2) Risk of illegal or objectionable content being viewed by
   readers and bystanders, especially when in public (libraries,
   coffee shops, planes, etc).  The risk of accidental clicks
   seems higher in public due to spills/bumps, too, especially
   in unfamiliar environments.

   The current practice of linkifying URLs poses that problem,
   too, but the public-inbox admin isn't responsible for hosting
   the content in those URLs, bringing us to...

3) (Probably) risk to admins hosting public-inbox instances if
   there's illegal content.  Right now, the data is still there,
   but having it less obviously visible probably helps reduce
   exposure when combined with 2).

I am not a lawyer, and laws vary wildly by jurisdiction;
so I think it's prudent to err on the side of paranoia when
dealing in untrusted data sources.

That said, a patch + options to allow passing through certain
content types for the server to pass through could be accepted.
It needs to also require a secondary option visible to the client
(via opt-in cookie or POST), to avoid surprising differences
between differently-configured server instances.

Risks will need to be documented for the admin, and the current
behavior needs to remain the default.