On Wed, Apr 21, 2021 at 11:26:10AM +0200, Björn Persson wrote:
Frank Ch. Eigler wrote:
> Björn Persson writes:
>
> > · How is it verified that files received from debuginfo servers have not
> > been tampered with?
>
> Following up further to this, we're planning to add optional client-side
> hash-verification of cached content, to provide some protection against
> tampering:
>
>
https://sourceware.org/bugzilla/show_bug.cgi?id=27758
The design you propose there won't improve anything for anyone. If the
hash is computed on the debuginfo server, then an attacker who can make
the server serve malicious debuginfo can also make it serve hashes that
match the malicious files. And as you noted yourself, an attacker who
can manipulate cached files client-side has already taken over the user
account anyway.
Quote from Sourceware Bugzilla:
> As transport over HTTPS protects the content, we can safely assume
> that immediately during/after the download, the content will be fine.
> However, what of cached files?
Of course – from your point of view. From my point of view, I can safely
assume that nobody has tampered with my cache. However, what of files on
the debuginfo server?
I see that
debuginfod.fedoraproject.org is currently another name for
koji.fedoraproject.org. Given that it serves debuginfo only for Fedora
packages, and does not forward requests to any other debuginfo servers,
using this server seems equivalent security-wise to downloading unsigned
packages from Koji.
As far as I understand, packages are built and signed on separate
servers with a smaller attack surface than the web front-end to minimize
the risk that an attacker could tamper with them. To make the debuginfo
protocol as secure as signed debuginfo packages, the client should
verify the files against a hash computed and signed on the signing
server.
Yes, this is the scenario which I think is worrisome. This was also raised
during the FESCo meeting, and I want to clarify a bit.
A hypothetical attack through -debuginfo files would require gdb (or
other consumers of the debug data) to incorrectly handle corrupt debug
data. Even if we don't know any such cases right now, gdb and the
underlying libraries are written in C. We have a long history of
buffer overflows and other exploitable memory handling errors, and we
should assume that sooner or later some will be discovered in those
code paths too.
Currently, the -debuginfo packages are distributed as any other
package, i.e. they are built and signed on dedicated machines. A
modification anywhere at a later point would cause a signature
mismatch. The trust level for -debuginfo data is the same as any other
package. A hypothetical attacker who gained access to the package contents
*before signing* would probably be better off modifying executable code in
those packages, instead of a roundabout attack through debug data.
OTOH, the debuginfo files distributed through the debuginfod server
are not signed and there is no direct way to verify that they match
the (signed) contents of the debuginfo package. Thus, the debuginfod
server becomes a juicy target. There are a few things which make it
particularly attractive to an attacker: the debugger is very likely to
be ran directly from a developer account. The debugger is executed
without any sandboxing, and possibly even with elevated privileges
(when debugging system services). The debugger code was not written
with security it mind, so it's more likely to be exploitable than say
a web browser.
As to the debuginfod code itself, it is in C++, and has SQL and
threads, a http server, and also does bunch of low-level string
parsing. It is also fairly new code. I don't have any particular
knowledge about the code, but some exploit being found is not outside
of the realm of possibility.
Thus, to summarize: debuginfo files served over the web provide a new
fairly big attack surface, with attacks most likely leading to a
compromise of a developer or privileged account.
Zbyszek
Perhaps a hash of the debuginfo could be stored in a signed RPM package,
either the main package or a separate debughash package?
For those who are concerned about privacy, the proposal would make that
problem worse as it would cause the "phoning home" to happen every time
they debug something.
By the way, the change page still doesn't say enough about how network
problems will affect the user experience. Making a previously offline
activity network-dependent also makes it sensitive to network problems.
For example, if great packet loss causes TCP timeouts or long delays,
will that make GDB hang for minutes at a time, or is it handled
asynchronously? Will GDB hang once per process, once per login session,
or every time it encounters a new source filename?
Björn Persson
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure