Patchez vos noyaux !
Par Petaramesh le mardi 12 février 2008, 15:41 - Informatique non-duelle - Lien permanent
Un des plus "beaux" privilege escalation exploits qu'il m'ait été donnés de voir sous Linux jusqu'ici : le vmsplice local root exploit :
Quiconque exécute le programme "jess" sous un profil utilisateur ordinaire devient instantanément root. Je viens de vérifier : ça le fait effectivement, et ce jusqu'au noyau 2.6.24.2 qui vient de sortir pour contrer cet exploit.
Alors je n'ai qu'une chose à dire : Patchez vos noyaux !
Sinon, tout utilisateur "ordinaire" capable d'exécuter un programme sur votre machine peut également devenir root...
Commentaires
D'où l'intérêt, plus que jamais, de ne filer d'accès ssh qu'à des gens en qui on a entièrement confiance...
J'ai honte je viens de tester chez un pote.
Aaaaaaargh ;-))
Il n'y a pas qu'en SSH qu'on peut exécuter des binaires... un site en PHP où l'on trouve le moyen de contourner le script pour télécharger le binaire puis l'exécuter... ça le fait aussi. :-/
Je croise les doigts pour que OVH nous tienne au courant... au plus vite. :-)
Une faille qui ne concernent pas les gens (comme votre serviteur) pratiquant le downgrade puisque vmsplice() a été introduit dans le noyau depuis la version 2.6.17 :D
devenir root c'est quand on veut se teindre les cheveux c'est ça :-} ?
@krysalia : ah non, ça c'est quand on veux devenir blonde :o))
@Swami : t'as raison, tiens, je vais me patcher le noyau. Bonuitre à tous !
À l'ashram, c'est fait. Bon, ben vous avez raté l'occasion de devenir root sur Totor. C'est bête, hein ? ;-)
Sauf pour les blondes. Et quelques brunes à la rigueur, mais à titre exceptionnel. Là, le rootkit peut toujours se négocier ;-)
Mince !
Pourquoi je n'ai pas installé ce r00tk1t alors que j'était r00t il y a 2 jours ?
Encore une occassion manquée :-(
En tous cas, sur un serveur ouvert au public, il y en a des tentatives:
...
...
J'en suis à 400 oops dans ce style.
Je ne peut pas updater le kernel de cette machine donc j'utilise un workaround de fou furieux: edition de la table syscall du noyaux pour rediriger vmsplice vers rien (ce qui fait oopser le kernel) ...
@Nico : Ben dis donc, par chez toi, c'est un univers impitoyable ! ;-)
Et pourquoi ne peux-tu pas mettre le noyau à jour ? C'est une machine critique et "non-rebootable", ou un noyau vraiment très custom nécessitant ample réflexion avant bidouille ?
Fidèle lecteur, il m'arrive quelquefois de ne rien comprendre à vos billets.
Qu'importe!.
Comme dans un poème de René Char, je me laisse porter par la musique des mots et la beauté des images.
"Patchez vos noyaux", vraiment?
Il vous en faut peu pour vous émoustiller. Ce n'est pas le premier "privilege escalation" local, et ce n'est pas le dernier.
De totue façon, si vous donnez accès à des extérieurs à une machine, ils finiront root un jour ou l'autre s'ils ne se comportent pas en gens civilisés. De mon côté, je donne accès à de sinistres individus sur une machine qui fait tourner grsecurity en niveau Gentoo Hardened, et ces beaux exploitz foirent minablement -- PaX flingue le processus en annonçant suspicious global protection fault.
Je ne dis pas que ça soit blindé, mais ça réduit considérablement la fréquence des patchs urgents.
On peut même faire d'autres choses pour cantonner les sinistres individus dans le bocal qui leur est réservé:
casserole@~$ ssh -l root passoire
Last login: Wed Feb 13 15:20:28 2008 from 192.168.4.6
passoire ~ # telnet casserole
...
Linux 2.6.23-gentoo-r6 (casserole) (28)
casserole login:
telnet> q
passoire ~ # exit
casserole@~$ ssh -l guru passoire
guru@passoire ~ $ telnet casserole
telnet: socket: Permission denied
guru@passoire ~ $
Et je n'ai pas encore réactivé le RBAC, feignasse que je suis...
@Vengeur Masqué :
Certes, certes. Mais celui-là était vraiment net et sans bavures. J'en ai vu de tordus qui nécessitaient des conditions vachement particulières et marchaient au petit bonheur la chance, mais çui-là, c'était quand même un beau "
su" sans mot de passe... Enfin moi, il m'a impressionné, mais c'est parce que je suis encore jeune ;-)>
Beh, les loups ne se dévorent pas entre eux :-}
En plus, je trouve que faire un privilege escalation chez quelqu'un qui t'ouvre volontairement un accès, c'est un kolossal manque de savoir-vivre ;-)
...Surtout si ce quelqu'un a des munitions ;-))
eh eh eh grsec y a que ca de vrai !
@Danton : moi non plus, je ne comprend pas tout. Tiens, par exemple, j'ai bien essayé de me "patcher le noyau" hier soir, bin j'ai dû mal m'y prendre parce que ça m'a rudement mal, en fait. :o)))
Heu non ...
En faite, une partie de la payload a le temps de s'executer avant que PaX intervienne.
Donc tu as un kernel instable et qui crash generalement au bout de 10-15 minutes.
C'est un kernel assez particulier sur une machine trés particuliére qui necessite quelqu'un devant elle pour booter correctement.
Et puis, comme c'est devenu un serveur trés frequenté, je peut pas foutre tout le monde dehors sans préavis ...
Mon noyau n'a toujours pas crashé...
De toute façon, vu que seul root est dans le groupe "trusted path execution", il faut lui demander de bien vouloir installer l'exploit sous
/usr/local/binpour pouvoir l'exécuter.Evidemment, on peut toujours trouver un binaire système mal foutu qui appelle vmslicetrucbidule, ou tenter un "return into libc", mais ça devient coton.
Il faudrait quand même que je reconfigure ce fichu RBAC pour vraiment durcir ce système...
+1 Vengeur masqué. La gentoo hardened evite bcp de désagrements liés a la plebe des malfaisants et autres script kiddies. Mais bon, le plus simple, c'est de ne pas accepter de connexion type ssh (bon, j'admet que dans mon cas ca marche bien vu que petipentium (ma machine) est dans mon salon, et que pour un vrai admin avec de vrais serveurs dans un datacenter, c'est un mal necessaire).
Ca faisait quand meme super longtemps que j'avais pas vu aussi d'exploit aussi "straightforward".
Enfin, 1 exploit sur le kernel linux pour 200 patchs critique sous zindozs, ca reste tolerable.
@Wastedtime :
...ou de ne les accepter qu'avec authentification par paire de clés, et surtout pas par login / password.
C'est une solution. Mais elle impose de travailler sur une machine bien précise et reconnue (ou alors je me plante ? )
@Wastedtime : Cela impose seulement que les machines-cible possèdent les clés publiques autorisées à se connecter, et que celui qui veut se connecter à distance possède la clé privée correspondante - pas nécessairement sur une machine particulière, on peut très bien avoir cette clé avec soi, et elle est supposée être de surcroît protégée par mot de passe.
Pour info, j'ai testé ce matin:
while : ; do exploitz; doneMa Passoire a freezé en une seconde.
M'en fous, il reste TPE pour me protéger des invités facétieux.
Je profite de ce billet sur Linux pour vous laisser un lien vers le podcast de France Inter et plus précisément sur l'émission "Service public" du 14 fevrier 2008 concernant le monopole Microsoft.
Comme je sais votre non-dualité libre de ses pensées et tenant à ce que ses outils soient tout aussi libre, j'ai pensé de suite à vous.