Vulnerability in Mint Nanny and mint updater?

Contribute code & patches
Forum rules
No support questions here please

Vulnerability in Mint Nanny and mint updater?

Postby gorfou on Wed Nov 09, 2011 6:09 pm

Hi all!

A friend of mine forwarded me a post (french) indicating that there might be a vulnerability in mint nanny and mint update, leading to a possible attack on LMDE. I searched for it on the forum and found nothing, so here is an excerpt, and a translation.

En dehors d'avoir un code python déplorable utilisant os.system allégrement ( os.system('cat toto') ) et des variables globales de temps en temps, de ne pas connaître setuptool, ce code a aussi souvent la fâcheuse manie de tourner en root assez souvent.
Je ne vais pas détailler tout ce qui ne va pas ( mais je conseille de lire le code de
ce programme ) et je vais directement aller à
l'essentiel.
En fait, c'est toujours le même souci qui revient, l'incapacité à utiliser proprement /tmp ( voir même, l'incapacité à voir qu'il faut utiliser autre chose comme mécanisme de RPC ).
Le premier exemple que j'ai trouvé, c'est dans mintNanny, un programme de gestion parentale.
Derrière une idée pompeuse se cache un simple éditeur de fichier /etc/hosts. Le souci, c'est que
le développeur ne connaît visiblement pas augeas ni mêmes les bases concernant les bonnes pratiques pour la création de fichier temporaire, ou plus prosaïquement, l'usage propre de sed.
Regardons le code à la ligne 78. On voit une fonction qui se charge de retirer une ligne de /etc/hosts avec sed, en passant par un fichier temporaire du nom de /tmp/hosts.mintNanny, et qui copie à nouveau ce fichier sur /etc/hosts.
Alors bien sur, le premier souci est le coté non atomique de la modification, vu qu'il y a un temps
entre le sed et le cp. Le deuxième souci est un bug du à l'usage de motif trop larges ( ie, il manque
des \b ), mais n'est pas grave. Le 3eme souci est aussi de ne pas vérifier le retour des opérations, et la présence du fichier. On peut ainsi facilement injecter ce qu'on veut dans /etc/hosts.
C'est gênant, mais le plus gros problème, c'est bien de lancer sed en root en redirigeant la sortie dans un fichier. Pour le fun, je propose de tenter de faire :
ln -s /etc/pam.d/common-session /tmp/mintNanny

et de lancer l'outil de gestion des domaines ( Administration / Domain Blocker ) en rajoutant et en retirant des domaines. Surprise garanti au prochain démarrage.
Alors ok, ça arrive, c'est une erreur bête, sauf que c'est pas la seule.
Prenons un autre exemple, l'outil de gestion des mises à jour du nom de mintUpdate. Regardons
la ligne 1444. On voit donc la déclaration d'un répertoire puis un appel à "chmod a+rwx" sur ce répertoire. Chose amusante :
$ mkdir test_1 ; ls -ld test_1 ; ln -s test_1 test_2 ; chmod a+rwx test_2 ; ls -ld test_1
drwxrwxr-x. 2 misc misc 4096 5 nov. 22:58 test_1
drwxrwxrwx. 2 misc misc 4096 5 nov. 22:58 test_1

On peut donc faire changer les permissions d'un répertoire arbitraire sur le système. Faisons le
test, prenons /etc/pam.d. Lançons donc :
ln -s /etc/pam.d/ /tmp/mintUpdate/

Et attendons que quelqu'un lance mintupdate. Comme j'ai pas trouvé le moindre utilisateur pour tester, je me suis retrouvé obligé de faire le test moi même. Et c'est à ce moment la que je suis retrouvé fort marri, car il se trouve que depuis la version 10.10 d'Ubuntu, Kees Cook a rajouté un LSM nommé Yama qui rajoute justement une protection contre ce genre d'attaque comme indiqué sur le wiki d'Ubuntu.
Mais, et c'est la que c'est drôle, le patch a été envoyé pour inclusion dans le kernel mais il a été
refusé tel quel plusieurs fois. Il a d'abord été refusé tel quel pour diverses raisons comme compliqué et non élégant puis il a été refusé pour
cause de controverse sur l'usage de plusieurs LSM. Ce qui veut dire que Debian n'utilise pas ce patch, car il est contraire à leur politique d'intégration de modification du noyau. Hors, il se trouve que Linux Mint a une version basé sur Debian. Donc, on peut supposer que la version Debian est vulnérable à la faille. Une faille qui, si je ne me trompe pas, permet de piéger en douce un système pour donner un droit d'écriture pour tous sur un répertoire de son choix, juste avec un accès ssh et du temps.


And the translation (forgive (and pm to correct) me about any translation mistake):

Outside having wretched python code that uses os.system joyfully ( os.system('cat toto') ) and global variables from time to time, not knowing setuptool, that code also has the unfortunate habit of running as root quite often.
I won't go into the details of everything not correct (but i advise you to read the code of this program) to get straight to the point.
In fact, it's the same problem that arises: the incapacity to cleanly use /tmp (even further, the incapacity to see the need to use something else as RPC mechanism).
The first example I found is in mintNanny, a parental control software.
Behind that grand idea hides a simple editor of the /etc/hosts file. The problem is that the developer obviously knows augeas nor the basis of good practices to create temporary files, or, put it simply, the clean use of sed.

Let's have a peek at the code at line 78. We see a functions which deals with removing a line from /etc/hosts with sed, passing by a temporary file named /tmp/hosts.mintNanny, and which copies again that file over /etc/hosts.

The first worry is thus clearly the non-atomic character of the modification, due to the time between the sed and the cp.
The second worry is a bug due to the use of too wide pattern (i.e. it lacks \b 's), but it's not severe.
The third worry is also not verifying the return values of the operations, and the presence of the file. That way, we can easily inject arbitrary data in /etc/hosts.

It's inconvenient, but the worst problem is in fact running sed as root and redirecting the output in a file. For the fun, I propose the following experiment:
ln -s /etc/pam.d/common-session /tmp/mintNanny

followed by the launch of the domain manager tool ( Administration / Domain Blocker ) by adding and deleting domains. Surprise is guaranteed at next boot.
Ok, it happens, it's a stupid mistake, but it's not the only one.

Let's take another example: the update tool, mintUpdate. Looking at line 1444, we see the creation of a repertory then a call to "chmod a+rwx" on that directory. Amusing thing:

$ mkdir test_1 ; ls -ld test_1 ; ln -s test_1 test_2 ; chmod a+rwx test_2 ; ls -ld test_1
drwxrwxr-x. 2 misc misc 4096 5 nov. 22:58 test_1
drwxrwxrwx. 2 misc misc 4096 5 nov. 22:58 test_1

We can thus modify the permissions of an arbitrary directory on the system. We can test it with /etc/pam.d . We run:
ln -s /etc/pam.d/ /tmp/mintUpdate/

And let us wait that a user launch mintupdate. Since I was the only user around, i did the test myself. And that's the point were I found myself unlucky, because since Ubuntu version 10.10, Kees Cook added a LSM named Yama that adds a protection against that kind of attacks, as indicated on Ubuntu's wiki.

But, and it's where it bites, the patch was sent for inclusion in the kernel, but it was refused as is multiple times. It was first refused as is for different reasons as "complicated" or "non-elegant", then for controversial in the use of multiple LSM. This implies that Debian doesn't use the patch, because it's against their policy about kernel modification.

And it just happens Linux has a Debian-based version. We can thus guess that the Debian version is vulnerable. A vulnerability that, if I'm not wrong, can silently trap a system to give write permissions for everyone on an arbitrary directory, with just a ssh connection and time.


Note: and LMDE is indeed vulnerable. doing this in /tmp works:
super tmp # mkdir important_root_dir
super tmp # chmod 700 important_root_dir/
super tmp # exit
gorfou@super /tmp $ ls -ld important_root_dir/
drwx------ 2 root root 4096 Nov 9 23:01 important_root_dir/
gorfou@super /tmp $ ln -s important_root_dir mintUpdate
gorfou@super /tmp $ ls -ld important_root_dir/
drwxrwxrwx 2 root root 4096 Nov 9 23:06 important_root_dir/


Additionnal note: I do this so that my preferred distribution gets better. Hope it helps.

gorfou
gorfou
Level 1
Level 1
 
Posts: 20
Joined: Wed Dec 02, 2009 5:27 pm

Linux Mint is funded by ads and donations.
 

Re: Vulnerability in Mint Nanny and mint updater?

Postby proxima_centauri on Thu Nov 10, 2011 6:20 pm

Any contributions with github concerning issues with mintNanny or mintUpdate code would be much appreciated and will help getting this bug fixed.

https://github.com/linuxmint
User avatar
proxima_centauri
Level 11
Level 11
 
Posts: 3976
Joined: Tue Dec 25, 2007 3:24 pm
Location: NB, Canada


Return to Code & Patches

Who is online

Users browsing this forum: No registered users and 0 guests