CVE-2015-6409 : Downgrade STARTTLS appliqué au client Cisco Jabber

Magazine
Marque
MISC
Numéro
84
Mois de parution
mars 2016
Domaines


Résumé
La fin de l'année 2015 a été plutôt mouvementée pour Cisco. La société a publié pas moins d'une centaine d'avis de sécurité dans le courant du mois de décembre. Je vous épargne la description de chacun d'entre eux et m'attarderai plus particulièrement sur celui affectant le client Cisco Jabber de la version 9 à la version 11.1. Nous avons signalé la vulnérabilité associée à Cisco le 4 août 2015. Elle a été rendue publique sous l'identifiant CVE-2015-6409 le 24 décembre au soir à 18h30, juste avant l'ouverture du champagne et le début d'un marathon sans fin de toasts de foie gras [1].

1. Cisco Jabber for dummies

En tant que détenteur de la société Jabber Inc depuis 2008, la société Cisco se devait de mettre à disposition des entreprises une solution de communication intégrant le fameux service de messagerie instantanée du même nom. Il lui fallait également proposer une offre de communication unifiée capable de concurrencer Microsoft Lync (anciennement OCS) déjà sur le marché depuis plusieurs années. C'est donc au cours de l'année 2012 que la société a dévoilé la solution « Jabber for Everyone » mettant en avant le fameux client Cisco Jabber.

Cette solution a pour principal objectif de fournir un outil de communication tout-en-un aux utilisateurs finaux d'une entreprise en s'intégrant aux infrastructures Cisco Unified Communications Manager (CUCM) déjà existantes. Un employé peut désormais profiter de l'ensemble des technologies de communication Cisco au sein d'un même logiciel : passer des appels téléphoniques, participer à des...

Cet article est réservé aux abonnés. Il vous reste 95% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite


Articles qui pourraient vous intéresser...

Introduction aux TPM (Trusted Platform Modules)

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Les TPM (Trusted Platform Modules), brique de base du Trusted Computing, ont été imaginés il y a une vingtaine d’années, et pourtant ils ne sont pas très utilisés malgré leurs réelles qualités. Comment expliquer cela ? Cet article tend à fournir de premiers éléments de réponse.

Dora au pays du kernel debugging

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Après plusieurs années dans le monde de la sécurité informatique il est récurrent d'être confronté aux remarques telles que : « Wow tu bosses sur le kernel Windows, c'est trop cool, mais vachement compliqué quand même ! ». Que nenni, en réalité la documentation est conséquente et le point le plus difficile et rédhibitoire est bien souvent la mise en place d'un Labo permettant d'analyser celui-ci. En bref, cet article vous permettra de vous faire passer pour un super haxxor de ses morts qui dt des KPCR à tour de bras et vous permettra peut-être au passage de demander une augmentation.

En sécurité sous les drapeaux

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

En sécurité sous les drapeaux... du compilateur, ces fameux -fstack-protector-strong et autres -D_FORTIFY_SOURCE=2 que l’on retrouve dans de plus en plus de logs de compilation. Cet article se propose de parcourir quelques-uns des drapeaux les plus célèbres, en observant les artefacts dans le code généré qui peuvent indiquer leur utilisation, tout en discutant de leur support par gcc et clang. Après tout, nombre d’entre eux sont utilisés par défaut sous Debian ou Fedora, ils méritent bien qu’on s’y intéresse un peu.

Use-After-Free dans le noyau Linux

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Pièce logicielle qui a accompagné les deux dernières décennies, le noyau Linux est un système relativement complet qui dispose d’un allocateur de mémoire dynamique. Comme tous les logiciels classiques, le noyau est ainsi régulièrement sujet à des vulnérabilités de type Use-After-Free via cet allocateur.