* [Bug debuginfod/27917] New: protect against federation loops
@ 2021-05-26 17:48 fche at redhat dot com
2021-06-08 14:13 ` [Bug debuginfod/27917] " dichen at redhat dot com
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: fche at redhat dot com @ 2021-05-26 17:48 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27917
Bug ID: 27917
Summary: protect against federation loops
Product: elfutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: debuginfod
Assignee: unassigned at sourceware dot org
Reporter: fche at redhat dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
If someone misconfigures a debuginfod federation to have loops, and a
nonexistent buildid lookup is attempted, bad things will happen, as is
documented. Let's reduce the risk by adding an option to debuginfod that
functions kind of like an IP packet's TTL: a limit on the length of XFF: header
that debuginfod is willing to process.
The simplest thing could be a comma (= hop) limit: "if X-Forwarded-For: exceeds
N hops, do not delegate a local lookup miss to upstream debuginfods". The
default could be reasonably high, say 8. Then recursion is guaranteed to
terminate.
Note that it wouldn't be right to simply reject requests with one's own IP
address (which a server doesn't really easily know anyway), because there could
be multiple servers running on any given host; or network-local RFC1918
addresses could legitimately recur.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug debuginfod/27917] protect against federation loops
2021-05-26 17:48 [Bug debuginfod/27917] New: protect against federation loops fche at redhat dot com
@ 2021-06-08 14:13 ` dichen at redhat dot com
2021-06-25 18:59 ` amerey at redhat dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: dichen at redhat dot com @ 2021-06-08 14:13 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27917
Di Chen <dichen at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |dichen at redhat dot com
CC| |dichen at redhat dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug debuginfod/27917] protect against federation loops
2021-05-26 17:48 [Bug debuginfod/27917] New: protect against federation loops fche at redhat dot com
2021-06-08 14:13 ` [Bug debuginfod/27917] " dichen at redhat dot com
@ 2021-06-25 18:59 ` amerey at redhat dot com
2021-08-26 3:04 ` dichen at redhat dot com
2021-08-27 17:43 ` mark at klomp dot org
3 siblings, 0 replies; 5+ messages in thread
From: amerey at redhat dot com @ 2021-06-25 18:59 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27917
Aaron Merey <amerey at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amerey at redhat dot com
--- Comment #1 from Aaron Merey <amerey at redhat dot com> ---
Commit ab38d167c40c99 causes federation loops for non-existent resources to
result in multiple temporary livelocks, each lasting for $DEBUGINFOD_TIMEOUT
seconds. Since concurrent requests for each unique resource are now serialized,
federation loops can result in one server thread waiting to acquire a lock
while the server thread holding the lock waits for the first thread to respond
to an http request.
An implementation for this PR should help protect against this behaviour. Ex.
if --forwarded-ttl-limit=0 then the timeout behaviour of local loops should be
avoided.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug debuginfod/27917] protect against federation loops
2021-05-26 17:48 [Bug debuginfod/27917] New: protect against federation loops fche at redhat dot com
2021-06-08 14:13 ` [Bug debuginfod/27917] " dichen at redhat dot com
2021-06-25 18:59 ` amerey at redhat dot com
@ 2021-08-26 3:04 ` dichen at redhat dot com
2021-08-27 17:43 ` mark at klomp dot org
3 siblings, 0 replies; 5+ messages in thread
From: dichen at redhat dot com @ 2021-08-26 3:04 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27917
--- Comment #2 from Di Chen <dichen at redhat dot com> ---
Created attachment 13623
--> https://sourceware.org/bugzilla/attachment.cgi?id=13623&action=edit
Submit a Patch for Bug 27917
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug debuginfod/27917] protect against federation loops
2021-05-26 17:48 [Bug debuginfod/27917] New: protect against federation loops fche at redhat dot com
` (2 preceding siblings ...)
2021-08-26 3:04 ` dichen at redhat dot com
@ 2021-08-27 17:43 ` mark at klomp dot org
3 siblings, 0 replies; 5+ messages in thread
From: mark at klomp dot org @ 2021-08-27 17:43 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27917
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
CC| |mark at klomp dot org
Status|NEW |RESOLVED
--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
commit d3f914023abcd6ae76b168da97518e5e7dbd761a
Author: Di Chen <dichen@redhat.com>
Date: Fri Aug 20 13:03:21 2021 +0800
debuginfod: PR27917 - protect against federation loops
If someone misconfigures a debuginfod federation to have loops, and
a nonexistent buildid lookup is attempted, bad things will happen,
as is documented.
This patch aims to reduce the risk by adding an option to debuginfod
that functions kind of like an IP packet's TTL: a limit on the length of
XFF: header that debuginfod is willing to process. If X-Forwarded-For:
exceeds N hops, it will not delegate a local lookup miss to upstream
debuginfods.
Commit ab38d167c40c99 causes federation loops for non-existent resources
to result in multiple temporary deadlocks, each lasting for
$DEBUGINFOD_TIMEOUT seconds. Since concurrent requests for each unique
resource are now serialized, federation loops can result in one server
thread waiting to acquire a lock while the server thread holding the
lock waits for the first thread to respond to an http request.
This PR can help protect against the above multiple temporary deadlocks
behaviour. Ex. if --forwarded-ttl-limit=0 then the timeout behaviour of
local loops should be avoided.
https://sourceware.org/bugzilla/show_bug.cgi?id=27917
Signed-off-by: Di Chen <dichen@redhat.com>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-08-27 17:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-26 17:48 [Bug debuginfod/27917] New: protect against federation loops fche at redhat dot com
2021-06-08 14:13 ` [Bug debuginfod/27917] " dichen at redhat dot com
2021-06-25 18:59 ` amerey at redhat dot com
2021-08-26 3:04 ` dichen at redhat dot com
2021-08-27 17:43 ` mark at klomp dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).