Re: Security implications of debugging features

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Siddhesh Poyarekar:

> On 7/12/21 3:33 PM, Florian Weimer wrote:
>>> ~~~~~~~~~~
>>> Debugging features
>>>
>>> glibc comes with a number of debugging features that allow developers
>>> to isolate root causes of problems.  Bugs in debugging features that
>>> are enabled by explicitly compiling applications or glibc to use them
>>> are not considered security vulnerabilities and will be treated as
>>> regular bugs.  Examples of such features are mcheck and mtrace, which
>>> allow debugging and tracing of glibc malloc functions.
>>>
>>> Bugs in debugging features that are enabled by exporting an
>>> environment variable in the environment of a program may for now be
>>> considered security issues in a local context.
>>> ~~~~~~~~~~
>> I don't understand the second paragraph.
>
> What I intend to convey is that bugs in debugging features won't be
> considered remotely exploitable.

I think it's not remote vs local.  It's about whether a trust boundary
is crossed.  This happens only for AT_SECURE invocations.

>> I think we need to talk about AT_SECURE (SUID) mode in this context.
>
> Could you elaborate on what you'd like mentioned?  Would you like a
> note that the dynamic linker wipes out debugging options when running
> setuid binaries?  It seems like a security claim (there could well be
> a bug in there that negates it) and hence not suitable for this text.

Those are debugging features, too, and we will treat them as security
bugs.  So the exception should not cover them.

Thanks,
Florian