elf: Check for empty tokens before dynamic string token expansion [BZ #22625]
Commit Message
The fillin_rpath function in elf/dl-load.c loops over each RPATH or
RUNPATH tokens and intepret empty tokens as the current directory
("./"). In practice the check for empty token is done *after* the
dynamic string token expansion. The expansion process can return an
empty string for the $ORIGIN token if __libc_enable_secure is set
or if the path of the binary can not be determined (/proc not mounted).
Fix that by moving the check for empty tokens before the dynamic string
token expansion. In addition, check for NULL pointer or empty strings
return by expand_dynamic_string_token.
The above changed highlighted a bug in decompose_rpath, an empty array
is represented by the first element being NULL at the fillin_rpath path
level, but by using a -1 pointer in decompose_rpath and other functions.
Changelog:
[BZ #22625]
* elf/dl-load.c (fillin_rpath): Check for empty tokens before
dynamic string token expansion. Check for NULL pointer or empty
string possibly returned by expand_dynamic_string_token.
(decompose_rpath): Check for empty path after dynamic string
token expansion.
---
ChangeLog | 9 +++++++++
NEWS | 4 ++++
elf/dl-load.c | 30 ++++++++++++++++++++++++++----
3 files changed, 39 insertions(+), 4 deletions(-)
Comments
On Sun, Dec 17, 2017 at 06:21:49PM +0100, Aurelien Jarno wrote:
> The fillin_rpath function in elf/dl-load.c loops over each RPATH or
> RUNPATH tokens and intepret empty tokens as the current directory
> ("./"). In practice the check for empty token is done *after* the
> dynamic string token expansion. The expansion process can return an
> empty string for the $ORIGIN token if __libc_enable_secure is set
> or if the path of the binary can not be determined (/proc not mounted).
>
> Fix that by moving the check for empty tokens before the dynamic string
> token expansion. In addition, check for NULL pointer or empty strings
> return by expand_dynamic_string_token.
>
> The above changed highlighted a bug in decompose_rpath, an empty array
> is represented by the first element being NULL at the fillin_rpath path
> level, but by using a -1 pointer in decompose_rpath and other functions.
>
> Changelog:
> [BZ #22625]
> * elf/dl-load.c (fillin_rpath): Check for empty tokens before
> dynamic string token expansion. Check for NULL pointer or empty
> string possibly returned by expand_dynamic_string_token.
> (decompose_rpath): Check for empty path after dynamic string
> token expansion.
Accidentally, I was looking at this issue recently and have been testing
a slightly different patch, so I'd just share my thoughts.
> ---
> ChangeLog | 9 +++++++++
> NEWS | 4 ++++
> elf/dl-load.c | 30 ++++++++++++++++++++++++++----
> 3 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index 815e73571d..4ef438d08c 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,12 @@
> +2017-12-17 Aurelien Jarno <aurelien@aurel32.net>
> +
> + [BZ #22625]
> + * elf/dl-load.c (fillin_rpath): Check for empty tokens before
> + dynamic string token expansion. Check for NULL pointer or empty
> + string possibly returned by expand_dynamic_string_token.
> + (decompose_rpath): Check for empty path after dynamic string
> + token expansion.
> +
> 2017-12-16 Aurelien Jarno <aurelien@aurel32.net>
>
> [BZ #22505]
> diff --git a/NEWS b/NEWS
> index 0670585b4c..8099ecc8f1 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -149,6 +149,10 @@ Security related changes:
> CVE-2017-1000366 has been applied, but it is mentioned here only because
> of the CVE assignment.) Reported by Qualys.
>
> + CVE-2017-16997: Incorrect handling of RPATH or RUNPATH containing $ORIGIN
> + for AT_SECURE or SUID binaries could be used to load libraries from the
> + current directory.
> +
> The following bugs are resolved with this release:
>
> [The release manager will add the list generated by
> diff --git a/elf/dl-load.c b/elf/dl-load.c
> index bbd3be9e20..81a1a03a01 100644
> --- a/elf/dl-load.c
> +++ b/elf/dl-load.c
> @@ -433,14 +433,11 @@ fillin_rpath (char *rpath, struct r_search_path_elem **result, const char *sep,
> {
> char *cp;
> size_t nelems = 0;
> - char *to_free;
> + char *to_free = NULL;
Let's use this opportunity and move to_free inside the loop.
> while ((cp = __strsep (&rpath, sep)) != NULL)
> {
> struct r_search_path_elem *dirp;
> -
> - to_free = cp = expand_dynamic_string_token (l, cp, 1);
> -
> size_t len = strlen (cp);
>
> /* `strsep' can pass an empty string. This has to be
I think the code would be easier to read if len == 0 check below was
changed to *cp == '\0'. This way you wouldn't have to call strlen twice,
and ...
> @@ -450,6 +447,24 @@ fillin_rpath (char *rpath, struct r_search_path_elem **result, const char *sep,
> static const char curwd[] = "./";
> cp = (char *) curwd;
... an explicit len = 0 assignment would highlight the nastiness
of the trick with len later in fillin_rpath.
> }
> + else
> + {
> + to_free = cp = expand_dynamic_string_token (l, cp, 1);
> +
> + /* expand_dynamic_string_token can return NULL in case of memory
> + allocation failure. */
> + if (cp == NULL)
> + continue;
> +
> + /* Recompute the length after dynamic string token expansion
> + and ignore empty paths. */
> + len = strlen (cp);
> + if (len == 0)
> + {
> + free (to_free);
> + continue;
> + }
> + }
The alternative (that I was testing in my patch) to len == 0 check is to
change expand_dynamic_string_token to return NULL if _dl_dst_substitute
returned an empty string, e.g.
- return _dl_dst_substitute (l, s, result, is_path);
+ char *retval = _dl_dst_substitute (l, s, result, is_path);
+
+ /* If substitution of dynamic string tokens resulted to an empty string,
+ return NULL as in case of insufficient memory. */
+ if (__glibc_unlikely (*retval == '\0'))
+ {
+ free (result);
+ return NULL;
+ }
+
+ return retval;
Both users of expand_dynamic_string_token, fillin_rpath and _dl_map_object,
would be happy.
> /* Remove trailing slashes (except for "/"). */
> while (len > 1 && cp[len - 1] == '/')
> @@ -620,6 +635,13 @@ decompose_rpath (struct r_search_path_struct *sps,
> necessary. */
> free (copy);
>
> + /* There is no path after expansion. */
> + if (result[0] == NULL) {
> + free (result);
> + sps->dirs = (struct r_search_path_elem **) -1;
> + return false;
> + }
> +
> sps->dirs = result;
> /* The caller will change this value if we haven't used a real malloc. */
> sps->malloced = 1;
Yes, the bug was just sitting here and waiting for a fix in fillin_rpath
to explode.
On 2017-12-17 23:07, Dmitry V. Levin wrote:
> On Sun, Dec 17, 2017 at 06:21:49PM +0100, Aurelien Jarno wrote:
> > The fillin_rpath function in elf/dl-load.c loops over each RPATH or
> > RUNPATH tokens and intepret empty tokens as the current directory
> > ("./"). In practice the check for empty token is done *after* the
> > dynamic string token expansion. The expansion process can return an
> > empty string for the $ORIGIN token if __libc_enable_secure is set
> > or if the path of the binary can not be determined (/proc not mounted).
> >
> > Fix that by moving the check for empty tokens before the dynamic string
> > token expansion. In addition, check for NULL pointer or empty strings
> > return by expand_dynamic_string_token.
> >
> > The above changed highlighted a bug in decompose_rpath, an empty array
> > is represented by the first element being NULL at the fillin_rpath path
> > level, but by using a -1 pointer in decompose_rpath and other functions.
> >
> > Changelog:
> > [BZ #22625]
> > * elf/dl-load.c (fillin_rpath): Check for empty tokens before
> > dynamic string token expansion. Check for NULL pointer or empty
> > string possibly returned by expand_dynamic_string_token.
> > (decompose_rpath): Check for empty path after dynamic string
> > token expansion.
>
> Accidentally, I was looking at this issue recently and have been testing
> a slightly different patch, so I'd just share my thoughts.
>
> > ---
> > ChangeLog | 9 +++++++++
> > NEWS | 4 ++++
> > elf/dl-load.c | 30 ++++++++++++++++++++++++++----
> > 3 files changed, 39 insertions(+), 4 deletions(-)
> >
> > diff --git a/ChangeLog b/ChangeLog
> > index 815e73571d..4ef438d08c 100644
> > --- a/ChangeLog
> > +++ b/ChangeLog
> > @@ -1,3 +1,12 @@
> > +2017-12-17 Aurelien Jarno <aurelien@aurel32.net>
> > +
> > + [BZ #22625]
> > + * elf/dl-load.c (fillin_rpath): Check for empty tokens before
> > + dynamic string token expansion. Check for NULL pointer or empty
> > + string possibly returned by expand_dynamic_string_token.
> > + (decompose_rpath): Check for empty path after dynamic string
> > + token expansion.
> > +
> > 2017-12-16 Aurelien Jarno <aurelien@aurel32.net>
> >
> > [BZ #22505]
> > diff --git a/NEWS b/NEWS
> > index 0670585b4c..8099ecc8f1 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -149,6 +149,10 @@ Security related changes:
> > CVE-2017-1000366 has been applied, but it is mentioned here only because
> > of the CVE assignment.) Reported by Qualys.
> >
> > + CVE-2017-16997: Incorrect handling of RPATH or RUNPATH containing $ORIGIN
> > + for AT_SECURE or SUID binaries could be used to load libraries from the
> > + current directory.
> > +
> > The following bugs are resolved with this release:
> >
> > [The release manager will add the list generated by
> > diff --git a/elf/dl-load.c b/elf/dl-load.c
> > index bbd3be9e20..81a1a03a01 100644
> > --- a/elf/dl-load.c
> > +++ b/elf/dl-load.c
> > @@ -433,14 +433,11 @@ fillin_rpath (char *rpath, struct r_search_path_elem **result, const char *sep,
> > {
> > char *cp;
> > size_t nelems = 0;
> > - char *to_free;
> > + char *to_free = NULL;
>
> Let's use this opportunity and move to_free inside the loop.
Indeed. I was even wondering if we can just use cp = strdup("./") below
to get rid of to_free and limit the amount of different code paths.
> > while ((cp = __strsep (&rpath, sep)) != NULL)
> > {
> > struct r_search_path_elem *dirp;
> > -
> > - to_free = cp = expand_dynamic_string_token (l, cp, 1);
> > -
> > size_t len = strlen (cp);
> >
> > /* `strsep' can pass an empty string. This has to be
>
> I think the code would be easier to read if len == 0 check below was
> changed to *cp == '\0'. This way you wouldn't have to call strlen twice,
> and ...
>
> > @@ -450,6 +447,24 @@ fillin_rpath (char *rpath, struct r_search_path_elem **result, const char *sep,
> > static const char curwd[] = "./";
> > cp = (char *) curwd;
>
> ... an explicit len = 0 assignment would highlight the nastiness
> of the trick with len later in fillin_rpath.
Good idea indeed.
> > }
> > + else
> > + {
> > + to_free = cp = expand_dynamic_string_token (l, cp, 1);
> > +
> > + /* expand_dynamic_string_token can return NULL in case of memory
> > + allocation failure. */
> > + if (cp == NULL)
> > + continue;
> > +
> > + /* Recompute the length after dynamic string token expansion
> > + and ignore empty paths. */
> > + len = strlen (cp);
> > + if (len == 0)
> > + {
> > + free (to_free);
> > + continue;
> > + }
> > + }
>
> The alternative (that I was testing in my patch) to len == 0 check is to
> change expand_dynamic_string_token to return NULL if _dl_dst_substitute
> returned an empty string, e.g.
>
> - return _dl_dst_substitute (l, s, result, is_path);
> + char *retval = _dl_dst_substitute (l, s, result, is_path);
> +
> + /* If substitution of dynamic string tokens resulted to an empty string,
> + return NULL as in case of insufficient memory. */
> + if (__glibc_unlikely (*retval == '\0'))
> + {
> + free (result);
> + return NULL;
> + }
> +
> + return retval;
>
> Both users of expand_dynamic_string_token, fillin_rpath and _dl_map_object,
> would be happy.
I thought about that, but refrained as much as possible to change any
interface, as it might trigger more bugs, even if it looks ok.
The current bug actually show that a simple change might have big
consequences. Overall it seems the RPATH handling code became very
complex over the time, and would clearly benefit from a rewrite. I
would not be really surprised if other similar bugs are found.
All that said, if a few more persons review that code path, that should
be fine.
> > /* Remove trailing slashes (except for "/"). */
> > while (len > 1 && cp[len - 1] == '/')
> > @@ -620,6 +635,13 @@ decompose_rpath (struct r_search_path_struct *sps,
> > necessary. */
> > free (copy);
> >
> > + /* There is no path after expansion. */
> > + if (result[0] == NULL) {
> > + free (result);
> > + sps->dirs = (struct r_search_path_elem **) -1;
> > + return false;
> > + }
> > +
> > sps->dirs = result;
> > /* The caller will change this value if we haven't used a real malloc. */
> > sps->malloced = 1;
>
> Yes, the bug was just sitting here and waiting for a fix in fillin_rpath
> to explode.
Yes, however there is at least one more "continue" in fillin_rpath
which can lead to an empty path after expansion. I am surprised it
didn't trigger before today.
Thanks for the review!
On Sun, Dec 17, 2017 at 10:26:01PM +0100, Aurelien Jarno wrote:
> On 2017-12-17 23:07, Dmitry V. Levin wrote:
[...]
> > > }
> > > + else
> > > + {
> > > + to_free = cp = expand_dynamic_string_token (l, cp, 1);
> > > +
> > > + /* expand_dynamic_string_token can return NULL in case of memory
> > > + allocation failure. */
> > > + if (cp == NULL)
> > > + continue;
> > > +
> > > + /* Recompute the length after dynamic string token expansion
> > > + and ignore empty paths. */
> > > + len = strlen (cp);
> > > + if (len == 0)
> > > + {
> > > + free (to_free);
> > > + continue;
> > > + }
> > > + }
> >
> > The alternative (that I was testing in my patch) to len == 0 check is to
> > change expand_dynamic_string_token to return NULL if _dl_dst_substitute
> > returned an empty string, e.g.
> >
> > - return _dl_dst_substitute (l, s, result, is_path);
> > + char *retval = _dl_dst_substitute (l, s, result, is_path);
> > +
> > + /* If substitution of dynamic string tokens resulted to an empty string,
> > + return NULL as in case of insufficient memory. */
> > + if (__glibc_unlikely (*retval == '\0'))
> > + {
> > + free (result);
> > + return NULL;
> > + }
> > +
> > + return retval;
> >
> > Both users of expand_dynamic_string_token, fillin_rpath and _dl_map_object,
> > would be happy.
>
> I thought about that, but refrained as much as possible to change any
> interface, as it might trigger more bugs, even if it looks ok.
I agree in general, but in this particular case I've been playing
with this code for some time and think the change would be safe.
> The current bug actually show that a simple change might have big
> consequences. Overall it seems the RPATH handling code became very
> complex over the time, and would clearly benefit from a rewrite. I
> would not be really surprised if other similar bugs are found.
There are definitely more bugs in this code. For example, _dl_init_paths
calls _dl_dst_substitute twice on $LD_LIBRARY_PATH: the first time
_dl_dst_substitute is called directly, the second time the result is
passed to fillin_rpath which calls expand_dynamic_string_token which in
turn calls _dl_dst_substitute. As $LD_LIBRARY_PATH is filtered in case
of __libc_enable_secure, this doesn't look security sensitive, it just
does a wrong thing:
$ mkdir -p /tmp/'$ORIGIN' && cd /tmp/'$ORIGIN' && echo 'int main(){}' |gcc -xc - && strace -qq -E LD_LIBRARY_PATH='$ORIGIN' -e /open ./a.out
open("/tmp//tmp/$ORIGIN/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/tmp//tmp/$ORIGIN/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/tmp//tmp/$ORIGIN/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/tmp//tmp/$ORIGIN/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
@@ -1,3 +1,12 @@
+2017-12-17 Aurelien Jarno <aurelien@aurel32.net>
+
+ [BZ #22625]
+ * elf/dl-load.c (fillin_rpath): Check for empty tokens before
+ dynamic string token expansion. Check for NULL pointer or empty
+ string possibly returned by expand_dynamic_string_token.
+ (decompose_rpath): Check for empty path after dynamic string
+ token expansion.
+
2017-12-16 Aurelien Jarno <aurelien@aurel32.net>
[BZ #22505]
@@ -149,6 +149,10 @@ Security related changes:
CVE-2017-1000366 has been applied, but it is mentioned here only because
of the CVE assignment.) Reported by Qualys.
+ CVE-2017-16997: Incorrect handling of RPATH or RUNPATH containing $ORIGIN
+ for AT_SECURE or SUID binaries could be used to load libraries from the
+ current directory.
+
The following bugs are resolved with this release:
[The release manager will add the list generated by
@@ -433,14 +433,11 @@ fillin_rpath (char *rpath, struct r_search_path_elem **result, const char *sep,
{
char *cp;
size_t nelems = 0;
- char *to_free;
+ char *to_free = NULL;
while ((cp = __strsep (&rpath, sep)) != NULL)
{
struct r_search_path_elem *dirp;
-
- to_free = cp = expand_dynamic_string_token (l, cp, 1);
-
size_t len = strlen (cp);
/* `strsep' can pass an empty string. This has to be
@@ -450,6 +447,24 @@ fillin_rpath (char *rpath, struct r_search_path_elem **result, const char *sep,
static const char curwd[] = "./";
cp = (char *) curwd;
}
+ else
+ {
+ to_free = cp = expand_dynamic_string_token (l, cp, 1);
+
+ /* expand_dynamic_string_token can return NULL in case of memory
+ allocation failure. */
+ if (cp == NULL)
+ continue;
+
+ /* Recompute the length after dynamic string token expansion
+ and ignore empty paths. */
+ len = strlen (cp);
+ if (len == 0)
+ {
+ free (to_free);
+ continue;
+ }
+ }
/* Remove trailing slashes (except for "/"). */
while (len > 1 && cp[len - 1] == '/')
@@ -620,6 +635,13 @@ decompose_rpath (struct r_search_path_struct *sps,
necessary. */
free (copy);
+ /* There is no path after expansion. */
+ if (result[0] == NULL) {
+ free (result);
+ sps->dirs = (struct r_search_path_elem **) -1;
+ return false;
+ }
+
sps->dirs = result;
/* The caller will change this value if we haven't used a real malloc. */
sps->malloced = 1;