Forum Linux.debian/ubuntu Vulnérabilité = high sur maj debian 7.1 : WTF ?!

Posté par  . Licence CC By‑SA.
Étiquettes :
0
4
juil.
2013

Salut linuxFR.

Voilà je viens tous juste de migrer de squeeze vers wheezy sur mon serveur web, et voici ce que contenait le rapport des changements en début d'installation.

Il débute sympathiquement par deux grosses urgency=high et medium sur lighttpd (que j'utilise pour m'héberger … sympa).

A ce propos j'ai été obligé d'utiliser les miroirs Allemands pour l'update car sur les miroirs français je téléchargeais à quelque chose comme 5 253 B/s … et plus de 9**M/s** sur les Allemands .. (et ce n'est pas la première fois).

lighttpd (1.4.31-4) unstable; urgency=high

  The default Debian configuration file for PHP invoked from FastCGI was
  vulnerable to local symlink attacks and race conditions when an attacker
  manages to control the PHP socket file (/tmp/php.socket up to 1.4.31-3)
  before the web server started. Possibly the web server could have been
  tricked to use a forged PHP.

  The problem lies in the configuration, thus this update will fix the problem
  only if you did not modify the file /etc/lighttpd/conf-available/15-fastcgi-php.conf
   If you did, dpkg will not overwrite your changes. Please make sure to set

        "socket" => "/var/run/lighttpd/php.socket"

  yourself in that case.

 -- Arno Töll <arno@debian.org>  Thu, 14 Mar 2013 01:57:42 +0100

lighttpd (1.4.30-1) unstable; urgency=medium

  This releases includes an option to force Lighttpd to honor the cipher order
  in ssl.cipher-list. This mitigates the effects of a SSL CBC attack commonly
  referred to as "BEAST attack". See [1] and CVE-2011-3389 for more details.

  To minimze the risk of this attack it is recommended either to disable all CBC
  ciphers (beware: this will break reasonably old clients or those who support
  CBC ciphers only), or pursue clients to use safe ciphers where possible at
  least. To do so, set

  ssl.cipher-list =  "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM"
  ssl.honor-cipher-order = "enable"

  in your /etc/lighttpd/conf-available/10-ssl.conf file or on any SSL enabled
  host you configured. If you did not change this file previously, this upgrade
  will update it automatically.

  [1] http://blog.ivanristic.com/2011/10/mitigating-the-beast-attack-on-tls.html

 -- Arno Töll <debian@toell.net>  Sun, 18 Dec 2011 20:26:50 +0100

Si quelqu'un pouvait m'expliquer exactement de quoi il en retourne, je pensais que les "stables" figeaient les paquets stables longtemps en avance pour éviter ce genre de déconvenues … moi plus trop bien comprendre là.

  • # Inutile de s'alarmer, ce sont des correctifs de sécurité

    Posté par  . Évalué à 3.

    Premièrement, il est à remarquer que les deux notes de version que tu as posté concernent des correctifs de sécurité introduits par cette mise à jour (et non pas des failles de sécurité). Il n'y a donc pas lieu de s'alarmer.

    Plus en détail :

    1. La première note concerne une faille de sécurité pouvant être exploitée par un attaquant ayant accès au socket PHP (qui sert à lighttpd à communiquer avec PHP). Si tu n'as pas d'utilisateurs potentiellement malicieux ayant un accès shell sur ton serveur (parce que tu leur en as fourni un ou via une autre faille de sécurite), il n'y a vraiment pas lieu d'en faire une montagne. Je fais remarquer à nouveau que la nouvelle version du paquet corrige cette faille.

    2. La deuxième note concerne des attaques sur le protocole SSL/TLS qui malheureusement concernent tous les serveurs HTTPS. Ces attaques sont tout de même assez avancées, et pas forcément faciles à mettre en oeuvre, donc là encore inutile de sombrer dans la panique. Là encore, la nouvelle version du paquet contient des réglages plus sécurisés (enfin selon le mainteneur du paquet, bon, personnellement je suis pas super favorable à l'idée d'utiliser RC4 étant donné que les attaques CRIME et BEAST sont vraiment difficiles à utiliser en pratique…).

    Bref, ces deux notes de versions concernent des corrections de failles de sécurité, tu peux continuer à utiliser Debian les yeux fermés.

    • [^] # Re: Inutile de s'alarmer, ce sont des correctifs de sécurité

      Posté par  . Évalué à 3. Dernière modification le 04 juillet 2013 à 22:08.

      En même temps je ne suis pas très malin, la première ligne commençant par :

      " The default Debian configuration file for PHP invoked from FastCGI was vulnerable to local symlink attacks and race conditions when an attacker " […] "The problem lies in the configuration, thus this update will fix the problem "

      Cela dit, cela fait un peu un choque de recevoir un tel mail avec dés la première ligne "lighttpd (1.4.31-4) unstable; urgency=high". L'objet ne précise en rien qu'il s'agit d'une liste de "correctifs", mais seulement de "nouveautés".

      Merci pour les précisions techniques sur ces failles de sécurités d'ailleurs que je ne comprends parfois pas très bien.

      Dois-je en déduire que j'ai trainé des mois durant une Debian 6 avec des trous de sécurités sur lighttpd ? Ou s'agit-il de correctifs trainant depuis la "unstable" auquel cas je n'aurais jamais été concerné ?

      De mémoire je crois que la Debian 6.x me proposait lighttpd 1.4.28 ou quelque chose du genre (on y va mollo sur les mises à jour chez lighttpd …)

      • [^] # Re: Inutile de s'alarmer, ce sont des correctifs de sécurité

        Posté par  . Évalué à 3.

        Les gens qui sont touchés considèrent que la faille est grave oui, les autres non.

        Pour citer je ne sais plus qui : "all software are made of bugs". Oui, il y a des failles dans Debian, dans les logiciels upstream, certaines sont probablement là depuis très longtemps et ne seront jamais découvertes par quiconque. Tu veux système sûr ? Le principal problème sans utilisateurs malveillants, c'est le câble réseau. Débranche le.

        La sécurité d'un système ne repose pas exclusivement sur la correction du code qui tourne dessus. Il y a de nombreux dispositifs qui y contribue : droit unix, acl, SELinux, firewall… Déjà si tu règle le firewall pour qu'il n'autorise rien de plus que ce que tu veux faire avec, ce genre de failles n'a plus aucune importance.

        La sécurité d'un système dépend aussi de la menace qui pèse dessus. Si tu laisse traîner une babiole qui t'es très précieuse dans la rue, à la vue de tous, elle ne risque pas grand chose, parce que tout le monde s'en fout. Pour ton serveur sauf si t'as des données qui intéresse des gens il y a peu de chances qu'un hacker se casse la tête dessus pour trouver une faille. Parce que là on ne parle pas de failles béantes qui puisse être exploitées automatiquement.

        Please do not feed the trolls

        • [^] # Re: Inutile de s'alarmer, ce sont des correctifs de sécurité

          Posté par  (site web personnel) . Évalué à 3.

          Pour ton serveur sauf si t'as des données qui intéresse des gens il y a peu de chances qu'un hacker se casse la tête dessus pour trouver une faille

          Ça dépend aussi du serveur, certains sont plus intéressés par les ressources dont dispose le serveur que les données de celui-ci :
          - Processeur (miner du bitcoin)
          - Bande passante (bot ddos)
          - présence au sein d'une infra ou d'un réseau interessant (passerelle pour attaquer un autre serveur)

          mais effectivement, les failles en question sont un peu chaude à utiliser.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.