Isodumper currently creates a root owned log in users home directory ~/.isodumper/isodumper.log This is a potential security issue which can be used to overwrite system files etc. # echo "Not the real one" > /tmp/passwd $ ll /tmp/passwd -rw-r--r-- 1 root root 17 Oct 1 15:50 /tmp/passwd $ cat /tmp/passwd Not the real one $ ll .isodumper ls: cannot access .isodumper: No such file or directory $ mkdir .isodumper $ ln -s /tmp/passwd .isodumper/isodumper.log $ ll .isodumper/isodumper.log lrwxrwxrwx 1 claire claire 11 Oct 1 15:53 .isodumper/isodumper.log -> /tmp/passwd $ cat .isodumper/isodumper.log Not the real one $ isodumper # ll /tmp/passwd -rw-r--r-- 1 root root 5880 Oct 1 16:02 /tmp/passwd # head /tmp/passwd Backup in: /home/claire/SanDiskCruzerGator.iso Image: /mnt/Storage/ISOs/Mageia3/Mageia-3-dual-CD/Mageia-3-dual-CD.iso Target Device: SanDisk Cruzer Gator (/dev/sdc) 1907Mb Executing copy from /dev/sdc to /home/claire/SanDiskCruzerGator.iso Wrote: 1% 20447232 bytes Wrote: 2% 40370176 bytes Wrote: 3% 60293120 bytes Wrote: 4% 80216064 bytes Wrote: 5% 100139008 bytes Wrote: 6% 120061952 bytes Reproducible: Steps to Reproduce:
The file is actually overwritten as soon as isodumper is started.
CC: (none) => luigiwalser
Whiteboard: (none) => MGA3TOO
Sorry Daniel. Assigned incorrectly to you.
Assignee: napcok => yves.brungard_mageia
On Mageia 4 and newer, you will see that this only works if the file you're pointing at is also owned by you. If it's the real /etc/passwd owned by root (or anything else owned by someone else) the kernel has protection against this type of issue. This issue may be valid in Mageia 3, but we have an update in progress there already.
Status: NEW => RESOLVEDResolution: (none) => INVALID
The test n comment 0 was performed on Mga4.
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
# cat /proc/sys/fs/protected_symlinks 1 Do you get something different?
Ahh, your home directory doesn't have the sticky bit set, so this protection fails.
Ouch. I guess this is the next wave of security vulnerabilities. It was announced today that SDDM has the same issue.
A possible solution would be to store the log elsewhere or save it in /home with the correct attributes or a temporary mitigation may be to timestamp the log file.
See: https://bugzilla.suse.com/show_bug.cgi?id=897788 If you chown it afterward, there's a race condition. isodumper needs to drop privileges back to the user account before it creates the log or writes to it.
It's been a while since I ran it, but don't you have to put in a root password to give isodumper root privleges? Does it use polkit? I can't remember how this works.
polkit, yes.
OK, so depending on the configuration it might not require a root password, so this is still bad.
The log file is not an important feature. I can write it in /var/log. Or I can suppress it. Have you a preferred option?
CC: (none) => geiger.david68210
/var/log is the simplest solution I think, however you want to handle it though.
Hi, I have a fix, which consists in changing to group and user id before creating the directory and writing the log file. I'm waiting for David_david to package it. Papoteur
Is the vulnerability also in Mageia 3?
Blocks: (none) => 12702
Blocks: 12702 => (none)
Hi, A new patch for mga3 and mga4 is now ready for testing !! Was corrected the following issues: - Fix security issue writing log file. Updated packages in core/updates_testing: ======================== isodumper-0.23-1.1.mga3.noarch isodumper-0.23-1.2.mga4.noarch Source RPMs: isodumper-0.23-1.1.mga3.src.rpm isodumper-0.23-1.2.mga4.src.rpm
Fixed in http://advisories.mageia.org/MGAA-2014-0187.html
Status: REOPENED => RESOLVEDDepends on: (none) => 12702Resolution: (none) => FIXED