À l'origine, au moins, le format pdf était destiné à l'impression (si je ne m'abuse ?). Que se passe-t-il en balançant un tel fichier à une imprimante ? On se retrouve avec un Linux au format papier ?
Oui mais bon. La norme PDF incorpore 4 ou 5 langages turing complete. Tu pouvais déjà incorporer des swf ou des flv et tu as un moteur JS dedans sachant que tu as évidement postscript dedans.
Nos systèmes et nos logiciels sont devenus si complexes et si puissants qu'on peut faire tourner un noyau linux sur un émulateur dans un ficher PDF !
Autant je salue la performance autant j'aimerai qu'il soit techniquement impossible de faire ça. Difficile après ça d'imaginer la surface d'attaque étendue par un "simple" lecteur PDF…
J’ai souvent dit autour de moi que c’était mal parti quand PDF a commencé à intégrer des fonctionnalités comme du JS et de la vidéo etc. J’ai su que c’est le début des ennuis quand on nous a annoncé récemment Doom…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
En même temps ça fait longtemps qu'il y a du js dans pdf, on a pas spécialement souvenir de gros problèmes par ce biais. Sachant que maintenant pour une bonne part le lecteur pdf c'est le navigateur, c'est pire que le js dans le navigateur ? Ça me semble sensiblement équivalent. En plus firefox n'implémente pas cette partie il me semble :)
Je prenais le JS comme un cas bien connu, mais mon propos était plus large (5 langages turing-complet précise un autre commentaire) : on pouvait déjà théoriquement embarquer de véritables programmes. La problématique est similaire avec le navigateur qui devient plus complexe à écrire pour sécuriser l’usage de la norme (et c’est là que je suis d’accord avec le commentaire auquel je répondais : ça n’aurait pas du être permis àmha.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Techniquement c'est pas si compliquer d’exécuter du code non sûre de manière sûre. Ce qui est compliquer c'est de donner accès à des ressources de manière sûre. Lancer un processus en lui donnant des droits extrêmement limité c'est l'histoire de quelques appels système, il y a une méthodologie simple à suivre. Donner accès à la webcam sans que ce soit une manière de sortir de la sandbox c'est ça qui est compliqué dans un navigateur (la webcam n'est qu'un exemple parmi d'autres).
Tu peux toujours utiliser postscript ou djvu par exemple, mais tu as aussi le PDF/A qui interdit les vidéos, le JS, certaines fonctionnalités des fonts, etc
Les attaques sur PDF sont vraiment vielles ont en parlait beaucoup il y a 10 ans. Je ne veux pas dire qu'il n'y en a plus mais disons que c'est connu.
Ah, je ne savais pas qu’il y avait des fonctionnalités problématiques de fontes…
En tout cas ces bien que PDF/A soit revenu aux fondamentaux tout en étant une norme pour de l’archivage : on veut à la fois du pérenne (et pas trop complexe) et sans de risque de couver une bombe…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
La problématique de la surface d'attaque très large est commune à de nombreux logiciels y compris dans des domaines « variés » : dès que tu gères de réseau et plein de protocoles réseau, des accès aux fichiers locaux, des tas de formats de fichiers, de l'exécution de code venant de l'extérieur sur des données venant de l'extérieur, etc. Bref un navigateur type Firefox, une suite bureautique type LibreOffice, un convertisseur de formats type ImageMagick, un noyau comme Linux, un analyseur de paquets comme Wireshark, un lecteur de machins audio-vidéo-animo-bidules qui fait tout et plus comme pour le PDF (ou du Flash dans les épisodes précédents). Forcément ne pas gérer de fichiers, de réseau et de données règle plein de soucis en informatique, au prix d'une certaine vacuité et inutilité, mais clairement tout mettre dans un même logiciel n'est pas une sinécure en terme de sécurité informatique.
# TinyEMU
Posté par passke (site web personnel) . Évalué à 4 (+3/-0).
Merci Fabrice Bellard.
# Impression
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 7 (+5/-0).
À l'origine, au moins, le format pdf était destiné à l'impression (si je ne m'abuse ?). Que se passe-t-il en balançant un tel fichier à une imprimante ? On se retrouve avec un Linux au format papier ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Impression
Posté par O_Leave . Évalué à 7 (+7/-0).
un manchot en origami
[^] # Re: Impression
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Oui mais bon. La norme PDF incorpore 4 ou 5 langages turing complete. Tu pouvais déjà incorporer des swf ou des flv et tu as un moteur JS dedans sachant que tu as évidement postscript dedans.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# complexité
Posté par nonas . Évalué à 10 (+10/-0).
Nos systèmes et nos logiciels sont devenus si complexes et si puissants qu'on peut faire tourner un noyau linux sur un émulateur dans un ficher PDF !
Autant je salue la performance autant j'aimerai qu'il soit techniquement impossible de faire ça. Difficile après ça d'imaginer la surface d'attaque étendue par un "simple" lecteur PDF…
[^] # Re: complexité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
J’ai souvent dit autour de moi que c’était mal parti quand PDF a commencé à intégrer des fonctionnalités comme du JS et de la vidéo etc. J’ai su que c’est le début des ennuis quand on nous a annoncé récemment Doom…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: complexité
Posté par thoasm . Évalué à 5 (+2/-0).
En même temps ça fait longtemps qu'il y a du js dans pdf, on a pas spécialement souvenir de gros problèmes par ce biais. Sachant que maintenant pour une bonne part le lecteur pdf c'est le navigateur, c'est pire que le js dans le navigateur ? Ça me semble sensiblement équivalent. En plus firefox n'implémente pas cette partie il me semble :)
[^] # Re: complexité
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Si si https://www.winastuce.com/failles-adobe-reader-desactivation-du-javascript-recommandee
https://codeanlabs.com/blog/research/cve-2024-4367-arbitrary-js-execution-in-pdf-js/
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: complexité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Je prenais le JS comme un cas bien connu, mais mon propos était plus large (5 langages turing-complet précise un autre commentaire) : on pouvait déjà théoriquement embarquer de véritables programmes. La problématique est similaire avec le navigateur qui devient plus complexe à écrire pour sécuriser l’usage de la norme (et c’est là que je suis d’accord avec le commentaire auquel je répondais : ça n’aurait pas du être permis àmha.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: complexité
Posté par David Delassus (site web personnel) . Évalué à 9 (+7/-0).
Je me demande si quelqu'un a déjà pensé a embarquer un lecteur de pdf dans un pdf.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: complexité
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Techniquement c'est pas si compliquer d’exécuter du code non sûre de manière sûre. Ce qui est compliquer c'est de donner accès à des ressources de manière sûre. Lancer un processus en lui donnant des droits extrêmement limité c'est l'histoire de quelques appels système, il y a une méthodologie simple à suivre. Donner accès à la webcam sans que ce soit une manière de sortir de la sandbox c'est ça qui est compliqué dans un navigateur (la webcam n'est qu'un exemple parmi d'autres).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: complexité
Posté par barmic 🦦 . Évalué à 7 (+5/-0).
Tu peux toujours utiliser postscript ou djvu par exemple, mais tu as aussi le PDF/A qui interdit les vidéos, le JS, certaines fonctionnalités des fonts, etc
Les attaques sur PDF sont vraiment vielles ont en parlait beaucoup il y a 10 ans. Je ne veux pas dire qu'il n'y en a plus mais disons que c'est connu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: complexité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Ah, je ne savais pas qu’il y avait des fonctionnalités problématiques de fontes…
En tout cas ces bien que PDF/A soit revenu aux fondamentaux tout en étant une norme pour de l’archivage : on veut à la fois du pérenne (et pas trop complexe) et sans de risque de couver une bombe…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: complexité
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 02 février 2025 à 10:08.
La problématique de la surface d'attaque très large est commune à de nombreux logiciels y compris dans des domaines « variés » : dès que tu gères de réseau et plein de protocoles réseau, des accès aux fichiers locaux, des tas de formats de fichiers, de l'exécution de code venant de l'extérieur sur des données venant de l'extérieur, etc. Bref un navigateur type Firefox, une suite bureautique type LibreOffice, un convertisseur de formats type ImageMagick, un noyau comme Linux, un analyseur de paquets comme Wireshark, un lecteur de machins audio-vidéo-animo-bidules qui fait tout et plus comme pour le PDF (ou du Flash dans les épisodes précédents). Forcément ne pas gérer de fichiers, de réseau et de données règle plein de soucis en informatique, au prix d'une certaine vacuité et inutilité, mais clairement tout mettre dans un même logiciel n'est pas une sinécure en terme de sécurité informatique.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.