Cette semaine en sécurité : Git Deep Dive, Mailchimp et SPF – Systeme io

Cette semaine en sécurité : Git Deep Dive, Mailchimp et SPF – Systeme io


Tout d’abord, git a été audité. Il s’agissait d’un effort parrainé par l’Open Source Technology Improvement Fund (OSTIF), une organisation à but non lucratif travaillant à améliorer la sécurité des projets Open Source. L’audit lui-même a été effectué par des chercheurs de X41 et GitLab, et deux vulnérabilités critiques ont été trouvées, toutes deux causées par la même mauvaise habitude de codage – en utilisant un int pour conserver les longueurs de tampon.

Sur les systèmes modernes, un size_t est toujours non signé et a la même longueur en bits que la largeur en bits de l’architecture. Il s’agit du type de données approprié pour les longueurs de chaîne et de tampon, car il est garanti de ne pas déborder lors de la gestion de longueurs jusqu’à la mémoire adressable maximale sur le système. D’autre part, un int est généralement long de quatre octets et signé, avec une valeur maximale de 2^31-1, ou 2147483647 — environ 2 Go. Un grand tampon, mais pas une quantité inouïe de données. Lancez quelque chose d’aussi gros sur git, et il se cassera de manière inattendue.

Notre premier exemple est CVE-2022-23521, une écriture hors limites causée par un int débordant vers le négatif. UN .gitattributes le fichier peut être validé dans un référentiel avec un client git modifié, puis l’extraction de ce référentiel entraînera le num_attrs variable à déborder. Poussez le débordement jusqu’à un petit nombre négatif, et git sous-allouera alors largement le tampon d’attributs et écrira toutes ces données au-delà de la fin du tampon alloué.

CVE-2022-41903 est un autre débordement d’entier signé, cette fois lorsqu’un joli format d’impression est abusé pour faire quelque chose d’inattendu. Jetez un œil à ce bloc de code :


        int sb_len = sb->len, offset = 0;
        if (c->flush_type == flush_left)
                offset = padding - len;
        else if (c->flush_type == flush_both)
                offset = (padding - len) / 2;
        /*
         * we calculate padding in columns, now
         * convert it back to chars
         */
        padding = padding - len + local_sb.len;
        strbuf_addchars(sb, ' ', padding);
        memcpy(sb->buf + sb_len + offset, local_sb.buf,
               local_sb.len);

Le format d’exploit ressemblerait à quelque chose comme %>(2147483647)%a%>(2147483646)%x41où le code ci-dessus s’exécute pour chaque instance de remplissage (Le %>(#) blocs) trouvés dans le format. La première fois que ce code ajoute (2^31)-1 espaces au début de la chaîne de sortie. Ce nombre se trouve être la valeur maximale d’un entier signé de quatre octets. Mais le bloc de code ci-dessus est exécuté une autre fois, et une fois de plus, du texte est ajouté au tampon, poussant sa longueur au-dessus de la valeur entière maximale. La première ligne de ce bloc effectue un cast implicite à partir de size_t pour intparamètre sb_len à une valeur négative.

Puis dans le memcpy() appel, sb->buf est un pointeur vers le début du tampon, sb_len est notre grand nombre négatif débordé et offset sera une valeur contrôlée par l’utilisateur. Cela signifie que l’emplacement de la destination envoyée à memcpy() peut involontairement être défini sur un emplacement de mémoire inférieur au début du tampon prévu. Écritures contrôlées par l’attaquant. J’ai ajouté quelques instructions de débogage printf() à ce bloc de texte et exécuté un cas de test :


$ ./bin-wrappers/git log -1 --pretty="format:%>(2147483647)%a%>(2147483635)%s" >/dev/null
Padding: 2147483647
sb_len: 0
offset: 2147483647
Memcpy: 
Padding: 2147483635
sb_len: -2147483647
offset: 2147483591
Memcpy: CI: upgrade to macos-12, and pin OSX version
=================================================================
==844038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8989f97c8 at pc 0x7fdb15e49d21 bp 0x7ffe8fa5c100 sp 0x7ffe8fa5b8b0
WRITE of size 44 at 0x7fd8989f97c8 thread T0
0x7fd8989f97c8 is located 56 bytes to the left of 4831838268-byte region (0x7fd8989f9800,0x7fd9b89f983c)

Le premier quatuor de sorties est la configuration, amorçant la ligne de journal avec un rembourrage pour qu’il soit max int long. Le deuxième quatuor est le dépassement de tampon, où sb_len est défini sur négatif, puis ajouté au décalage pour nous donner un emplacement à 56 octets à gauche du début du tampon. Le contenu qui est imprimé à cet emplacement est dans ce cas %s, qui est remplacé par la ligne d’objet du commit — 44 octets de long. Les auteurs suggèrent que cela pourrait être utilisé comme arme contre une « forge git », AKA GitHub et GitLab, car ces suites logicielles exécutent la commande git archive, qui peut invoquer une jolie chaîne contrôlée par l’utilisateur.

Les correctifs ont été poussés vers le code source de git le 8 décembre, mais de nouvelles versions contenant ces correctifs sont maintenant disponibles. Il existe environ 2 200 instances du fichier raw int problème, et ceux-ci prendront un certain temps à nettoyer, même avec des hacks amusants comme cast_size_t_to_int()une fonction en ligne qui tue simplement le programme si un 2 Go + size_t est gérée. Alors allez mettre à jour!

Mailchimp — Encore

Il semble que les gens de Mailchimp ne puissent pas faire de pause, car leurs outils d’administration internes ont de nouveau été consultés par des attaquants, ce qui a conduit à l’exposition de 133 comptes clients, dont WooCommerce. C’est la troisième fois que Mailchimp est victime d’une attaque d’ingénierie sociale ou de phishing au cours de l’année dernière, et à chaque fois, des e-mails de harponnage ont été envoyés aux utilisateurs finaux. Donc, si vous êtes sur des listes de diffusion Mailchimp, gardez cette violation à l’esprit la prochaine fois qu’un e-mail connexe arrivera. (Note de la rédaction : les deux newsletters de Hackaday utilisent Mailchimp, et nous n’avons pas été avertis, nous pensons donc que nous sommes bons.)

Logiciel de rançon Royal Mail

Dans une histoire qui pourrait avoir de grandes conséquences, la Royal Mail du Royaume-Uni a subi une attaque de ransomware sur son système de traitement du courrier international. L’attaque utilise le ransomware Lockbit, un groupe soupçonné d’être un gang de ransomware russophone. Cela pourrait être important, car une attaque contre une agence gouvernementale réelle est bien plus grave qu’une attaque contre une entreprise. Étant donné que Lockbit fonctionne en tant que ransomware-as-a-service, il sera très difficile de déterminer exactement qui a réellement réussi l’attaque. Pour l’instant, la recommandation est simple : n’envoyez pas de courrier international. Ouf.

Numérisation des enregistrements SPF

(Sebastian Salla) a ce qui peut être considéré comme un passe-temps étrange, sous la forme d’une analyse des enregistrements SPF à la recherche d’étranges erreurs de configuration. Dans sa dernière aventure, cette analyse figurait parmi les 3 millions de domaines les plus visités. Et une mauvaise configuration a été trouvée.

Mais attendez, qu’est-ce qu’un SPF et pourquoi nous en soucions-nous ? Sender Policy Framework est un enregistrement txt qui fait partie des enregistrements DNS d’un domaine. Et il spécifie quelles adresses IP sont réellement autorisées à envoyer des e-mails pour ce domaine. Ainsi, si un e-mail entrant prétend provenir d’un domaine avec un enregistrement SPF valide et que l’adresse IP d’envoi ne figure pas dans cet enregistrement, il est clair qu’il ne provient pas vraiment du domaine revendiqué.

Et faire rejeter les e-mails de votre domaine en raison d’un problème SPF est l’un des moyens les plus sûrs d’attraper la critique. Il est donc tentant de rendre le dossier SPF un peu plus… *libéral* qu’il ne devrait peut-être l’être. Et l’itération la plus extrême de ceci est de simplement gifler un +all sur votre enregistrement SPF et en finir avec ça. Bien sûr, cela indique au monde entier que chaque spammeur qui utilise votre domaine envoie en fait de vrais e-mails, mais au moins, les e-mails sortants du patron fonctionnent à nouveau. Avec plus d’un millier de domaines définis sur SPF +allapparemment c’est un défaut plus courant que prévu.

La partie vraiment intéressante est le who’s who de ces domaines mal configurés, comme plusieurs agences gouvernementales américaines, d’autres domaines gouvernementaux dans le monde et plusieurs universités. Le plus intéressant était le ministère ukrainien de la défense, où le dossier du SPF a été extrait d’un -all pour +all il y a environ 4 mois.

Bits et octets

Tailscale a découvert un problème potentiellement grave, où connaître l’ID de nœud d’un autre client permettrait à un attaquant d’ajouter le nœud à son propre réseau de queue. Cela aurait mis un attaquant à l’intérieur de votre VPN, certainement un mauvais scénario. Mais avant d’avoir vos fourches, le code vulnérable a été déployé pendant moins de quatre mois avant d’être corrigé. Il a été signalé en privé le 11 de ce mois et fixé le 12. Et pour démarrer, l’attaque laisse une signature de journal que Tailscale a pu rechercher et a conclu qu’elle était isolée des tests de preuve de concept. Vous pouvez consulter votre propre tableau de bord pour tous les nœuds partagés à partir de leur propre réseau de queue pour confirmation. Et même s’il s’agit d’une vulnérabilité désagréable, bon pour Tailscale de l’avoir divulguée. De nombreux vendeurs se seraient assis sur celui-ci et ne l’auraient jamais rendu public.

Le noyau Linux avait un débordement de tampon dans son code Netfilter, où un débordement de tampon pouvait entraîner à la fois une fuite de données et l’exécution de code. Il n’y a pas de chemin vers l’exploitation à distance, mais l’e-mail lié ci-dessus contient un PoC complet pour une élévation de privilèges locale. Et si l’exploitation du noyau est votre truc, Project Zero de Google a un nouvel article sur le sujet, tout sur le déréférencement nul.

Et si vous utilisez ManageEngine de Zoho, vos cheveux peuvent être en feu aujourd’hui, si vous n’avez pas mis à jour la version qui corrige CVE-2022-47966. Les chercheurs d’Horizon3 ont rétro-conçu le patch et ont renversé la mèche sur ce RCE. C’est un problème dans la façon dont l’authentification unique SAML est implémentée, en partie à cause d’une bibliothèque extrêmement ancienne intégrée au produit. C’est un exploit assez facile à réaliser, alors il est temps de vérifier ces installations !

Laisser un commentaire