Message ID | 1441471191-4683-1-git-send-email-hecmargi@upv.es |
---|---|
State | New, archived |
Headers |
Received: (qmail 93505 invoked by alias); 5 Sep 2015 16:40:18 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 92894 invoked by uid 89); 5 Sep 2015 16:40:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=BAYES_20, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: smtpsalv.upv.es From: Hector Marco-Gisbert <hecmargi@upv.es> To: "Carlos O'Donell" <carlos@redhat.com>, GNU C Library <libc-alpha@sourceware.org>, "Joseph S. Myers" <joseph@codesourcery.com>, Siddhesh Poyarekar <siddhesh@redhat.com>, Andreas Jaeger <aj@suse.com> Cc: Hector Marco-Gisbert <hecmargi@upv.es>, Ismael Ripoll Ripoll <iripoll@upv.es> Subject: [PATCH] Ignore LD_POINTER_GUARD for set-user-ID/set-group-ID binaries. Date: Sat, 5 Sep 2015 18:39:51 +0200 Message-Id: <1441471191-4683-1-git-send-email-hecmargi@upv.es> |
Commit Message
Hector Marco-Gisbert
Sept. 5, 2015, 4:39 p.m. UTC
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(-)
Comments
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.
diff --git a/ChangeLog b/ChangeLog index 53b6c24..3c799ec 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,14 @@ +2015-08-31 Hector Marco-Gisbert <hemcargi@upv.es> + Ismael Ripoll Ripoll <iripoll@upv.es> + + * elf/rtld.c: Ignore LD_POINTER_GUARD for set-user-ID/set-group-ID + binaries. Otherwise an attacker can disable the pointer guarding + protection when attacking set-user-ID/set-group-ID binaries + locally. + * sysdeps/generic/unsecvars.h: Added LD_POINTER_GUARD environment + variable to UNSECURE_ENVVARS list to remove it from environment of + SUID binaries. + 2015-09-04 Roland McGrath <roland@hack.frob.com> [BZ #18921] diff --git a/elf/rtld.c b/elf/rtld.c index 69873c2..abdc1a2 100644 --- a/elf/rtld.c +++ b/elf/rtld.c @@ -2472,7 +2472,8 @@ process_envvars (enum mode *modep) break; } - if (memcmp (envline, "POINTER_GUARD", 13) == 0) + if (!__libc_enable_secure + && memcmp (envline, "POINTER_GUARD", 13) == 0) GLRO(dl_pointer_guard) = envline[14] != '0'; break; diff --git a/sysdeps/generic/unsecvars.h b/sysdeps/generic/unsecvars.h index d5b8119..9f1946a 100644 --- a/sysdeps/generic/unsecvars.h +++ b/sysdeps/generic/unsecvars.h @@ -11,6 +11,7 @@ "LD_DYNAMIC_WEAK\0" \ "LD_LIBRARY_PATH\0" \ "LD_ORIGIN_PATH\0" \ + "LD_POINTER_GUARD\0" \ "LD_PRELOAD\0" \ "LD_PROFILE\0" \ "LD_SHOW_AUXV\0" \