From: Leah Neukirchen <leah@vuxu.org> To: Eric Wong <e@80x24.org> Cc: meta@public-inbox.org Subject: Re: MIME types for image attachments Date: Sun, 08 Nov 2020 01:05:38 +0100 Message-ID: <87imagyap9.fsf@vuxu.org> (raw) In-Reply-To: <20201107203913.GA8294@dcvr> (Eric Wong's message of "Sat, 7 Nov 2020 20:39:14 +0000") Eric Wong <e@80x24.org> writes: > 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. Well, that's what probably literally every other website on the web does. ;) > 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... Yes, I don't want to inline the data but just display it on click. It's the same as any other Mailman or Google Groups archive. > 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). Notice that deep-linking this attachment (e.g. with <img src= />) will already display the image, as it triggers content autodetection. > 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. I think it would be more correct to send the real MIME type and "Content-Disposition: attachment" (or "inline" then, when asked for). (However this does not prevent hotlinking either...) > Risks will need to be documented for the admin, and the current > behavior needs to remain the default. -- Leah Neukirchen <leah@vuxu.org> https://leahneukirchen.org
next prev parent reply other threads:[~2020-11-08 0:05 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-07 19:10 Leah Neukirchen 2020-11-07 20:39 ` Eric Wong 2020-11-08 0:05 ` Leah Neukirchen [this message] 2020-11-08 7:49 ` [PATCH] wwwattach: set "Content-Disposition: attachment" Eric Wong 2020-11-23 14:15 ` [PATCH v2] wwwattach: prevent deep-linking via Referer match Eric Wong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://public-inbox.org/README * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87imagyap9.fsf@vuxu.org \ --to=leah@vuxu.org \ --cc=e@80x24.org \ --cc=meta@public-inbox.org \ --subject='Re: MIME types for image attachments' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
user/dev discussion of public-inbox itself This inbox may be cloned and mirrored by anyone: git clone --mirror https://public-inbox.org/meta git clone --mirror http://czquwvybam4bgbro.onion/meta git clone --mirror http://hjrcffqmbrq6wope.onion/meta git clone --mirror http://ou63pmih66umazou.onion/meta # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 meta meta/ https://public-inbox.org/meta \ meta@public-inbox.org public-inbox-index meta Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.mail.public-inbox.meta nntp://ou63pmih66umazou.onion/inbox.comp.mail.public-inbox.meta nntp://czquwvybam4bgbro.onion/inbox.comp.mail.public-inbox.meta nntp://hjrcffqmbrq6wope.onion/inbox.comp.mail.public-inbox.meta nntp://news.gmane.io/gmane.mail.public-inbox.general note: .onion URLs require Tor: https://www.torproject.org/ code repositories for project(s) associated with this inbox: https://80x24.org/public-inbox.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git