Bulletin d'alerte Debian

DLA-65-1 python-django -- Mise à jour de sécurité pour LTS

Date du rapport :
29 septembre 2014
Paquets concernés :
python-django
Vulnérabilité :
Oui
Références dans la base de données de sécurité :
Dans le dictionnaire CVE du Mitre : CVE-2014-0480, CVE-2014-0481, CVE-2014-0482, CVE-2014-0483.
Plus de précisions :

Cette mise à jour corrige un problème avec reverse() créant des URL externes, un déni de service impliquant le téléversement de fichier, un problème de détournement de session potentiel dans un intergiciel d’utilisateur distant, et une fuite de données dans l’interface administrative.

Cette mise à jour vous est apportée grâce aux parrains de Debian LTS : http://www.freexian.com/services/debian-lts.html

  • CVE-2014-0480

    Django est fourni avec une fonction d’assistance django.core.urlresolvers.reverse, classiquement utilisée pour créer un URL à partir d’une référence pour inspecter une fonction ou un nom de modèle d’URL. Cependant, lorsqu'une entrée est présentée avec deux barres obliques (//), reverse() pourrait créer un URL fonction du modèle à d’autres hôtes, permettant à un attaquant conscient de l’usage non sûr de reverse(), (c'est-à-dire pour prendre un cas courant, dans une situation où un utilisateur final peut contrôler la cible d’une redirection), de créer des liens vers les sites de son choix, d’activer l’hameçonnage ou d’autres attaques.

    Pour remédier à cela, la résolution inverse d’URL (URL reversing) veille dorénavant à ce qu’aucun URL ne commence avec deux barres obliques (//), en remplaçant la seconde barre oblique par sa contrepartie encodée d’URL (F). Cette approche garantit que les sémantiques restent les mêmes, tout en rendant les URL relatifs au domaine et non au modèle.

  • CVE-2014-0481

    Dans la configuration par défaut, quand le système de téléversement de fichier de Django est fourni avec un fichier qui aurait les mêmes nom et chemin sur le disque qu’un fichier existant, il essaie de créer un nouveau nom unique de fichier en ajoutant un tiret bas et un nombre à la fin du nom de fichier (tel qu’enregistré sur le disque), incrémentant le nombre (c'est-à-dire, _1, _2, etc.) jusqu’à créer un nom n’entrant pas en conflit avec celui d’un fichier existant.

    Un attaquant connaissant cela peut exploiter le comportement séquentiel de la création de nom de fichier, en téléversant de nombreux petits fichiers qui ont en commun un nom de fichier. Django, dans leur traitement, créera des nombres continuellement croissant d’appels de os.stat() en essayant de créer un nom de fichier unique. Par conséquent, même un nombre relativement petit de tels téléversements peut dégrader de manière significative les performances.

    Pour remédier à cela, le système de téléversement de fichier de Django n’utilisera plus de noms avec nombres séquentiels pour éviter des conflits de noms de fichier sur le disque. À la place, une chaîne alphanumérique courte et aléatoire sera ajoutée, supprimant la possibilité de créer de manière fiable plusieurs noms de fichier continuellement différents.

  • CVE-2014-0482

    Django fournit un intergiciel, django.contrib.auth.middleware.RemoteUserMiddleware, et un dorsal d’authentification, django.contrib.auth.backends.RemoteUserBackend, utilisant l’en-tête REMOTE_USER en vue d’authentification.

    Dans quelques circonstances, l’utilisation de ces intergiciel et dorsal pourrait conduire à ce qu’un utilisateur reçoive la session d'un autre utilisateur, si une modification de l’en-tête REMOTE_USER se produit sans action de connexion ou déconnexion.

    Pour remédier à cela, l’intergiciel garantit dorénavant qu’un changement dans REMOTE_USER, sans une déconnexion explicite, forcera une connexion avant d’accepter un nouveau REMOTE_USER.

  • CVE-2014-0483

    L’interface administrative de Django, django.contrib.admin, fournit une fonction permettant à des objets voisins d’être affichés pour une sélection dans une fenêtre surgissante. Le mécanisme pour cela repose sur le placement de valeurs dans l’URL et de chaînes de requête qui indiquent le modèle concerné à afficher et le champ dans lequel le lien est implémenté. Ce mécanisme doit réaliser des vérifications de permission au niveau de la classe du modèle dans son ensemble.

    Ce mécanisme, cependant, ne vérifiait pas que le champ indiqué représentait effectivement le lien entre les modèles. Par conséquent, un utilisateur ayant accès à l’interface d’administration et avec une connaissance suffisante de la structure du modèle et des URL adéquats, pourrait construire des fenêtres surgissantes qui pourraient afficher des valeurs de champs non liés, y compris des champs que le développeur de l’application n’avait pas prévu d’exposer de cette façon.

    Pour remédier à cela, l’interface administrative, en plus de ses vérifications habituelles de permission, vérifie que le champ indiqué représente effectivement un lien avec le modèle enregistré par l’administrateur et lèvera une exception si l’une des conditions est fausse.

Pour Debian 6 Squeeze, ces problèmes ont été corrigés dans la version 1.2.3-3+squeeze11 de python-django.