Une faille de sécurité non comblée par Apple depuis 11 ans, Réactions à la publication du 13/06/2018

[Lionel]

Dans un article très détaillé, Ars Technica revient sur une faille de sécurité présente sur macOS (et avant Mac OS X) depuis 11 ans.

La faille concerne la signature des codes qui permet à macOS d'authentifier la source des logiciels et ainsi éviter que des malwares ne puissent revêtir des habits de logiciels légitimes.

Il s'avère que le système de signature des codes d'Apple le fait sur tout un fichier soumis, même si plusieurs codes sont inclus dedans.
Ce n'est pas une vulnérabilité selon des experts, mais un bug associé à des instructions floues proposées par Apple.

Il est toutefois possible aujourd'hui de faire croire à un Mac que du code est signé par un développeur, même si ce n'est pas le cas.

Lien vers le billet original

[Pat94]

Simple, Apple va répondre, pour votre sécurité : "acheter vos logiciels sur l'APP Store"

Ce message a été modifié par Pat94 - 13 Jun 2018, 07:05.

[ericb2]

Ou comment tuer les logiciels "tiers" (que ce nom est moche ...)

[yponomeute]

LittleSnitch a été mis à jour et la vulnérabilité CVE-2018-10470 est corrigée dans la version 4.1


https://obdev.at/cve/2018-10470-8FRWkW4oH8.html
https://www.okta.com/security-blog/2018/06/...signing-checks/
https://www.obdev.at/products/littlesnitch/releasenotes.html

[gesti]

Ce n'est absolument pas une faille de sécurité d'Apple. Certains programmes utilisent de facon incorrecte une API fournie par Apple et affichent donc de faux positifs. Mais Apple ne pouvait pas y faire grand chose, a part clarifier la documentation de l'API, ce qu'ils ont fait.

C'est donc les programmes concernés qu'il faut corriger (Little Snitch a déja été mis a jour, les autres devraient suivre).

[kikeo]

Il s'avère que le système de signature des codes d'Apple le fait sur tout un fichier soumis, même si plusieurs codes sont inclus dedans.

rien compris

[raoulito]

Il s'avère que le système de signature des codes d'Apple le fait sur tout un fichier soumis, même si plusieurs codes sont inclus dedans.

rien compris

+1

[marc_os]

Il s'avère que le système de signature des codes d'Apple le fait sur tout un fichier soumis, même si plusieurs codes sont inclus dedans.

rien compris

+1

En fait on peut compiler avec Xcode uniquement pour une cible architecturale donnée comme les processeurs Intel 64 bits, ou compiler en "fat binary" pour obtenir une Application "universelle" contenant du code i386, x86_64, ou PPC (ok, ça date un peu pour ce dernier). L'App (ou le bundle, cas plus général) peut donc contenir plusieurs exécutables. Le truc c'est qu'il pouvait arriver que seul l'un des exécutables soit signé (le premier) mais pas les autres, ce qui permettait théoriquement de remplacer ces autres exécutables par des trucs malveillants sans que l'OS ne rechigne.
ArsTechnica cite huit logiciels affectés :
VirusTotal, Google Santa, Facebook OSQuery, Little Snitch Firewall, Yelp, OSXCollector, Carbon Black’s db Response, et « plusieurs outils » de chez Objective-See.

Ce message a été modifié par marc_os - 13 Jun 2018, 15:05.

[raoulito]

@marc_os alors là respect! et merci c'est carrément plus clair !

[Licorne31]

En fait on peut compiler avec Xcode uniquement pour une cible architecturale donnée comme les processeurs Intel 64 bits, ou compiler en "fat binary" pour obtenir une Application "universelle" contenant du code i386, x86_64, ou PPC (ok, ça date un peu pour ce dernier). L'App (ou le bundle, cas plus général) peut donc contenir plusieurs exécutables. Le truc c'est qu'il pouvait arriver que seul l'un des exécutables soit signé (le premier) mais pas les autres, ce qui permettait théoriquement de remplacer ces autres exécutables par des trucs malveillants sans que l'OS ne rechigne.
ArsTechnica cite huit logiciels affectés :
VirusTotal, Google Santa, Facebook OSQuery, Little Snitch Firewall, Yelp, OSXCollector, Carbon Black’s db Response, et « plusieurs outils » de chez Objective-See.

VirusTotal... Pas mal, ça, un antivirus qui pourrait être porteur d'une vérole...

[yponomeute]

En fait on peut compiler avec Xcode uniquement pour une cible architecturale donnée comme les processeurs Intel 64 bits, ou compiler en "fat binary" pour obtenir une Application "universelle" contenant du code i386, x86_64, ou PPC (ok, ça date un peu pour ce dernier). L'App (ou le bundle, cas plus général) peut donc contenir plusieurs exécutables. Le truc c'est qu'il pouvait arriver que seul l'un des exécutables soit signé (le premier) mais pas les autres, ce qui permettait théoriquement de remplacer ces autres exécutables par des trucs malveillants sans que l'OS ne rechigne.
ArsTechnica cite huit logiciels affectés :
VirusTotal, Google Santa, Facebook OSQuery, Little Snitch Firewall, Yelp, OSXCollector, Carbon Black’s db Response, et « plusieurs outils » de chez Objective-See.

VirusTotal... Pas mal, ça, un antivirus qui pourrait être porteur d'une vérole...

Logiciels affectés, pas infectés. Aucun des logiciels cités n'est porteur d'un truc malveillant pour cette vulnérabilité. Ils ont juste un défaut qui ne leur permet pas de s'assurer à 100% qu'un logiciel tiers signé ne soit pas porteur d'une vérole.

[vlady]

Il s'avère que le système de signature des codes d'Apple le fait sur tout un fichier soumis, même si plusieurs codes sont inclus dedans.

rien compris

+1

En fait on peut compiler avec Xcode uniquement pour une cible architecturale donnée comme les processeurs Intel 64 bits, ou compiler en "fat binary" pour obtenir une Application "universelle" contenant du code i386, x86_64, ou PPC (ok, ça date un peu pour ce dernier). L'App (ou le bundle, cas plus général) peut donc contenir plusieurs exécutables. Le truc c'est qu'il pouvait arriver que seul l'un des exécutables soit signé (le premier) mais pas les autres, ce qui permettait théoriquement de remplacer ces autres exécutables par des trucs malveillants sans que l'OS ne rechigne.
ArsTechnica cite huit logiciels affectés :
VirusTotal, Google Santa, Facebook OSQuery, Little Snitch Firewall, Yelp, OSXCollector, Carbon Black’s db Response, et « plusieurs outils » de chez Objective-See.

J'ai l'impression que macOS n'est pas directement en cause. C'est la séquence correcte de la validation de la signature (d'un fat binary, t'as raison) qui n'est pas triviale et certains nombre de softs (et pas OS), comme Little Snitch, se servent mal de l'API de validation et peuvent laisser passer des "morceaux" non signés.

Ce message a été modifié par vlady - 13 Jun 2018, 19:58.

[Fafnir]

Panic Inc. a eu une alerte il y a qq années quand un dévelopeur a accepté toutes les alertes parce qu'il les considéraient comme un embêtement.

[linus]

Il s'avère que le système de signature des codes d'Apple le fait sur tout un fichier soumis, même si plusieurs codes sont inclus dedans.

rien compris

+1

En fait on peut compiler avec Xcode uniquement pour une cible architecturale donnée comme les processeurs Intel 64 bits, ou compiler en "fat binary" pour obtenir une Application "universelle" contenant du code i386, x86_64, ou PPC (ok, ça date un peu pour ce dernier). L'App (ou le bundle, cas plus général) peut donc contenir plusieurs exécutables. Le truc c'est qu'il pouvait arriver que seul l'un des exécutables soit signé (le premier) mais pas les autres, ce qui permettait théoriquement de remplacer ces autres exécutables par des trucs malveillants sans que l'OS ne rechigne.
ArsTechnica cite huit logiciels affectés :
VirusTotal, Google Santa, Facebook OSQuery, Little Snitch Firewall, Yelp, OSXCollector, Carbon Black’s db Response, et « plusieurs outils » de chez Objective-See.

J'ai l'impression que macOS n'est pas directement en cause. C'est la séquence correcte de la validation de la signature (d'un fat binary, t'as raison) qui n'est pas triviale et certains nombre de softs (et pas OS), comme Little Snitch, se servent mal de l'API de validation et peuvent laisser passer des "morceaux" non signés.

Je suis un peu étonné car je pratique beaucoup la signature de bundles contenant de multiples binaires et je n’ai jamais constaté que la commande « codesign » laisse passer quoique ce soit qui n’aurait pas du passer. Au contraire je la trouve très stricte et pointilleuse.
J’ai souvent charcuté des bundles multilinéaires à titre de debugging et jamais pris gatekeeper en défaut.

[zero]

En fait on peut compiler avec Xcode uniquement pour une cible architecturale donnée comme les processeurs Intel 64 bits, ou compiler en "fat binary" pour obtenir une Application "universelle" contenant du code i386, x86_64, ou PPC (ok, ça date un peu pour ce dernier). L'App (ou le bundle, cas plus général) peut donc contenir plusieurs exécutables. Le truc c'est qu'il pouvait arriver que seul l'un des exécutables soit signé (le premier) mais pas les autres, ce qui permettait théoriquement de remplacer ces autres exécutables par des trucs malveillants sans que l'OS ne rechigne.

Gesti, si ça pour toi ce n'est pas une belle grosse faille de sécurité, qu'est-ce que c'est ?

[Licorne31]

En fait on peut compiler avec Xcode uniquement pour une cible architecturale donnée comme les processeurs Intel 64 bits, ou compiler en "fat binary" pour obtenir une Application "universelle" contenant du code i386, x86_64, ou PPC (ok, ça date un peu pour ce dernier). L'App (ou le bundle, cas plus général) peut donc contenir plusieurs exécutables. Le truc c'est qu'il pouvait arriver que seul l'un des exécutables soit signé (le premier) mais pas les autres, ce qui permettait théoriquement de remplacer ces autres exécutables par des trucs malveillants sans que l'OS ne rechigne.
ArsTechnica cite huit logiciels affectés :
VirusTotal, Google Santa, Facebook OSQuery, Little Snitch Firewall, Yelp, OSXCollector, Carbon Black’s db Response, et « plusieurs outils » de chez Objective-See.

VirusTotal... Pas mal, ça, un antivirus qui pourrait être porteur d'une vérole...

Logiciels affectés, pas infectés. Aucun des logiciels cités n'est porteur d'un truc malveillant pour cette vulnérabilité. Ils ont juste un défaut qui ne leur permet pas de s'assurer à 100% qu'un logiciel tiers signé ne soit pas porteur d'une vérole.

J'ai bien fait la différence entre "affecté" et "infecté", c'est pour ça que j'ai écrit "pourrait" (conditionnel).

Ceci dit, le fait que ces logiciels soient "affectés" fait qu'ils peuvent être "infectés" par des malfaisants pour transmettre des véroles.
Et la récente histoire de Transmission me fait dire que, même en téléchargeant directement depuis le site de l'auteur, on n'est pas à l'abri d'une modification délétère de l'application... même si le fait de télécharger depuis le site de l'auteur est quand même beaucoup plus sûr que depuis des sites comme "soft-gratuits" ou "tout-a-un-clic" (noms inventés, mais vous voyez desquels je veux parler), voire même depuis des sites bien moins cashers et hors charte...

[yponomeute]

Ceci dit, le fait que ces logiciels soient "affectés" fait qu'ils peuvent être "infectés" par des malfaisants pour transmettre des véroles.

Non, pas dans le cas de la vulnérabilité dont il est question ici.

[Licorne31]

Ceci dit, le fait que ces logiciels soient "affectés" fait qu'ils peuvent être "infectés" par des malfaisants pour transmettre des véroles.

Non, pas dans le cas de la vulnérabilité dont il est question ici.

Ah bon?

En fait on peut compiler avec Xcode uniquement pour une cible architecturale donnée comme les processeurs Intel 64 bits, ou compiler en "fat binary" pour obtenir une Application "universelle" contenant du code i386, x86_64, ou PPC (ok, ça date un peu pour ce dernier). L'App (ou le bundle, cas plus général) peut donc contenir plusieurs exécutables. Le truc c'est qu'il pouvait arriver que seul l'un des exécutables soit signé (le premier) mais pas les autres, ce qui permettait théoriquement de remplacer ces autres exécutables par des trucs malveillants sans que l'OS ne rechigne.(...)

Ce qui est possible "en théorie" finit souvent par être fait "en pratique", surtout si ça peut nuire à autrui et/ou rapporter du pognon...

[downanotch]

Je suis un peu étonné car je pratique beaucoup la signature de bundles contenant de multiples binaires et je n’ai jamais constaté que la commande « codesign » laisse passer quoique ce soit qui n’aurait pas du passer. Au contraire je la trouve très stricte et pointilleuse.
J’ai souvent charcuté des bundles multilinéaires à titre de debugging et jamais pris gatekeeper en défaut.

Le problème n'est pas dans l'OS ni dans les outil de développement. Il est dans un certains nombres d'applications tierces qui utilisent mal la procédure de validation et peuvent être abusée dans certains cas.

[marc_os]

En fait on peut compiler avec Xcode uniquement pour une cible architecturale donnée comme les processeurs Intel 64 bits, ou compiler en "fat binary" pour obtenir une Application "universelle" contenant du code i386, x86_64, ou PPC (ok, ça date un peu pour ce dernier). L'App (ou le bundle, cas plus général) peut donc contenir plusieurs exécutables. Le truc c'est qu'il pouvait arriver que seul l'un des exécutables soit signé (le premier) mais pas les autres, ce qui permettait théoriquement de remplacer ces autres exécutables par des trucs malveillants sans que l'OS ne rechigne.(...)

Ce qui est possible "en théorie" finit souvent par être fait "en pratique", surtout si ça peut nuire à autrui et/ou rapporter du pognon...

Ça fait finalement juste 11 ans que la théorie n'a pas été confirmée par la pratique dans le cas présent.

[Licorne31]

Ce qui est possible "en théorie" finit souvent par être fait "en pratique", surtout si ça peut nuire à autrui et/ou rapporter du pognon...

Ça fait finalement juste 11 ans que la théorie n'a pas été confirmée par la pratique dans le cas présent.

“It’s really easy,” Joshua Pitts, a senior penetration testing engineer at security firm Okta, said of the technique.
When he discovered it in February, he quickly contacted Apple and the third-party developers.
“This really scared the bejeebus out of me, so we went right to disclosure mode.”

On a eu du bol, c'est un White Hat qui l'a trouvé le premier, et il l'a filé à Apple sans la rendre publique... il y a environ quatre mois.
Ceci dit, maintenant que c'est connu, on peut s'attendre à des exploits visant les anciennes versions d'OSX!

[downanotch]

“It’s really easy,” Joshua Pitts, a senior penetration testing engineer at security firm Okta, said of the technique.
When he discovered it in February, he quickly contacted Apple and the third-party developers.
“This really scared the bejeebus out of me, so we went right to disclosure mode.”

On a eu du bol, c'est un White Hat qui l'a trouvé le premier, et il l'a filé à Apple sans la rendre publique... il y a environ quatre mois.
Ceci dit, maintenant que c'est connu, on peut s'attendre à des exploits visant les anciennes versions d'OSX!

Non : "Pitts said tools built into macOS weren’t susceptible to the bypass". Encore une fois, l'OS ne se laisse pas abuser, contrairement à certaines applications tierces.

Ce message a été modifié par downanotch - 15 Jun 2018, 13:55.