From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 1BA2E1F66F; Sat, 7 Nov 2020 20:39:14 +0000 (UTC) Date: Sat, 7 Nov 2020 20:39:14 +0000 From: Eric Wong To: Leah Neukirchen Cc: meta@public-inbox.org Subject: Re: MIME types for image attachments Message-ID: <20201107203913.GA8294@dcvr> References: <87mtztx9sr.fsf@vuxu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87mtztx9sr.fsf@vuxu.org> List-Id: Leah Neukirchen 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.