Annonce : faille de sécurité sur luatex

Bonjour à toutes et tous,

Nous nous permettons de relayer une annonce de faille de sécurité sur
LuaTeX :

Tout document compilé avec les versions 1.04-1.16.1 de LuaTeX peut exécuter
des commandes shell arbitraires, et cela même si l’option -shell-escape est
désactivée. Cela affecte les versions qui étaient incluses dans TeX Live
2017-2022 ainsi que dans la version originale de TeX Live 2023

Ce problème a été corrigé dans LuaTeX version 1.17.0 qui s’installe lors
des mises à jour de TeX Live 2023.

Les formats (Plain TeX, LaTeX, etc.) ne sont pas en cause mais dès lors
qu’ils sont utilisés avec le moteur LuaTeX, alors la vulnérabilité est
présente.

Un fichier de test est présent sur le site du TUG ci-dessus. Si vous avez
des questions ou des problèmes, n’hésitez pas à demander de l’aide sur la
présente liste ou à écrire à xyz@xyz.tld.

N’hésitez donc pas à mettre votre distribution à jour !

Bonne soirée,

Maxime pour le bureau de l’association GUTenberg


Maxime Chupin
Site personnel : Parabolicae | Accueil
Site professionnel : Maxime Chupin | Accueil
http://www.ceremade.dauphine.fr/~chupin/
adresse libre : xyz@xyz.tld

Merci beaucoup pour l’info !

Bonne soirée,

Thomas Savary
1 le Grand-Plessis
F-85340 L’Île-d’Olonne
Tél. Tél. masqué

Le lundi 22 mai 2023, 21:45:08 CEST Maxime Chupin a écrit :

Bonjour à toutes et tous,

Nous nous permettons de relayer une annonce de faille de sécurité sur
LuaTeX :
LuaTeX Security Vulnerabilities  — Max Chernoff

Tout document compilé avec les versions 1.04-1.16.1 de LuaTeX peut
exécuter des commandes shell arbitraires, et cela même si l’option
-shell-escape est désactivée. Cela affecte les versions qui étaient
incluses dans TeX Live 2017-2022 ainsi que dans la version originale
de TeX Live 2023

Ce problème a été corrigé dans LuaTeX version 1.17.0 qui s’installe
lors des mises à jour de TeX Live 2023.

Les formats (Plain TeX, LaTeX, etc.) ne sont pas en cause mais dès
lors qu’ils sont utilisés avec le moteur LuaTeX, alors la
vulnérabilité est présente.

Un fichier de test est présent sur le site du TUG ci-dessus. Si vous
avez des questions ou des problèmes, n’hésitez pas à demander de
l’aide sur la présente liste ou à écrire à
xyz@xyz.tld.

N’hésitez donc pas à mettre votre distribution à jour !

Bonne soirée,

Maxime pour le bureau de l’association GUTenberg

Bonsoir et mille mercis.

J’apprends que je suis sauvé des eaux.
Ceci dit, il faudra qu’on fasse des progrès en matière de comm.

Parce que la page LuaTeX Security Vulnerabilities  — Max Chernoff

est bigrement réservée aux initiés
Sourires et bonne soirée
Eric

Empty body

Le Mon, May 22, 2023 at 09:45:08PM +0200, Maxime Chupin a crit :

Bonjour toutes et tous,

Nous nous permettons de relayer une annonce de faille de scurit sur
LuaTeX :
LuaTeX Security Vulnerabilities  — Max Chernoff

Tout document compil avec les versions 1.04-1.16.1 de LuaTeX peut excuter
des commandes shell arbitraires, et cela mme si l?option -shell-escape est
dsactive. Cela affecte les versions qui taient incluses dans TeX Live
2017-2022 ainsi que dans la version originale de TeX Live 2023

Ce problme a t corrig dans LuaTeX version 1.17.0 qui s?installe lors
des mises jour de TeX Live 2023.

Les formats (Plain TeX, LaTeX, etc.) ne sont pas en cause mais ds lors
qu?ils sont utiliss avec le moteur LuaTeX, alors la vulnrabilit est
prsente.

Un fichier de test est prsent sur le site du TUG ci-dessus. Si vous avez
des questions ou des problmes, n?hsitez pas demander de l?aide sur la
prsente liste ou crire xyz@xyz.tld.

N?hsitez donc pas mettre votre distribution jour !

Je me permets de signaler que le moteur Prote de kerTeX, qui n’est
l’instar de e-TeX, qu’un fichier d’extension sur TeX (enfin : TeX +
e-TeX), permet d’interprter LaTeX, et qu’il ne souffre pas de ce genre
de choses (j’ai, par principe, cart tout ce qui pouvait faire un appel
en C system(3)).

noter galement que certaines versions de dvips(1) permettaient aussi
d’incorporer des squences (backtick) pour lancer des appels au systme
(c’tait prvu l’origine pour appeler des programmes transformant des
images incluses qui n’taient pas dans un format directement support
par dvips(1)). Tout cela a aussi t supprim dans la version kerTeX.

Tout ce qui crit dans le systme de fichiers est implment par le code
ajout qui est limit au strict minimum et est donc facilement
inspectable (dans le rpertoire lib1/ pour tout ce qui est du C
normalis, et dans sys/ pour ce qui dpend de choses qui ne sont pas
dans le C normalis — une primitive requise par LaTeX ncessite
POSIX.1 ; le rendu graphique de METAFONT ncessite un systme 2D —
c’est X11 pour les systmes de base Unix ; il faut que je termine Rio
pour Plan9 et que j’ajoute GDI pour Windows).

Enfin, de manire gnrale, il faut se mfier de tout ce qui est compil
l’extrieur. Voir :

RT linker, rpath and security

    Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
                http://kertex.kergis.com/

Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

Le 22/05/2023 à 21:45, Maxime Chupin a écrit :

Bonjour à toutes et tous,

Bonjour,

Nous nous permettons de relayer une annonce de faille de sécurité sur
LuaTeX :
LuaTeX Security Vulnerabilities  — Max Chernoff https://tug.org/~mseven/luatex.html

Tout document compilé avec les versions 1.04-1.16.1 de LuaTeX peut
exécuter des commandes shell arbitraires, et cela même si l’option
-shell-escape est désactivée. Cela affecte les versions qui étaient
incluses dans TeX Live 2017-2022 ainsi que dans la version originale de
TeX Live 2023

Ce problème a été corrigé dans LuaTeX version 1.17.0 qui s’installe lors
des mises à jour de TeX Live 2023.

Les formats (Plain TeX, LaTeX, etc.) ne sont pas en cause mais dès lors
qu’ils sont utilisés avec le moteur LuaTeX, alors la vulnérabilité est
présente.

Un fichier de test est présent sur le site du TUG ci-dessus. Si vous
avez des questions ou des problèmes, n’hésitez pas à demander de l’aide
sur la présente liste ou à écrire à xyz@xyz.tld
mailto:xyz@xyz.tld.

N’hésitez donc pas à mettre votre distribution à jour !

Même après cette correction, ne croyez pas pour autant que luatex (ou
lualatex) devient sans risque. Un document LaTeX (malicieux) compilé via
luatex peut écrire/modifier n’importer quel fichier appartenant à
l’utilisateur. C’est donc la porte ouverte à n’importe quel piratage
(exactement comme les macros MS Word).

L’option ‘–safer’ de luatex améliore la sécurité… mais il n’est alors
plus possible d’utiliser ‘fontspec’ !!!

Ma question posée en 2013 reste d’actualité:

<https://tex.stackexchange.com/q/100932/14500>

De ce point de vue pdftex (ou pdflatex) est un peu plus sûr puisqu’on
peut limiter son effet au répertoire courant.

Mais l’idéal pour mieux se prémunir de cela, c’est un conteneur (docker
ou podman par exemple) pour compiler les documents de sources non
contrôlées.

Cordialement,

 Paul Gaborit

Bonjour,

Le 23/05/2023 à 00:02, Paul Gaborit a écrit :

Mais l’idéal pour mieux se prémunir de cela, c’est un conteneur (docker
ou podman par exemple) pour compiler les documents de sources non
contrôlées.

C’est quoi une “source non contrôlée” ? A-t-on la certitude que ce qui
est sur CTAN soit contrôlé du point de vue sécurité ? Et si oui, quel
est le processus de contrôle ?

–Jean-Yves

Le 23 mai 2023 Paul Gaborit a écrit :

Mais l’idéal pour mieux se prémunir de cela, c’est un conteneur (docker ou
podman par exemple) pour compiler les documents de sources non contrôlées.

Sans entrer dans l’installation de docker ou autre, il suffit de se créer
un autre utilisateur dédié à ça.

Le 23/05/2023 à 08:18, Jean-Yves Baudais a écrit :

Le 23/05/2023 à 00:02, Paul Gaborit a écrit :

Mais l’idéal pour mieux se prémunir de cela, c’est un conteneur
(docker ou podman par exemple) pour compiler les documents de sources
non contrôlées.

C’est quoi une “source non contrôlée” ? A-t-on la certitude que ce qui
est sur CTAN soit contrôlé du point de vue sécurité ? Et si oui, quel
est le processus de contrôle ?

Ce qui est distribué via TeXLive, MacTeX ou MiKTeX n’est peut-être pas
spécifiquement contrôlé d’un point de vue sécurité… mais de nombreuses
personnes ont accès au code avant même qu’il soit distribué. Donc y
cacher du code permettant une attaque n’est pas simple puisqu’il risque
d’être détecté avant d’avoir atteint sa cible.

En revanche, la compilation d’un fichier reçu d’une source non contrôlée
est un bon vecteur d’attaque. Et ce vecteur permet facilement de cibler
une personne en particulier (celui à qui on soumet le document).

Cordialement,

 Paul Gaborit

Le 23/05/2023 à 09:21, Michel Verdier a écrit :

Le 23 mai 2023 Paul Gaborit a écrit :

Mais l’idéal pour mieux se prémunir de cela, c’est un conteneur (docker ou
podman par exemple) pour compiler les documents de sources non contrôlées.

Sans entrer dans l’installation de docker ou autre, il suffit de se créer
un autre utilisateur dédié à ça.

C’est toujours mieux qui rien… mais l’intérêt d’un conteneur c’est que
rien ne persiste une fois la compilation effectuée (sauf les documents
qu’on a choisi d’extraire, généralement le fichier PDF produit et
éventuellement certains fichiers annexes).

C’est comme cela que des services tels que Overleaf assure leur sécurité.

Cordialement,

 Paul Gaborit

Le 23/05/2023 à 09:14, Paul Gaborit a écrit :

Ce qui est distribué via TeXLive, MacTeX ou MiKTeX n’est peut-être pas
spécifiquement contrôlé d’un point de vue sécurité… mais de nombreuses
personnes ont accès au code avant même qu’il soit distribué. Donc y
cacher du code permettant une attaque n’est pas simple puisqu’il risque
d’être détecté avant d’avoir atteint sa cible.

Et un code genre xii.tex pour embarquer un simple “rm -Rf .” et caché
dans des milliers de ligne de code de… beamer par exemple ?

En revanche, la compilation d’un fichier reçu d’une source non contrôlée
est un bon vecteur d’attaque.

Bon, ça ne me donne toujours pas de définition d’une “source non
contrôlée”, ni contrôlée d’ailleurs… Et je ne prendrai pas pour
exemple le mail que j’ai reçu hier d’un inconnu qui me demandait de
compiler un fichier tex avec Lualatex. Trop facile :slight_smile:

Jean-Yves un peu retors

Le Tue, May 23, 2023 at 09:30:28AM +0200, Paul Gaborit a crit :

Le 23/05/2023 09:21, Michel Verdier a crit:

Le 23 mai 2023 Paul Gaborit a crit :

Mais l’idal pour mieux se prmunir de cela, c’est un conteneur (docker ou
podman par exemple) pour compiler les documents de sources non contrles.

Sans entrer dans l’installation de docker ou autre, il suffit de se crer
un autre utilisateur ddi a.

C’est toujours mieux qui rien… mais l’intrt d’un conteneur c’est que
rien ne persiste une fois la compilation effectue (sauf les documents qu’on
a choisi d’extraire, gnralement le fichier PDF produit et ventuellement
certains fichiers annexes).

C’est comme cela que des services tels que Overleaf assure leur scurit.

Il y aurait une autre possibilit, pour vrifier les fichiers, d’autant
qu’il y a des manipulations de chanes complexes (c’est quand mme
l’essentiel du traitement de TeX) qui peuvent rendre extrmement
furtives les tentatives d’attaque, c’est de modifier
lgrement le moteur TeX afin de permettre d’interdire de rcrire les
primitives, en relevant un niveau de scurit (le principe des niveaux
existent dj dans TeX d’une certaine faon).

Et il est galement possible, parce que tout ce qui n’est pas du
traitement de chanes ncessite d’appeler le code ajout, de
remplacer le code ajout par un autre qui capture les tentatives
de sortie (le mme principe que les exceptions pour un systme
d’exploitation) : plutt que de tenter de deviner ce que le code
va faire, “chopper” (“trap”) du code inconnu qui essaie de franchir
certaines limites.

Bien entendu, pour la scurit (protection contre la malveillance
volontaire), cela concerne principalement des services qui sont proposs
afin de compiler des fichiers *.tex externes.

Mais pour la sret (se protger contre les fautes involontaires ;
contre nos propres bourdes, entre autres et principalement), il y a des
mesures prendre : le code ne doit pas lire n’importe quoi n’importe o
et ne doit pas surtout pas crire n’importe quoi. Dans kerTeX, par
exemple, les fichiers crits ont toujours une extension ajoute,
dfinie (et qui est lie TeX : “.tex”, “.dvi”).

noter que dans le code non modifi de TeX (et de METAFONT : le code est
identique), il subsiste une faute dans la gestion des chemins des
fichiers qui permet justement de rcrire un fichier sans extension,
et mme d’ouvrir le mme fichier comme source TeX, comme rsultat
et comme log. En mme temps…

    Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
                http://kertex.kergis.com/

Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

Le 23 mai 2023 à 09:49, Jean-Yves Baudais xyz@xyz.tld a écrit :

Et un code genre xii.tex pour embarquer un simple “rm -Rf .” et caché dans des milliers de ligne de code de… beamer par exemple ?

Il me semble quand même que pour exécuter la commande rm, un shell-escape est nécessaire.

Michel Bovani

Le 23/05/2023 à 09:48, Jean-Yves Baudais a écrit :
[…]

Bon, ça ne me donne toujours pas de définition d’une “source non
contrôlée”, ni contrôlée d’ailleurs… Et je ne prendrai pas pour
exemple le mail que j’ai reçu hier d’un inconnu qui me demandait de
compiler un fichier tex avec Lualatex. Trop facile :slight_smile:

Choisissez le définition qui vous convient… ou qui convient au niveau
de sécurité que vous visez.

Cordialement,

 Paul Gaborit