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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
