I think Florian is right.
I see a scenario where:
1. someone runs a debuginfod service for closed source software in an
internal network
2. the names for debuginfod server instances are guessable
3. users in corporate networks don't run adblockers
4. the debuginfod defaults change
5. it is now possible to exfiltrate sensitive debug information
I don't think making software insecure by default, even if it is convenient,
is appropriate in 2024. I don't want people not to run debuginfod instances
because of security considerations.
I still think it is a good idea to make it easy to enable
this when serving open source software.
I am not sure what the best way forward is,
usually I would say, make it all configurable,
but debuginfod doesn't have a central configuration file.
I would not like to add more environment variables.
Regards,
Henning
On 08.12.24 12:06, Florian Weimer wrote:
* Frank Ch. Eigler:
Hi -
I'm planning to commit this shortly:
From 4ebefc8f3b4b8fb68a55c960e70122fda50a0fb9 Mon Sep 17 00:00:00 2001
From: "Frank Ch. Eigler" <f...@redhat.com>
Date: Sat, 7 Dec 2024 15:01:54 -0500
Subject: [PATCH] debuginfod: add CORS response headers and OPTIONS method
What are the security implications of a shared origin when serving
(potentially third-party) debuginfo data?
I think it will allow public web clients to exfiltrate debuginfo data
from debuginfod servers on private intranets. Previously, the
cross-origin restrictions on web content would have prevented that.
Thanks,
Florian
