tag:linuxfr.org,2005:/tags/post/publicLinuxFr.org : les contenus étiquetés avec « post »2019-01-04T14:37:34+01:00/favicon.pngtag:linuxfr.org,2005:Post/397092018-12-12T18:31:42+01:002018-12-12T19:03:10+01:00comportement étrange de curl dans un script.<p>Bonjour à tous,</p>
<p>J'ai un comportement étrange dans un script shell avec la commande curl. </p>
<p>Dans mon script je génère dynamiquement les paramètres de ma commande pour obtenir la commande suivante :</p>
<pre><code class="sh"> curl -k --request POST -H <span class="s2">"type:csv"</span> -H <span class="s2">"import:fich"</span> -H <span class="s2">"zipped:true"</span> -H <span class="s2">"fichier:nbncsv00002.csv.zip"</span> -H <span class="s2">"key:JmzEVJ2EezlkfemlfmleSDKKFekv"</span> -T /tmp/tmp.QJENaDVvAV/nbncsv00002.csv.zip http://www.xxx.yyy.zzz:pppp/monappli/import <span class="m">2</span>><span class="p">&</span><span class="m">1</span>>/tmp/tmp.QJENaDVvAV/curlreturn.log</code></pre>
<p>Lors de l'exécution dans le script cette commande ne semble pas atteindre le serveur qui reçois le fichier;ça se caractérise par pas d'entrée dans les logs.</p>
<p>malgré l'affichage des infos suivantes.</p>
<pre><code class="sh"> % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
<span class="m">100</span> <span class="m">1136</span> <span class="m">100</span> <span class="m">1136</span> <span class="m">0</span> <span class="m">0</span> <span class="m">12443</span> <span class="m">0</span> --:--:-- --:--:-- --:--:-- <span class="m">12483</span></code></pre>
<p>Alors que la même ligne de commande ( qui a été générée par le script je fait un echo de la ligne générée avant de l’exécuter pour voir ) copiée dans un terminal interactif fonctionne.</p>
<p>ma version de curl est : curl 7.38.0 (x86_64-pc-linux-gnu) <br>
Si quelqu'un peut m'aider?</p>
<p>après la lecture complète du man de curl et de bash je ne voie pas quel peut être le problème.</p>
<pre><code class="sh"> curl -k --request POST <span class="si">${</span><span class="nv">headerparams</span><span class="si">}</span> <span class="si">${</span><span class="nv">fullurl</span><span class="si">}</span> <span class="m">2</span>><span class="p">&</span><span class="m">1</span>><span class="si">${</span><span class="nv">tmpfileconvdir</span><span class="si">}</span>/curlreturn.log</code></pre>
<p>Si quelqu'un peut m'aider?</p>
<div><a href="https://linuxfr.org/forums/programmation-shell/posts/comportement-etrange-de-curl-dans-un-script.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/115969/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/programmation-shell/posts/comportement-etrange-de-curl-dans-un-script#comments">ouvrir dans le navigateur</a>
</p>
Nodeushttps://linuxfr.org/nodes/115969/comments.atomtag:linuxfr.org,2005:Post/345292014-10-20T16:07:42+02:002014-10-20T16:07:42+02:00gros soucis de domaine avec samba/ldap<p>Bonjour</p>
<p>J'ai un soucis depuis 1 semaine, je planche dessus et je ne vois pas ou le probleme est:</p>
<p>J'ai donc un serveur debian 6 avec samba 3.5.6</p>
<p>Je n'ai pas eu de soucis d'authentification jusqu'à present, pas de soucis de création de compte, pas de soucis pour faire passer les windows 7 du domaine AD au domaine samba etc…</p>
<p>Bref tout était nickel, mais voila, depuis 3 semaines:</p>
<p>1/ je ne peux plus faire entrer des PC dans le domaine Samba, pourtant les PC sont bien présent dans la liste des machines enregistrées dans openldap</p>
<p>2/ Quand aux users, ils sont bien inscrits avec leur droits dans openldap/samba (id user me donne les bonnes infos), mais impossible d'ouvrir une session sous windows 7 quand le PC est dans le domaine samba et que ces users ne se sont jamais connectés sur ces PC.<br>
- Si le user c'est déja connecté sur ce PC pas de soucis par contre pour ouvrir sa session.</p>
<p>J'ai l'erreur suivante sur windows 7: aucun serveur d'accés n'est actuellement disponible pour traiter la demande d'ouverture de session.</p>
<p>Bien entendu sur le serveur d'authentification j'ai relancé les services samba, saslauthd et slapd, et vérifié ligne par ligne les fichier conf.</p>
<p>Ce soucis est apparu après une coupure de courant assez longue qui a fait que mes serveurs ont dû tous redémarrer car les onduleurs n'ont pas tenu la durée.</p>
<p>Merci pour votre aide, c'est assez urgent maintenant.</p><div><a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/gros-soucis-de-domaine-avec-samba-ldap.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/103689/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/gros-soucis-de-domaine-avec-samba-ldap#comments">ouvrir dans le navigateur</a>
</p>
Minushttps://linuxfr.org/nodes/103689/comments.atomtag:linuxfr.org,2005:News/289522011-12-30T20:42:47+01:002011-12-31T23:25:20+01:00Le colonel Moutarde, sur la table (de hachage), avec un livre de mathsLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<div><p>Quand des chercheurs en informatique font de la théorie, certains écoutent, comme les développeurs de Perl. D'autres dorment au fond de la classe : cette fois, le bonnet d'âne est pour PHP, Python, V8 (JavaScript par Google, qui sert par exemple dans node.js), Ruby (sauf CRuby), de nombreux serveurs d'applications en Java, mais aussi ASP.NET. Ils ont dû se réveiller brutalement mercredi, lors d'une <a href="http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf">présentation</a> d'Alexander Klink et Julian Wälde au Chaos Communication Congress montrant comment saturer très simplement un serveur grâce à une attaque basée sur la complexité algorithmique.</p></div><ul><li>lien nᵒ 1 : <a title="http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf" hreflang="fr" href="https://linuxfr.org/redirect/74514">Présentation d'Alexander Klink et Julian Wälde au Chaos Communication Congress [PDF, 6 Mo]</a></li></ul><div><h2 id="sommaire">Sommaire</h2>
<ul><li><a href="#toc_0">Ô ♫ mon ♬ tablo-o-o-oooooo ♩</a></li>
<li><a href="#toc_1">Un hacheur sachant hacher</a></li>
<li><a href="#toc_2">Un arrière-gout sucré</a></li>
<li><a href="#toc_3">What's in a name ?</a></li>
<li><a href="#toc_4">Savez-vous compter les trous ?</a></li>
<li><a href="#toc_5">Mais pourquoi est-il aussi méchant ?</a></li>
<li><a href="#toc_6">Dromadaire 1 – ânes 0</a></li>
<li><a href="#toc_7">Un grain de sel suffit</a></li>
<li><a href="#toc_8">En attendant…</a></li>
</ul><p>Le point commun entre tous ces logiciels : ils sont capables de recevoir par HTTP une requête accompagnée de variables et de leurs valeurs. Par exemple, lorsqu'on remplit un formulaire sur un site web, le navigateur envoie au serveur une variable nommée <strong>réponse</strong> avec la valeur <strong>42</strong>. C'est aussi ce qui sert à naviguer sur un site marchand ou un bouchot à trolls en restant identifié. Quand la requête arrive, il faut donc que chaque variable, accompagnée de sa valeur, soit disponible pour le programme qui va la traiter. Pratiquement tous les langages le font de la même façon : ils les insèrent dans une table de hachage.</p>
<h2 id="toc_0">Ô ♫ mon ♬ tablo-o-o-oooooo ♩</h2>
<p>
<em>[avertissement : ceux qui savent ce qu'est une table de hachage perdent leur temps s'ils lisent ce paragraphe. Bon, en même temps, ils sont déjà sur DLFP…]</em>
</p>
<p>Soit un langage de programmation dans lequel existent deux types de données : les nombres entiers et les chaînes de caractères. En combinant les deux, il est possible de construire un tableau dans lequel chaque case, numérotée, contient une chaîne de caractères.</p>
<p>1 → « Victorine continua sa lecture en fermant les yeux »<br />
2 → « La vache paît en paix dans ces gras pâturages »<br />
3 → « Ah ! dit don Manoel en portugais »</p>
<h2 id="toc_1">Un hacheur sachant hacher</h2>
<p>C'est pratique, mais malheureusement, les variables que l'on utilise sur des pages web sont nommées, pas numérotées. Le nom d'une variable est lui-même une chaîne de caractères. Il faudrait donc une méthode qui transforme une chaîne en entier, c'est-à-dire une fonction de hachage. Pour une chaîne c donnée, la fonction de hachage h renvoie un entier n : h(c)=n.</p>
<p>Ainsi, on a une façon bien pratique d'enregistrer les variables : on se donne une fonction de hachage et un tableau comme ci-dessus, que l'on nomme table de hachage, et on range les chaines à l'emplacement correspondant à leur image par la fonction de hachage. Par exemple, si on a une variable nommée question et contenant « six fois neuf », on calcule h(« question »)=42, et on enregistre donc la chaîne « six fois neuf » dans l'emplacement numéro 42 du tableau.</p>
<h2 id="toc_2">Un arrière-gout sucré</h2>
<p>À ce stade, le programme n'a pas encore la main. Cette étape préparatoire va servir par la suite, cachée sous une couche de sucre syntaxique. Par exemple, si le programmeur demande la valeur de POST['question'], l'environnement d'exécution va calculer h(« question »)=42 et aller chercher le contenu de la case numéro 42.</p>
<h2 id="toc_3">What's in a name ?</h2>
<p>Il y a tout de même un problème. Oh, un tout petit problème, un de ceux qui ne se posent qu'en théorie, jamais en pratique. Le nombre de seaux (« cases » du tableau) est nécessairement limité, contrairement au nombre de chaînes de caractères qu'il est possible de construire. Il existe donc forcément, pour une fonction h et une chaîne c1 données, une chaîne c2 telle que h(c1) = h(c2) = n. On dit alors que c2 est un <em>deuxième antécédent</em> de n par h, et qu'une <em>collision</em> se produit entre c1 et c2. Dans ce cas, comme une case ne peut accueillir qu'une chaîne, il faut recourir à une astuce : chaque case, en plus d'une chaîne, contient aussi l'adresse d'une nouvelle case. On peut ainsi chaîner les valeurs sans limite autre que la mémoire de la machine.</p>
<p>41 → « foo »<br />
42 → « A noir » → « E blanc » → « I rouge » → « O bleu » → « U vert » → « Voyelles »</p>
<h2 id="toc_4">Savez-vous compter les trous ?</h2>
<p>Insérer dans une case numérotée ou dans une liste chaînée, c'est la même chose. Sans doute… Sauf pour les quelques farfelus qui comptent les opérations nécessaires à l'exécution d'un programme en fonction de la taille de ses données d'entrée. C'est ce qu'on appelle la <em>complexité algorithmique</em>.</p>
<p>Dans le cas de l'insertion d'une valeur c dans une table de hachage, si on tombe toujours sur une case vide, ce nombre d'opérations ne dépend que du nombre d'opérations que va mettre la fonction de hachage pour calculer sa valeur. Pour une fonction de hachage classique, le temps d'une insertion est donc proportionnel à la longueur de c, ce que l'on note O(|c|). Comme les bonnes fonctions de hachage sont très rapides, cela ne pose pas de problème. Pour une application web, en pratique, la longueur des données à hacher sera forcément très faible, et on peut donc considérer (bouchez-vous les oreilles si un puriste est dans les environs : il va hurler) que ce temps est une constante. Pour insérer n éléments, il faut donc O(n) opérations. À la grosse louche, si l'insertion d'un élément prend 0,0000001 seconde, l'insertion de 10000 éléments prend 0,001 seconde et celle de 100000 éléments prend 0,01 seconde. Une paille.</p>
<p>En revanche, si la case choisie est toujours déjà occupée, c'est une toute autre histoire. En effet, il faut alors parcourir la liste des données insérées pour trouver la place de la nouvelle chaine, qui peut très bien être à la fin (si elles sont triées, ce qui est généralement le cas). On tombe alors dans le pire cas : l'insertion de n éléments qui ont la même image par h nécessite O(n²) opérations. Si l'insertion d'un élément prend toujours 0,0000001 seconde, l'insertion de 10 000 éléments prend désormais 10 secondes et celle de 100 000 éléments prend 1000 secondes. Il y a peu de chances que l'utilisateur soit toujours en train d'attendre, un quart d'heure après avoir envoyé ses données.</p>
<p>Heureusement, en pratique, il est très rare de tomber sur une case occupée. Les développeurs des principaux environnements d'exécution sont compétents et ont donc choisi de très bonnes fonctions de hachage, souvent issues des travaux du mathématicien américain <a href="http://cr.yp.to/djb.html">Daniel Bernstein</a>, un expert en cryptologie. Grâce à cela, il est extrêmement difficile de trouver plusieurs chaines de caractères qui ont le même antécédent. On peut donc oublier ce scénario pathologique certes, complètement théorique toutefois.</p>
<h2 id="toc_5">Mais pourquoi est-il aussi méchant ?</h2>
<p>Sauf, bien sûr, si on dispose d'une attaque contre ces fonctions de hachage. Une telle attaque est à la base des travaux de Klink et Wälde. En résumé, ils ont trouvé un moyen de fabriquer un grand nombre de chaines de caractères qui ont la même image par les fonctions de hachage utilisées par les bibliothèques des principaux langages. Ils peuvent ainsi construire une requête HTTP contenant un grand nombre de variables nommées exprès pour provoquer le scénario pathologique décrit ci-dessus : occupation à 100% du processeur dédié à cette tâche.</p>
<h2 id="toc_6">Dromadaire 1 – ânes 0</h2>
<p>Ce genre d'attaque ne date pourtant pas d'hier, du moins en théorie. Un <a href="http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf">article de Crosby et Wallach</a> paru en 2003 décrit le problème et apporte des solutions. Les développeurs de Perl ont réagi dans la foulée en modifiant légèrement leur fonction de hachage, ceux de CRuby également, et… c'est à peu près tout. Pratiquement tous les autres langages largement déployés sur des serveurs sont toujours vulnérables.</p>
<h2 id="toc_7">Un grain de sel suffit</h2>
<p>La solution est évidente : l'attaquant ne doit pas être capable de prévoir le résultat de la fonction de hachage. Comment est-ce possible si le code source des logiciels déployés est public ? Simplement en modifiant la fonction de hachage pour intégrer un élément de hasard, sur le même principe que le salage des mots de passe. En général, la méthode employée pour hacher consiste à prendre un entier valant initialement 0, puis modifier cet entier en fonction des données à hacher, caractère par caractère. Dans les versions actuelles de Perl, cet entier ne vaut plus initialement 0, mais une valeur aléatoire qui ne sort jamais de l'environnement d'exécution. Résultat : les collisions sont pratiquement impossibles à trouver, et paf l'attaque.</p>
<h2 id="toc_8">En attendant…</h2>
<p>Quelques mesures simples protègent efficacement contre ce genre d'attaque, mais il n'est pas toujours facile, voire pas toujours possible, de les mettre en place. On peut limiter la taille maximale d'une requête, mais c'est ballot si l'utilisateur est censé pouvoir envoyer beaucoup de données. Plus fin : on peut limiter le nombre maximum de variables, notamment avec Suhosin pour PHP. En tous cas, maintenant que le 25 décembre est passé, il est temps d'arrêter de croire au père Noël : le choix d'une structure de données et des fonctions associées est toujours important.</p></div><div><a href="https://linuxfr.org/news/le-colonel-moutarde-sur-la-table-de-hachage-avec-un-livre-de-maths.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/88844/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/le-colonel-moutarde-sur-la-table-de-hachage-avec-un-livre-de-maths#comments">ouvrir dans le navigateur</a>
</p>
ɹǝıʌıʃObaud123claudexBenoît Sibaudpatrick_ghttps://linuxfr.org/nodes/88844/comments.atom