From the tree - to the surface: how, why and what to do?
Based on real events.
Imagine that you have a large project for which you need to collect software. And you also have the desire to stir up the assembly farm, on which your subordinates will collect the necessary software. And it all happens under Linux, and everyone needs to create a “clean” environment with minimum costs. How to do it?
Several people raised their hands in the hall and exclaimed “chroot!”. You agreed that it is simple, fast, and everyone gets the full resources of the host machine. All applauded, the decision was made.
')
And a week after the integration of this solution and after the dismissal of the employee “X”, you wake up - and on the server is a pristine clean hard disk. The villain has destroyed the work of developers, the work got up.
Why did he manage to delete everything if he was in a “protected” “locked” chrut?
The whole point is that the villain could put in a program. Or simply possessed in root rights.
Let's start from afar. In Linux, in addition to real file systems, there are virtual ones. One of these systems is / proc / - the kernel information file system. For example, the command
will show us the contents of the config file with which the loaded kernel was going. There is a lot of information in this file system, and it is almost always needed when you collect something under Linux. Appropriately - it was mounted in the chroot in which our warrior was sitting. And since chroot does not involve loading your own kernel - it was mounted from the host system by a command like
and, importantly, it also contains information about the host system!
In / proc, there are folders of the form / proc / $ pid / cwd, in which you can see the contents of the folder that is current for this process (and for the current process there is also a shortcut / proc / self / pid). There are such folders for all running processes, including for init.
What is the current folder for init? Right, /! And since init is a host for us, the task of “getting up” comes down to doing
and rubbing pens: voila, we're outside! Further freedom of action is limited only by the fantasy of exploiting vulnerability.
Imagine that you have a large project for which you need to collect software. And you also have the desire to stir up the assembly farm, on which your subordinates will collect the necessary software. And it all happens under Linux, and everyone needs to create a “clean” environment with minimum costs. How to do it?
Several people raised their hands in the hall and exclaimed “chroot!”. You agreed that it is simple, fast, and everyone gets the full resources of the host machine. All applauded, the decision was made.
')
And a week after the integration of this solution and after the dismissal of the employee “X”, you wake up - and on the server is a pristine clean hard disk. The villain has destroyed the work of developers, the work got up.
Why did he manage to delete everything if he was in a “protected” “locked” chrut?
The whole point is that the villain could put in a program. Or simply possessed in root rights.
Let's start from afar. In Linux, in addition to real file systems, there are virtual ones. One of these systems is / proc / - the kernel information file system. For example, the command
$ zcat /proc/config.gz
will show us the contents of the config file with which the loaded kernel was going. There is a lot of information in this file system, and it is almost always needed when you collect something under Linux. Appropriately - it was mounted in the chroot in which our warrior was sitting. And since chroot does not involve loading your own kernel - it was mounted from the host system by a command like
mount -t proc proc /mnt/chrootme/proc/
and, importantly, it also contains information about the host system!
In / proc, there are folders of the form / proc / $ pid / cwd, in which you can see the contents of the folder that is current for this process (and for the current process there is also a shortcut / proc / self / pid). There are such folders for all running processes, including for init.
What is the current folder for init? Right, /! And since init is a host for us, the task of “getting up” comes down to doing
# chroot /proc/1/cwd/
and rubbing pens: voila, we're outside! Further freedom of action is limited only by the fantasy of exploiting vulnerability.
How not to get into this situation?
- Never give chroot surroundings to strangers!
- Use virtualization to build assembly farms. Slowly, but safe (and with svm / vtx technology - and not slowly).
- Do not give root (or at least the slightest opportunity to get it) in chroot, even to those you trust.
Source: https://habr.com/ru/post/141012/
All Articles