Report Bug to Linux File System about fs/devpts

Report Bug to Linux File System about fs/devpts

[杨男子]

Hi, our team has found a problem in fs system on Linux kernel v5.10, leading to DoS attacks.

The pseudo-terminals can be opened by normal user can be exhausted by one singal normal user by calling syscall such as open. A normal user keeps opening/dev/ptmx to trigger ptmx_open, which calls devpts_new_index and increases pty_count. In a couple of seconds, the pty_count limit is reached, and other normal user’s ptmx_open operations fail.

In fact, we try this attack inside a deprivileged docker container without any capabilities. The processes in the docker can exhaust all normal user’s pseudo-terminals on the host kernel. We use a machine with 16G memory. We start 4 processes to open /dev/ptmx repeatedly. In total, around 3072 number of pseudo-terminals are consumed and other normal user can not use pseudo-terminals. 

The consequences are severe as pty devices are widely used by various applications such as SSH connection. As a result, all SSH connection attempts to any other container will fail due to the failed pseudo-terminal-open. Even worse, the host-machine cannot start any new containers, as the connections to a new container are denied due to the same error.

The following code shows a PoC that takes 3072 number of pseudo-terminals, while other normal user can not use pseudo-terminals. We evaluate the PoC on intel i5 CPU physical machine + Linux kernel v5.10.0 + Ubuntu 18.04 LTS + Docker 18.06.0-ce.
-----------------------------------------------
#include<stdio.h>
#define _XOPEN_SOURCE
#include<stdlib.h>
#include<unistd.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<sys/ioctl.h>

int main(){
    for(int j=0;j<=4;j++){
        int pid = fork();
        if(pid == 0){
            for(int i=0;;i++){
                int mfd = open("/dev/ptmx",O_RDWR);
            }
            sleep(1000);
        }
    }

    sleep(10000);
    return 0;
}
-----------------------------------------------

Looking forward to your reply!
                                                                                                                             Nanzi Yang

Re: Report Bug to Linux File System about fs/devpts

[Greg KH]

On Sun, Sep 05, 2021 at 02:31:06PM +0800, 杨男子 wrote:
> Hi, our team has found a problem in fs system on Linux kernel v5.10, leading to DoS attacks.
> 
> The pseudo-terminals can be opened by normal user can be exhausted by one singal normal user by calling syscall such as open. A normal user keeps opening/dev/ptmx to trigger ptmx_open, which calls devpts_new_index and increases pty_count. In a couple of seconds, the pty_count limit is reached, and other normal user’s ptmx_open operations fail.
> 
> In fact, we try this attack inside a deprivileged docker container without any capabilities. The processes in the docker can exhaust all normal user’s pseudo-terminals on the host kernel. We use a machine with 16G memory. We start 4 processes to open /dev/ptmx repeatedly. In total, around 3072 number of pseudo-terminals are consumed and other normal user can not use pseudo-terminals. 

If you are concerned about this, please restrict the kernel.pty.max
value to be much lower.  Otherwise, do not run untrusted code in a
container and expect it to not be able to use up system resources :)

All of these "reports" you sent out today, seem to imply that you feel
that containers should never be allowed to take up resources from things
in other containers or elsewhere on the system.  As has been pointed
out, that is possible, but you need to tune your system to keep that
from happening by using one of the many various resource limit "knobs"
that are available to you.

These are not kernel bugs, but rather system configuration issues in
userspace from what I can determine.

thanks,

greg k-h

Re: Report Bug to Linux File System about fs/devpts

[Theodore Ts'o]

On Sun, Sep 05, 2021 at 07:20:01PM +0200, Greg KH wrote:
> If you are concerned about this, please restrict the kernel.pty.max
> value to be much lower.

The kernel.pty.max value specifies the global maximum limit.  So I
believe the point solution to *this* particular container resource
limit is to mount separate instances of /dev/pts in each container
chroot with the mount option max=NUM, instead of bind-mounting the
top-level /dev/pts into each container chroot.

And <whack> we can use the rubber mallet to hit one more mole in the
whack-a-mole game.  :-)

Or you can just assume that all of the containers are cooperatively
trying to share the OS resources, and if there is a malicious
container, it can be handled out-of-band by non-technical means (e.g.,
by having the Site Reliability Engineer tracking down owner of said
malicious container, and then talking to their manager to tell them
not to do that particular anti-social thing, docking the owner's
social credit account, etc.).

	   	       	      	 	       - Ted

Re: Report Bug to Linux File System about fs/devpts

[Christian Brauner]

On Sun, Sep 05, 2021 at 09:36:56PM -0400, Theodore Ts'o wrote:
> On Sun, Sep 05, 2021 at 07:20:01PM +0200, Greg KH wrote:
> > If you are concerned about this, please restrict the kernel.pty.max
> > value to be much lower.
> 
> The kernel.pty.max value specifies the global maximum limit.  So I
> believe the point solution to *this* particular container resource
> limit is to mount separate instances of /dev/pts in each container
> chroot with the mount option max=NUM, instead of bind-mounting the
> top-level /dev/pts into each container chroot.

Yes, this is literally the standard.

But also, this is a problem for which you don't need any containers. Any
unprivileged user on the host can open as many pty devices as they want
as /dev/ptmx is openable by unprivileged user on every distro. It gets
worse obviously if you set max=1024 on the host obivously as you can
quickly exceed this. But most systems mount devtps without restrictions.
If you're sharing your host's devpts instance then that's a
misconfiguration.

Christian