Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to fix the CVE-2019-11244 loophole in Kubernetes. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

Background knowledge

In order to better understand this vulnerability, you need some basic knowledge about Linux file permissions.

You may often use the chmod command to set permissions for a file, such as chmod 755 xxx. Here 755 is a decimal number representing file Owner permissions, file Owner same group user rights and other user permissions, as shown in the following figure:

Under Linux, you can see the permissions of the file using the ls command, as shown in the following figure:

Setting permissions for a file is nothing more than restricting the read, write, and executable permissions of a file, so how to understand the read, write and executable permissions of a directory? According to my small survey, most people can't answer the question very well: what does it mean for a user to have read or write access to a directory?

Vulnerability description

The original description of the CVE-2019-11244 vulnerability is as follows:

In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by-- cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If-cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.

The simple understanding is that the cache files created by kubectl have permissions of rw-rw-rw-, or 666.These cache files are at risk of being modified by other users.

The other users here include two categories:

With other users under group (later referred to as group users)

Other users of different group (later called other users)

To fix this vulnerability, you need to shrink these file permissions, as long as you make sure that these files cannot be modified by these two types of users (you can have read permissions).

Community rehabilitation programme

Kubectl creates a special directory to store cache files, so here you need to control both directory permissions and file permissions.

In the community fix, the cache directory permission has been changed from 755 to 750. that is, other users will not be able to enter this directory, while Group users will still have RMIX permission, that is, they can read the list of files in the directory and enter the directory.

For the modification of the cache file, the permission has been changed from 755 to 660. There are three changes:

Owner users no longer have executable permissions (it doesn't make sense for cache files to have executable permissions)

Group users have rw- permissions, that is, Group users can still modify cache files

Other users do not grant any permissions (invalid even if they do, because the upper directory is no longer accessible)

See here, the problem is clear, cache files can still be modified by Group users, in fact, the vulnerability has not been completely fixed. We can demonstrate the actual operation. If there is no special instructions here, use root user operation:

Create a directory and set permissions to 755: # mkdir-m 0750 myPath0750

Create a file in the directory and set the permission to 660 touch myPath0750/myFile0660; chmod # 0660 myPath0750/myFile0660

Create a root group user and set the password: # useradd-G root-d / home/horen-m horen; passwd horen

Switch to the new user and try to modify the file contents: # echo "Hello" > myPath0750/myFile0660

You can find that the file can be modified.

Reinforcement scheme

Perhaps the community repair program can not meet your security requirements, you still need to do some security reinforcement based on the community solution, that is, to further shrink the permissions of cache files, from 660 to 640, that is, Group users can only view the contents of cache files at most.

In addition, because the directory permission is 750 jigger Group users do not have write permission to the directory, so the directory name cannot be modified and files cannot be created under the directory to achieve the purpose of directory-specific.

By the way, I also summarize the meaning of the three permissions of the directory: readable, writable, and executable. In fact, the directory itself is also a file, and its content is its sublayer directory structure, such as the list of files in the directory, file attributes and so on.

Readable: indicates that you can list what files are in the directory

Writable: indicates that you can create and delete files in the directory

Executable: indicates that you can enter the directory

This is the end of this article on "how to fix CVE-2019-11244 vulnerabilities in Kubernetes". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.