Security implications of debugging features

Security implications of debugging features

[Siddhesh Poyarekar]

Hi,

It occurred to me that our security exceptions are silent on our policy 
with debugging features.  This was specifically in the context of mcheck 
but I think it extends to other debugging features too.  mcheck is 
technically a supported glibc feature and may have been used in code 
bases for a while.  However given the lack of mcheck bugs (and boy is it 
buggy!), the latter seems to be not as common.

Given that debugging features must not be enabled in production, should 
we add the following exception for our security process?  I've kept the 
wording generic to cover any debugging features (source based or 
otherwise) that I may have missed or we end up adding in future.

~~~~~~~~~~
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.
~~~~~~~~~~

Siddhesh

Re: Security implications of debugging features

[Florian Weimer via Libc-alpha]

* Siddhesh Poyarekar:

> ~~~~~~~~~~
> 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.

I think we need to talk about AT_SECURE (SUID) mode in this context.
The general direction makes sense to me.

Thanks,
Florian

Re: Security implications of debugging features

[Siddhesh Poyarekar]

On 7/12/21 3:31 PM, Siddhesh Poyarekar wrote:
> variable in the environment of a program may for now be considered 
> security issues in a local context.

s/considered security issues/evaluated for security implications/

Re: Security implications of debugging features

[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 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.

Siddhesh

Re: Security implications of debugging features

[Florian Weimer via Libc-alpha]

* 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

Re: Security implications of debugging features

[Siddhesh Poyarekar]

On 7/12/21 3:46 PM, Florian Weimer wrote:
> * 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.

OK, then how about just the first paragraph for now?  I was trying to 
write for a future where we have a way to, say, administratively disable 
the debugging features but I guess we could add that in later.

~~~~~~~~~~
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.
~~~~~~~~~~

Re: Security implications of debugging features

[Florian Weimer via Libc-alpha]

* Siddhesh Poyarekar:

> OK, then how about just the first paragraph for now?  I was trying to
> write for a future where we have a way to, say, administratively
> disable the debugging features but I guess we could add that in later.
>
> ~~~~~~~~~~
> 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.
> ~~~~~~~~~~

It still needs to mention AT_SECURE, I think.

Thanks,
Florian

Re: Security implications of debugging features

[Siddhesh Poyarekar]

On 7/12/21 4:11 PM, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> OK, then how about just the first paragraph for now?  I was trying to
>> write for a future where we have a way to, say, administratively
>> disable the debugging features but I guess we could add that in later.
>>
>> ~~~~~~~~~~
>> 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.
>> ~~~~~~~~~~
> 
> It still needs to mention AT_SECURE, I think.

Could you suggest text that you think should get added to cover this?

Thanks,
Siddhesh