utf-8

Bonjour,

Antoine Leca wrote:

Ce qui me fait penser à un autre problème de UTF-8 (qui a été beaucoup
«exploité»), qui sont les faux encodages : exemple (utilisé par Java),
"xC0x80" «représente» la même chose que "", mais bien sûr n'a pas
les mêmes propriétés ; autres exemples, "xC0xAExC0xAExC0xAF"
représente "../", ce qui permet de passer à travers les répertoires,

J'avoue ne pas bien comprendre comment le fait de mal encoder un nom de
répertoire permet de contourner les protections du système d'exploitation.
Pourriez-vous éclairer ma lanterne (oui je suis un cracker en puissance :-))
?

Cordialement

Dominique

Bonjour,

Le 09/02/2015 07:59, Dominique MICOLLET a écrit :

Antoine Leca wrote:

Ce qui me fait penser à un autre problème de UTF-8 (qui a été beaucoup
«exploité»), qui sont les faux encodages : exemple (utilisé par Java),
"xC0x80" «représente» la même chose que "", mais bien sûr n'a pas
les mêmes propriétés ; autres exemples, "xC0xAExC0xAExC0xAF"
représente "../", ce qui permet de passer à travers les répertoires,

J'avoue ne pas bien comprendre comment le fait de mal encoder un nom de
répertoire permet de contourner les protections du système d'exploitation.
Pourriez-vous éclairer ma lanterne (oui je suis un cracker en puissance :-))
?

Par exemple, voici ce que peut faire un programme avant d'accéder à un
fichier dont le nom est passé en paramètre :

1) il vérifie que le chemin ne commence pas par « / » ou « .. » pour
éviter d'aller lire /etc/passwd ou ../../../../etc/passwd
2) ceci étant vérifié, il accède au fichier en toute confiance.

Mais si un « . » ou un « / » a été encodé en plusieurs caractères
en UTF-8, le test (1) passera, alors que le fichier accédé pourrait
bien être /etc/passwd malgré tout une fois traduit d'UTF-8 en le
charset par défaut du programme.

Le 09/02/2015 07:59, Dominique MICOLLET écrivit :

Antoine Leca wrote:

Ce qui me fait penser à un autre problème de UTF-8 (qui a été beaucoup
«exploité»), qui sont les faux encodages : exemple (utilisé par Java),
"xC0x80" «représente» la même chose que "", mais bien sûr n'a pas
les mêmes propriétés ; autres exemples, "xC0xAExC0xAExC0xAF"
représente "../", ce qui permet de passer à travers les répertoires,

J'avoue ne pas bien comprendre comment le fait de mal encoder un nom de
répertoire permet de contourner les protections du système d'exploitation.

Suppose que ton programme est un processus serveur (service, ou démon en
argot Unix), qui tourne en permanence avec des privilèges élevés
(administrateur, SECurityOFficeR, root, LocalSystem, ou même utilisateur
dédié avec des droits ou des quotas supérieurs à ceux des utilisateurs
normaux). Il reçoit des informations qui sont en fait des noms de
fichiers, dont ton programme va se servir pour ouvrir des fichiers ou
des ressources ; dans l'organisation classique des systèmes
d'exploitations, ce nom peut être séparé en morceaux, souvent appelés
répertoires. De plus, dans les organisations inspirées d'Unix, le nom
spécial .. désigne le répertoire parent. Normalement, ce genre de
programme doit valider les noms des fichiers avec les droits effectifs
du client qui effectue la requête. Certains programmes font cela en
utilisant les primitives du système qui sont disponibles à cet effet,
mais malheureusement leur utilisation est trop souvent complexe pour un
programme qui agit au nom d'un utilisateur (impersonation en anglais)
aussi bon nombre de programmeurs ont réécrit leur propre version, mieux
adaptée à leur propre besoin... mais qui pouvait avoir ses propres
bogues. Un exemple typique de personnalisation est le fait de changer de
majuscules à minuscules ou vice-versa ; un autre exemple est de changer
d'encodage pour les noms de fichiers ; et dans ce cas particulier, la
recommandation classique vers 2000 était de tout recoder en Unicode, le
« jeu de caractères universel ».
Ensuite, le fait d'utiliser UTF-8 pour les noms de fichiers a permis à
des petits malins de contourner la validation des noms de fichiers quand
elle ne prenait pas en compte ces faux encodages, et de rendre visible
des informations confidentielles.

Maintenant, le problème n'est pas limité aux processus serveur. Si le
dit processus serveur fait appel à un autre programme « normal » de la
machine (par exemple un script shell ou javascript ou autre, ou un
simple programme écrit en C, ou un plug-in ou une DLL lié
dynamiquement), ce dernier devient lui aussi privilégié ; et donc sujet
aux mêmes problèmes... parfois sans être conscient qu'il puisse être
utilisé pour le compte d'un «client» qui a des privilèges distincts de
ceux disponibles pour le processus en cours.


Antoine

Ca suppose bien sur que tu aies un filesystem avec "full-support" pour UTF8.

En ce qui me concerne, ca me parait evident qu'il *ne faut pas* un full-support
pour ce genre de choses. Quoi que tu fasses avec un nom de fichier, la seule
facon de representer le repertoire courant *doit* etre l'ascii ., le repertoire
parent .., et le / pour separer les repertoires.

Note pour ma paroisse: il y a bien peut-etre une raison pour laquelle OpenBSD
avance tres tres lentement en ce qui concerne le support UTF-8 dans le systeme
de base... typiquement, mieux vaut avoir un systeme vieux mais sans faille
qu'un systeme tout neuf mais rempli de trous.

Oui, on a tout le support wide-chars dans la bibliotheque de base. On n'a
pas encore tout concernant les locale ET les threads. Encore un joli bordel
qui a ete tres mal pense, et on n'a pas non plus les bouts de locale en
rapport avec localedef et consorts... en gros tout ce qui necessite de charger
du code dynamiquement avance a pas de fourmis, histoire d'eviter de se
retrouver avec des enormes trous aussi stupides que le gethostbyname() de la
glibc.

Le 09/02/2015 12:16, Marc Espie écrivit :

Ca suppose bien sur que tu aies un filesystem avec "full-support" pour UTF8.

Euh, non. Au contraire, en fait (sauf du point de vue très particulier
de celui qui écrit le système d'exploitation ;-) ).

Si le système de fichier (et le système d'exploitation en général) est
capable de manipuler sans souci des noms de fichiers en UTF-8, les
programmes peuvent se permettre de laisse faire le système, et par
conséquent ne sont pas obligé de manipuler les noms de fichiers, et donc
ne font pas de conversion (plus exactement, ne devraient pas faire de
conversion). Pas de possibilité d'erreur dans la jungle des programmes
des utilisateurs, seul le système doit être surveillé.
C'est d'ailleurs l'état que cherche à atteindre l'IETF : que les
problèmes d'encodage disparaissent des programmes des utilisateurs.

Mais on en est pas encore là.
D'une part parce qu'il y de nombreux programmes (et programmeurs) qui
continuent à penser qu'ils doivent faire eux-même le travail du système,
ici décoder des noms de fichiers.
Et d'autre part parce que les systèmes ne sont pas encore, et de loin,
capables de proposer un environnement totalement Unicode : entre les
machines ou les disques qui tournent en EBCDIC et autres horreurs
antédiluviennes, les interfaces ligne de commande genre Windows XP qui
ne comprennent que les encodages simple caractère, et les raisons liées
à la nature même d'Unicode (comme les problèmes des caractères
apparemment ambigu comme "A" écrit "xD0x90" ou "xCEx91"), on trouve
plein de raisons pour que les programmeurs système aient encore du pain
sur la planche.

En ce qui me concerne, ca me parait evident qu'il *ne faut pas* un full-support
pour ce genre de choses. Quoi que tu fasses avec un nom de fichier, la seule
facon de representer le repertoire courant *doit* etre l'ascii ., le repertoire
parent .., et le / pour separer les repertoires.

Ça, c'est l'argument de la portabilité. Avant Unicode, cet argument
permettait d'interdire les accents et les autres alphabets que le latin.
Parce que si on ouvrait la boîte de Pandore, il n'était pas possible de
gérer le résultat. Note bien que l'argument vaut aussi bien pour les
noms de fichiers, les claviers, les messages rfc822 ou Usenet, les
identificateurs en programmation, ou les noms des commandes.

Ce que change avec Unicode, c'est qu'on a une solution qui semble
permettre de surmonter l'écueil.

Note pour ma paroisse: il y a bien peut-etre une raison pour laquelle OpenBSD
avance tres tres lentement en ce qui concerne le support UTF-8 dans le systeme
de base... typiquement, mieux vaut avoir un systeme vieux mais sans faille
qu'un systeme tout neuf mais rempli de trous.

Oui, c'est ce que j'ai écrit ci-dessus. De plus, avec des ressources
limitées il faut faire de choix, ce qui impose de ne pas suivre la
dernière technologie à la mode, surtout lorsque c'est casse-gueule et
donc susceptible de se révéler être une technologie cul-de-sac.

en gros tout ce qui necessite de charger du code dynamiquement avance a pas
de fourmis,

Tout-à-fait d'accord : je trouve extrêmement dommage que dans MINIX, les
services du système utilisent maintenant l'allocation dynamique ;
certains me disent que c'est le progrès, moi j'ai surtout l'impression
qu'il s'agit d'une facilité pour ne pas avoir à dimensionner. Un peu
comme la «solution» en BTP qui consiste à multiplier par trois les
résultat des calculs d'efforts, « par sécurité ».


Antoine

On 02/07/2015 01:55 PM, Marc Espie a dit:

In article <mb4at5$str$1@uind.cispeo.fr>, tth <me@ici.invalid> wrote:

On 02/06/2015 01:56 PM, Antoine Leca a dit:

Ce qui me fait penser � un autre probl�me de UTF-8 (qui a �t� beaucoup
�exploit�), qui sont les faux encodages : exemple (utilis� par Java),
"xC0x80" �repr�sente� la m�me chose que "", mais bien s�r n'a pas
les m�mes propri�t�s ; autres exemples, "xC0xAExC0xAExC0xAF"
repr�sente "../", ce qui permet de passer � travers les r�pertoires,

Voil�, c'est � ce genre de pi�ge que je pensais quand je parlais
d'un guide des bonnes mani�res.

Ben je pense que du coup, tu as largement de quoi faire et te faire peur...

OMFG ! C'est la bérézina du charset !

Content-Type: text/plain; charset=windows-1252; format=flowed

Mais comment se fait-il que mon Tbird choisisse cet encodage ?
Peut-être pour s'adapter à une réponse précédente ?

Hop, xpost+foutou


--
------ https://my.smeuh.org/ ------