Ignore LD_POINTER_GUARD for set-user-ID/set-group-ID binaries.

  Hello,

A weakness in the dynamic loader have been found, Glibc prior to
2.22.90 are affected. The issue is that the LD_POINTER_GUARD in the
environment is not sanitized allowing local attackers easily to bypass
the pointer guarding protection on set-user-ID and set-group-ID
programs. 

Details of the weakness:
http://hmarco.org/bugs/glibc_ptr_mangle_weakness.html

This patch prevents to disable the pointer guarding protection for
set-user-ID/set-group-ID programs.

For example, executing "LD_POINTER_GUARD=0 /bin/ping" does not disable
the pointer guarding protection unless it is directly executed by root
(rUID==eUID).


Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es>
Signed-off-by: Ismael Ripoll Ripoll <iripoll@upv.es>
---
 ChangeLog                   | 11 +++++++++++
 elf/rtld.c                  |  3 ++-
 sysdeps/generic/unsecvars.h |  1 +
 3 files changed, 14 insertions(+), 1 deletion(-)
  

I think this merits a bug report in Bugzilla (and corresponding [BZ #N] 
notation in the ChangeLog entry, and inclusion in the list of fixed bugs 
in NEWS when committing the fix).
  

Hello,

The CVE assignment has changed, and now I don't know who is in charge of 
  assigning CVE. A few months ago we requested CVEs (for a different 
topic) to mitre and we got no answer.


Does anyone know anything about it?


On 05/09/15 19:28, Joseph Myers wrote:
> I think this merits a bug report in Bugzilla (and corresponding [BZ #N]
> notation in the ChangeLog entry, and inclusion in the list of fixed bugs
> in NEWS when committing the fix).
>


Hector.
  

* Hector Marco-Gisbert:

> The CVE assignment has changed, and now I don't know who is in charge
> of assigning CVE. A few months ago we requested CVEs (for a different
> topic) to mitre and we got no answer.

You reported the issue publicly to oss-security.  At this point, only
MITRE can assign CVE IDs.

Fortunately, a CVE ID is not required for fixing this bug in glibc.
We'll need a bug report, though.  If you cannot file one yourself,
let us know, and we'll take care of it.
  

On Sun, Sep 6, 2015 at 9:42 AM, Florian Weimer <fw@deneb.enyo.de> wrote:

> We'll need a bug report, though.  If you cannot file one yourself,
> let us know, and we'll take care of it.

https://sourceware.org/bugzilla/show_bug.cgi?id=18928
  

On 09/05/2015 06:39 PM, Hector Marco-Gisbert wrote:
> A weakness in the dynamic loader have been found, Glibc prior to
> 2.22.90 are affected. The issue is that the LD_POINTER_GUARD in the
> environment is not sanitized allowing local attackers easily to bypass
> the pointer guarding protection on set-user-ID and set-group-ID
> programs. 
> 
> Details of the weakness:
> http://hmarco.org/bugs/glibc_ptr_mangle_weakness.html
> 
> This patch prevents to disable the pointer guarding protection for
> set-user-ID/set-group-ID programs.
> 
> For example, executing "LD_POINTER_GUARD=0 /bin/ping" does not disable
> the pointer guarding protection unless it is directly executed by root
> (rUID==eUID).

Does anyone actually use LD_POINTER_GUARD for debugging?  Maybe we can
simply retire the environment variable instead.

Florian
  

On 10/08/2015 04:44 AM, Florian Weimer wrote:
> On 09/05/2015 06:39 PM, Hector Marco-Gisbert wrote:
>> A weakness in the dynamic loader have been found, Glibc prior to
>> 2.22.90 are affected. The issue is that the LD_POINTER_GUARD in the
>> environment is not sanitized allowing local attackers easily to bypass
>> the pointer guarding protection on set-user-ID and set-group-ID
>> programs. 
>>
>> Details of the weakness:
>> http://hmarco.org/bugs/glibc_ptr_mangle_weakness.html
>>
>> This patch prevents to disable the pointer guarding protection for
>> set-user-ID/set-group-ID programs.
>>
>> For example, executing "LD_POINTER_GUARD=0 /bin/ping" does not disable
>> the pointer guarding protection unless it is directly executed by root
>> (rUID==eUID).
> 
> Does anyone actually use LD_POINTER_GUARD for debugging?  Maybe we can
> simply retire the environment variable instead.

I vote we remove it. It has long since passed the point of usefullness.
With a proper tunables infrastructure we would have added it in one release
while we tested things, and then removed it one or two releases later.

Cheers,
Carlos.
  

On 09 Oct 2015 21:59, Carlos O'Donell wrote:
> On 10/08/2015 04:44 AM, Florian Weimer wrote:
> > On 09/05/2015 06:39 PM, Hector Marco-Gisbert wrote:
> >> A weakness in the dynamic loader have been found, Glibc prior to
> >> 2.22.90 are affected. The issue is that the LD_POINTER_GUARD in the
> >> environment is not sanitized allowing local attackers easily to bypass
> >> the pointer guarding protection on set-user-ID and set-group-ID
> >> programs. 
> >>
> >> Details of the weakness:
> >> http://hmarco.org/bugs/glibc_ptr_mangle_weakness.html
> >>
> >> This patch prevents to disable the pointer guarding protection for
> >> set-user-ID/set-group-ID programs.
> >>
> >> For example, executing "LD_POINTER_GUARD=0 /bin/ping" does not disable
> >> the pointer guarding protection unless it is directly executed by root
> >> (rUID==eUID).
> > 
> > Does anyone actually use LD_POINTER_GUARD for debugging?  Maybe we can
> > simply retire the environment variable instead.
> 
> I vote we remove it. It has long since passed the point of usefullness.
> With a proper tunables infrastructure we would have added it in one release
> while we tested things, and then removed it one or two releases later.

sounds fine to me.  punt it and be done.
-mike
  

I see your point. Unless the "rol" asm operation is also "removed" from mangling 
I cannot see any utility of disabling pointer guard when debugging.
So, let's remove it.


-- Hector.


El 11/10/15 a las 02:10, Mike Frysinger escribió:
> On 09 Oct 2015 21:59, Carlos O'Donell wrote:
>> On 10/08/2015 04:44 AM, Florian Weimer wrote:
>>> On 09/05/2015 06:39 PM, Hector Marco-Gisbert wrote:
>>>> A weakness in the dynamic loader have been found, Glibc prior to
>>>> 2.22.90 are affected. The issue is that the LD_POINTER_GUARD in the
>>>> environment is not sanitized allowing local attackers easily to bypass
>>>> the pointer guarding protection on set-user-ID and set-group-ID
>>>> programs.
>>>>
>>>> Details of the weakness:
>>>> http://hmarco.org/bugs/glibc_ptr_mangle_weakness.html
>>>>
>>>> This patch prevents to disable the pointer guarding protection for
>>>> set-user-ID/set-group-ID programs.
>>>>
>>>> For example, executing "LD_POINTER_GUARD=0 /bin/ping" does not disable
>>>> the pointer guarding protection unless it is directly executed by root
>>>> (rUID==eUID).
>>>
>>> Does anyone actually use LD_POINTER_GUARD for debugging?  Maybe we can
>>> simply retire the environment variable instead.
>>
>> I vote we remove it. It has long since passed the point of usefullness.
>> With a proper tunables infrastructure we would have added it in one
>> release while we tested things, and then removed it one or two releases
>> later.
>
> sounds fine to me.  punt it and be done. -mike
>
  

Hello all,

It would be nice if our names (Hector Marco and Ismael Ripoll) appear in the 
Changelog. At least showing that we reported the security issue.

Previously reported security issues (i.e BZ #15754) were properly credited in 
the Glibc Changelog.

Regarding security issues, the complexity relies on finding the issue rather 
than fixing it, which typically consists on adding or removing a few lines of code.

Developers that want contribute maybe discourage if their work is not recognized.


-- Hector Marco.


El 10/10/15 a las 03:59, Carlos O'Donell escribió:
> On 10/08/2015 04:44 AM, Florian Weimer wrote:
>> On 09/05/2015 06:39 PM, Hector Marco-Gisbert wrote:
>>> A weakness in the dynamic loader have been found, Glibc prior to
>>> 2.22.90 are affected. The issue is that the LD_POINTER_GUARD in the
>>> environment is not sanitized allowing local attackers easily to bypass
>>> the pointer guarding protection on set-user-ID and set-group-ID
>>> programs.
>>>
>>> Details of the weakness:
>>> http://hmarco.org/bugs/glibc_ptr_mangle_weakness.html
>>>
>>> This patch prevents to disable the pointer guarding protection for
>>> set-user-ID/set-group-ID programs.
>>>
>>> For example, executing "LD_POINTER_GUARD=0 /bin/ping" does not disable
>>> the pointer guarding protection unless it is directly executed by root
>>> (rUID==eUID).
>>
>> Does anyone actually use LD_POINTER_GUARD for debugging?  Maybe we can
>> simply retire the environment variable instead.
>
> I vote we remove it. It has long since passed the point of usefullness.
> With a proper tunables infrastructure we would have added it in one release
> while we tested things, and then removed it one or two releases later.
>
> Cheers,
> Carlos.
>
  

On 10/16/2015 04:51 PM, Hector Marco-Gisbert wrote:
> Hello all,
> 
> It would be nice if our names (Hector Marco and Ismael Ripoll) appear in
> the Changelog. At least showing that we reported the security issue.
> 
> Previously reported security issues (i.e BZ #15754) were properly
> credited in the Glibc Changelog.

In my opinion, this was a mistake, we should credit only reporters which
follow the established disclosure procedures.

If you found a vulnerability which is sufficiently significant, in your
opinion, to deserve credits and a CVE identifier, you should make at
least one attempt to report it privately first.  We do not want to keep
things secret, but the pain of CVE assignment *after* public disclosure
means that we currently need private vulnerability reports to arrange
for CVE assignment.

Florian
  

1.- We think that the issue is not critical => Not need to report it privately. 
It is not exploitable by itself.

2.- We informed at the same time: to the oss-list, Glibc maintainers and MITRE 
with full description including a PoC and patch which fixes it.

3.- We completely agree to remove the buggy code rather than to fix it.

4.- The CVE can be assigned or not, it depends on many factors, we don't care 
that much. But it is obvious that our contribution have been used to improve the 
security of the Glibc, and then it must be properly credited.

We follow in our work serious and responsible disclosures of all the issues that 
we found. BTW: It is strange that the authorship depends on how the issue is 
disclosed.

It is no easy to follow exactly the protocols defined by each different project, 
even more when MITRE, and projects are changing their rules very often. We did 
our best ! Again, we think this is not a critical issue.


Regards,
Hector and Ismael.


El 16/10/15 a las 17:23, Florian Weimer escribió:
> On 10/16/2015 04:51 PM, Hector Marco-Gisbert wrote:
>> Hello all,
>>
>> It would be nice if our names (Hector Marco and Ismael Ripoll) appear in
>> the Changelog. At least showing that we reported the security issue.
>>
>> Previously reported security issues (i.e BZ #15754) were properly
>> credited in the Glibc Changelog.
>
> In my opinion, this was a mistake, we should credit only reporters which
> follow the established disclosure procedures.
>
> If you found a vulnerability which is sufficiently significant, in your
> opinion, to deserve credits and a CVE identifier, you should make at
> least one attempt to report it privately first.  We do not want to keep
> things secret, but the pain of CVE assignment *after* public disclosure
> means that we currently need private vulnerability reports to arrange
> for CVE assignment.
>
> Florian
>
  

On Mon, 19 Oct 2015, Hector Marco-Gisbert wrote:

> 4.- The CVE can be assigned or not, it depends on many factors, we don't care
> that much. But it is obvious that our contribution have been used to improve
> the security of the Glibc, and then it must be properly credited.

Isn't the normal credit for a bug reported in public (whether or not a 
security bug): the bug number is referenced in the ChangeLog and the 
commit message, and anyone can follow that reference back to see who 
reported the bug?  I would hope that databases of CVEs would also point 
directly to the bug report in Bugzilla, not just the commit fixing the 
bug.
  

On 19 Oct 2015 16:48, Joseph Myers wrote:
> On Mon, 19 Oct 2015, Hector Marco-Gisbert wrote:
> > 4.- The CVE can be assigned or not, it depends on many factors, we don't care
> > that much. But it is obvious that our contribution have been used to improve
> > the security of the Glibc, and then it must be properly credited.
> 
> Isn't the normal credit for a bug reported in public (whether or not a 
> security bug): the bug number is referenced in the ChangeLog and the 
> commit message, and anyone can follow that reference back to see who 
> reported the bug?  I would hope that databases of CVEs would also point 
> directly to the bug report in Bugzilla, not just the commit fixing the 
> bug.

yeah, the name in the ChangeLog is used for showing who made the change,
not who reported the issue.  if the older entries mentioned reporters,
then that was a mistake.  the commit message / bug is where details like
the reporter go.

https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
-mike
  

On 10/16/2015 11:23 AM, Florian Weimer wrote:
> On 10/16/2015 04:51 PM, Hector Marco-Gisbert wrote:
>> Hello all,
>>
>> It would be nice if our names (Hector Marco and Ismael Ripoll) appear in
>> the Changelog. At least showing that we reported the security issue.
>>
>> Previously reported security issues (i.e BZ #15754) were properly
>> credited in the Glibc Changelog.
> 
> In my opinion, this was a mistake, we should credit only reporters which
> follow the established disclosure procedures.
> 
> If you found a vulnerability which is sufficiently significant, in your
> opinion, to deserve credits and a CVE identifier, you should make at
> least one attempt to report it privately first.  We do not want to keep
> things secret, but the pain of CVE assignment *after* public disclosure
> means that we currently need private vulnerability reports to arrange
> for CVE assignment.

I think this is slightly different from the notion you are used to in
the realm of security where the discovery of the vulnerability is widely
credited to some single source.

Regardless of the security impact of the bug the patch and the idea came
from Hector.

You should do either multi-author if the code is based on Hector's patch:

2013-09-23  Hector Marco  <hecmargi@upv.es>
            Ismael Ripoll  <iripoll@disca.upv.es>
            Carlos O'Donell  <carlos@redhat.com>

	...

or you should thank Hector for the bug report via `Reported by`:

2008-05-21  Ulrich Drepper  <drepper@redhat.com>

        * locales/iso14651_t1_common: Remove U0C0D entry added for Telugu.
        Reported by Pravin Satpute.

This has nothing to do with the security relevant attribution.

Cheers,
Carlos.
  

El 20/10/15 a las 01:25, Carlos O'Donell escribió:
> On 10/16/2015 11:23 AM, Florian Weimer wrote:
>> On 10/16/2015 04:51 PM, Hector Marco-Gisbert wrote:
>>> Hello all,
>>>
>>> It would be nice if our names (Hector Marco and Ismael Ripoll) appear in
>>> the Changelog. At least showing that we reported the security issue.
>>>
>>> Previously reported security issues (i.e BZ #15754) were properly
>>> credited in the Glibc Changelog.
>>
>> In my opinion, this was a mistake, we should credit only reporters which
>> follow the established disclosure procedures.
>>
>> If you found a vulnerability which is sufficiently significant, in your
>> opinion, to deserve credits and a CVE identifier, you should make at
>> least one attempt to report it privately first.  We do not want to keep
>> things secret, but the pain of CVE assignment *after* public disclosure
>> means that we currently need private vulnerability reports to arrange
>> for CVE assignment.
>
> I think this is slightly different from the notion you are used to in
> the realm of security where the discovery of the vulnerability is widely
> credited to some single source.
>
> Regardless of the security impact of the bug the patch and the idea came
> from Hector.
>
> You should do either multi-author if the code is based on Hector's patch:
>
> 2013-09-23  Hector Marco  <hecmargi@upv.es>
>              Ismael Ripoll  <iripoll@disca.upv.es>
>              Carlos O'Donell  <carlos@redhat.com>
>
> 	...
>
> or you should thank Hector for the bug report via `Reported by`:
>
> 2008-05-21  Ulrich Drepper  <drepper@redhat.com>
>
>          * locales/iso14651_t1_common: Remove U0C0D entry added for Telugu.
>          Reported by Pravin Satpute.
>
> This has nothing to do with the security relevant attribution.
>
> Cheers,
> Carlos.
>
>
>

Obviously we agree with Carlos, in fact the Linux Kernel development follows 
somewhat similar to what Carlos explains.

We think that a good handling of credits can make a difference in the community 
that help to support the project. Moving the credits to a third party (outside 
of the source code tree) jeopardize the responsibility or authorship because it 
is harder to track it.

Avoiding the use of "Reported by" or add "multi-author" forces to anyone who 
wants to track the issue to go to the external party, analyze the issue entry 
and figure out if the contribution is a bug report (Reported by), patch 
contribution (multi-author) or whatever.


Regards,
Hector & Ismael.
  

On 10/21/2015 07:12 AM, Hector Marco-Gisbert wrote:
>> I think this is slightly different from the notion you are used to
>> in the realm of security where the discovery of the vulnerability
>> is widely credited to some single source.
>> 
>> Regardless of the security impact of the bug the patch and the idea
>> came from Hector.
>> 
>> You should do either multi-author if the code is based on Hector's
>> patch:
>> 
>> 2013-09-23  Hector Marco  <hecmargi@upv.es> Ismael Ripoll
>> <iripoll@disca.upv.es> Carlos O'Donell  <carlos@redhat.com>
>> 
>> ...
>> 
>> or you should thank Hector for the bug report via `Reported by`:
>> 
>> 2008-05-21  Ulrich Drepper  <drepper@redhat.com>
>> 
>> * locales/iso14651_t1_common: Remove U0C0D entry added for Telugu. 
>> Reported by Pravin Satpute.
>> 
>> This has nothing to do with the security relevant attribution.
> 
> Obviously we agree with Carlos, in fact the Linux Kernel development
> follows somewhat similar to what Carlos explains.
> 
> We think that a good handling of credits can make a difference in the
> community that help to support the project. Moving the credits to a
> third party (outside of the source code tree) jeopardize the
> responsibility or authorship because it is harder to track it.
> 
> Avoiding the use of "Reported by" or add "multi-author" forces to
> anyone who wants to track the issue to go to the external party,
> analyze the issue entry and figure out if the contribution is a bug
> report (Reported by), patch contribution (multi-author) or whatever.

Ultimately it is up to the committer for the project to make the
decision if they feel that multi-author or reported by is the context
appropriate form to use.

Florian did nothing wrong and I do not wish to impinge on his autonomy
as a project developer. My goal was to clarify that security bug 
attributions are distinct from code-level attributions.

Regarding security issues I have proposed some changes to help
clarify when the project will provide attribution and how:

https://www.sourceware.org/ml/libc-alpha/2015-10/msg00768.html

Cheers,
Carlos.
  

El 22/10/15 a las 04:55, Carlos O'Donell escribió:
> On 10/21/2015 07:12 AM, Hector Marco-Gisbert wrote:
>>> I think this is slightly different from the notion you are used to
>>> in the realm of security where the discovery of the vulnerability
>>> is widely credited to some single source.
>>>
>>> Regardless of the security impact of the bug the patch and the idea
>>> came from Hector.
>>>
>>> You should do either multi-author if the code is based on Hector's
>>> patch:
>>>
>>> 2013-09-23  Hector Marco  <hecmargi@upv.es> Ismael Ripoll
>>> <iripoll@disca.upv.es> Carlos O'Donell  <carlos@redhat.com>
>>>
>>> ...
>>>
>>> or you should thank Hector for the bug report via `Reported by`:
>>>
>>> 2008-05-21  Ulrich Drepper  <drepper@redhat.com>
>>>
>>> * locales/iso14651_t1_common: Remove U0C0D entry added for Telugu.
>>> Reported by Pravin Satpute.
>>>
>>> This has nothing to do with the security relevant attribution.
>>
>> Obviously we agree with Carlos, in fact the Linux Kernel development
>> follows somewhat similar to what Carlos explains.
>>
>> We think that a good handling of credits can make a difference in the
>> community that help to support the project. Moving the credits to a
>> third party (outside of the source code tree) jeopardize the
>> responsibility or authorship because it is harder to track it.
>>
>> Avoiding the use of "Reported by" or add "multi-author" forces to
>> anyone who wants to track the issue to go to the external party,
>> analyze the issue entry and figure out if the contribution is a bug
>> report (Reported by), patch contribution (multi-author) or whatever.
>
> Ultimately it is up to the committer for the project to make the
> decision if they feel that multi-author or reported by is the context
> appropriate form to use.
>
> Florian did nothing wrong and I do not wish to impinge on his autonomy
> as a project developer. My goal was to clarify that security bug
> attributions are distinct from code-level attributions.
>
> Regarding security issues I have proposed some changes to help
> clarify when the project will provide attribution and how:
>
> https://www.sourceware.org/ml/libc-alpha/2015-10/msg00768.html
>
> Cheers,
> Carlos.
>

Sorry for the delayed response (I defended my PhD. last week).

I think it is a great idea, this kind of initiatives will encourage people to 
make contributions.

Would it be possible to update the corresponding files to reflect our contribution ?


Cheers,
Hector.