Sécurité info - Page 47

Je suis d'accord qu'il faudrait utiliser des langages plus sûrs (je l'ai déjà dit : je considère par exemple que MISRA C est le parfait exemple que le C n'est pas un bon langage pour faire de l'embarqué critique), mais :

Lionel Debroux (./1380) :
Rust et Go ne pourront avoir aucune chance avec un logiciel de pensée obsolète "mais il ne faut pas que ça bouge pendant des mois" alors qu'il y a une nouvelle release majeure toutes les quelques semaines

Ce n'est pas un modèle de pensée obsolète, c'est une réalité. Quand tu développes un projet sérieux, la phase de réflexion et de planification peut être longue. Tu ne peux pas t'amuser à tout remettre en chantier à chaque fois qu'une dépendance évolue, sinon ton projet ne sortira jamais.

Tu m'objecteras probablement le "release early, release often" et autres "move fast and break things", mais les projets qui utilisent ce genre de philosophies peuvent se permettre de sortir des MVP et d'avoir des régressions en production. C'est un critère éliminatoire pour tout projet qui a un minimum de criticité. Si je voulais être mauvaise langue, j'ajouterais que les résultats sont souvent médiocres, aussi bien en matière de qualité logicielle qu'en terme de qualité pour l'utilisateur.

Si Rust et Go veulent percer dans ces milieux, il faudra qu'ils arrivent à être matures et stables, il n'y a pas d'autres solutions. Ça ne veut pas dire qu'il ne doit pas y avoir de correction des bugs liés à la sécurité bien sûr, mais qu'il n'est pas question de changer des trucs fondamentaux d'une release à l'autre.

Trop souvent, "on veut garder la liberté de faire des évolutions majeures n'importe quand pour améliorer" est une excuse pour ne pas avouer "on n'a pas réfléchi à la conception, on navigue à vue et on verra ce que ça donne".

./1380 J'ai l'impression à te lire que si on n'applique pas une politique de sécurité extrême avec des mises à jour aussi souvent que possible, alors c'est qu'on ne fait rien du tout et qu'on court un très gros risque.

Pour ce que je fais en développement, la sécurité est la dernière des préoccupations. Faire un démonstrateur d'un algorithme, une implémentation pour effectuer des mesures ou une modélisation ne présente aucun risque en matière de sécurité. Prendre du temps à tout protéger ou faire des mises à jour serait seulement une perte. Et on ne va certainement pas faire une mise à jour d'un composant la veille d'une démonstration

RHJPP > ce n'est pas pour autant qu'il ne faut pas le faire en sécurité : dans certains domaines de recherche industriels (avec. beaucoup de $$$ derrière), il est envisageable (je pense même que ça s'est déjà vu même si je n'ai pas de preuve) de modifier le code expérimental pour qu'il renvoie des valeurs légèrement fausses.

Tu ne peux pas t'amuser à tout remettre en chantier à chaque fois qu'une dépendance évolue, sinon ton projet ne sortira jamais.

Certes, mais Rust et Go sont tous les deux, depuis des années, dans une phase où l'utilisation d'une nouvelle release ne remet pas tout en chantier. Et c'est heureux. Les grosses casses de compatibilité seraient pour des versions 2 des langages.

Si Rust et Go veulent percer dans ces milieux, il faudra qu'ils arrivent à être matures et stables, il n'y a pas d'autres solutions.

Peut-être que des entités prendront, pour ces langages, le rôle qu'ont Redhat, SUSE et quelques autres pour les distributions Linux, ou maintenant même Java pour RedHat puisqu'Oracle veut passer à des mises à jour rapides pour Java, comme le dont déjà la plupart des autres langages: figer une release pour un temps certain, en n'y appliquant qu'un sous-ensemble des mises à jour de sécurité. Ca pourrait être une solution pour contenter à peu près à la fois:
* ceux qui veulent et peuvent développer plus rapidement du code qui aura moins de bugs, quitte à traiter des casses de compatibilité antérieures sur des éléments mal faits de la toolchain, de la lib standard ou de certaines dépendances (l'écosystème Go a des soucis avec les modules, ça n'a pas été bien fait au départ, le passage aux modules est apparemment un mauvais moment à passer mais après, ça va plutôt mieux à long terme), et des obsolescences logicielles au fil de l'eau: ils resteront sur les versions à évolution rapide;
* ceux qui veulent rester sur une base qui n'évolue que rarement, avec des releases rares, une faible mise à jour des dépendances, et donc en général un déploiement en rares big bangs coûteux. Les projets avec un certain niveau de criticité seront en général dans cette catégorie, nous sommes d'accord

Sur RHEL 7.5, 7.6 et 7.7, Redhat a fait un travail moins limité que précédemment d'upgrade de packages user-space, pour des raisons à la fois de sécurité et de fonctionnalité. Peu d'upstreams fournissent un support sécurité sur 5 ans, c'est à la fois un principe de réalité (la maintenance des versions anciennes, et le packaging desdites versions, ont un coût, alors que beaucoup de projets et distributions ont déjà du mal à vivre...) et une bonne chose pour inciter à / forcer des upgrades vers des versions développées selon des standards et méthodes plus modernes. Ce travail d'upgrade réduit un peu la dangerosité de l'assemblage RHEL 7.x causée par les toolchains par défaut qui ne changent pas (GCC 4.8, donc absence ou faible diffusion des mitigations un tant soit peu récentes, PIE / relro / bindnow / etc.), les packages qui n'ont pas été mis à jour alors que des versions plus récentes contiennent des mises à jour de sécurité qui ne sont pas toujours clairement labelisées comme telles, la mauvaise car difficile maintenance du fork d'une version vraiment antique du kernel (les travaux de spender indiquent qu'il manque des centaines de patches de sécurité dans tous les kernels LTS, mainline comme vendor), etc..

J'ai l'impression à te lire que si on n'applique pas une politique de sécurité extrême avec des mises à jour aussi souvent que possible, alors c'est qu'on ne fait rien du tout et qu'on court un très gros risque.

Ca dépend sur quoi. Pour certains composants très largement répandus, une surface d'attaque élevée, avec un niveau de privilège élevé, des moyens d'accès à distance et/ou des PoC publics d'attaque, c'est un fait qu'on peut courir de gros risques si on ne fait pas les mises à jour de manière assidue. Pour des packages que presque personne n'utilise, même s'il y a de très gros problèmes, le risque qu'on prend à ne pas faire des mises à jour tout de suite est beaucoup plus faible, bien sûr.

Sur toutes mes machines perso, et la plupart des machines pro que j'administre (la plupart des machines Debian, et encore une fois, en environnement spécial où on est censés faire les mises à jour), unattended-upgrades est installé. Mes machines perso, et une machine pro, utilisent Debian sid, parce que dans les Debian, c'est ça qui permet d'avoir accès à des versions plus récentes qui ont en moyenne moins de vulnérabilités, à davantage de mitigations, etc. Il n'y a pas de support sécurité sur testing, et le support sécurité de stable - comme celui de toutes les distributions stables - laisse à désirer.
Ce n'est pas parce que les diverses équipes sécurité font mal leur travail que les distributions stables ont un support de sécurité loin d'être parfait. C'est parce qu'ils n'ont pas assez de moyens et que les informations dont ces équipes disposent sont très partielles: beaucoup de mises à jour de sécurité, y compris pour des packages largement utilisés, ne sont pas annoncées comme telles, pour quantité de raisons (à une époque, difficulté d'obtenir des assignations de CVE IDs; difficulté de se rendre compte que certains changements sont des mises à jour de sécurité; autre chose à faire que de détailler les problèmes et corrections; volonté de cacher les problèmes de sécurité; j'en passe). Même pour des packages populaires, presque toutes les mises à jour de sécurité issues de mes jobs de fuzzing ont été assez silencieuses, sans CVE IDs, donc elles ont été peu backportées vers les distros stables. Il y avait probablement peu d'ACE dans le lot, c'est vrai, mais énormément de DoS.

RHJPP > Que la sécurité du code de prototypes de recherche ou industriels soit secondaire, je peux le comprendre (même si l'argument de Flan est tout à fait recevable). Par contre, tu as toute la sécurité périphérique : si ton environnement de travail est corrompu (vol de données par quelqu'un qui va breveter ta découverte, destruction des données, corruption du code ou de l'environnement d'exécution...) tu risques d'avoir des problèmes. Ce n'est pas pour rien qu'en 10 ans, l'application des règles de sécurité du CNRS a pris un nouveau tournant (même si mes amis les chercheurs ont les habitudes bien ancrées ^^).

Ha oui, mais il n'était question que des développements que l'on fait.
On a bien sûr des contraintes de confidentialité et de sécurité pour notre système informatique. Il est déjà arrivé qu'un partenaire vienne faire un audit avant le début d'une étude ou nous demande de mettre en place des mesures particulières comme une isolation des machines utilisées et une restriction de l'accès aux locaux. On a aussi quelques fois des demandes étonnantes comme l'autorisation de diffuser des résultats, mais seulement si on ne donne pas les unités

Par contre, on ne mettra pas forcément à jour une librairie utilisée par un démonstrateur uniquement pour combler une faille de sécurité si ça n'a pas la moindre importance.

Lionel Debroux (./1384) :
Sur toutes mes machines perso, et la plupart des machines pro que j'administre (la plupart des machines Debian, et encore une fois, en environnement spécial où on est censés faire les mises à jour), unattended-upgrades est installé.

Autant c'est important de faire les mises à jour de sécurité régulièrement, autant je suis persuadé que les installer automatiquement est une bombe à retardement (je pense la même chose des mises à jour auto de Windows 10, évidemment).

Cette configuration ne serait pas adaptée chez nous. Tu n'imagines pas les réactions qu'entrainerait le redémarrage imprévu d'une machine pour faire une mise à jour alors que ça faisait deux semaines qu’elle était en train de réaliser un calcul ^^

À moins que le redémarrage automatique soit désactivé, mais dans ce cas, la sécurité n'est pas assurée

(couplet sur le fait que Linux n'a pas besoin de redémarrer pour appliquer les mises à jour, etc. dans 3... 2... 1... ^^)

Un tel couplet serait inapproprié
Pour appliquer des mises à jour de sécurité, moins besoin de redémarrer que Windows qui verrouille les fichiers du système en utilisation (sans que ça empêche significativement les malwares de fonctionner et de se rendre persistants, mais je ne suis pas sûr que cette pratique ait été à l'origine faite pour la sécurité ?), oui. Mais il est également un fait que comme les autres, les distros Linux et les BSD ont besoin de redémarrer pour appliquer certaines mises à jour, que ce soit le kernel dont presque toutes les mises à jour sont de sécurité (il y a quelques mises à jour qui contiennent un seul patch pour corriger une grosse erreur de compilation, par exemple, mais à part ça, peu de gens utilisent kexec / KSplice / KGraft / etc., qui réduisent la nécessité de rebooter), le daemon D-Bus qui a plusieurs vulnérabilités significatives dans l'année et dont le design ne permet pas de redémarrer, certains daemons systemd je crois, etc.

Des calculs qui prennent des semaines, sans possibilité de les redémarrer efficacement, j'en fais parfois, pour les sessions de fuzzing justement.

Stable. Sécurisé. Choisissez l'un ou l'autre

C'est pas tellement l'un ou l'autre qu'un compromis à trouver entre les deux en fonction de l'étude de risques ^^

Uther (./1372) :
A voir. On a des langage plus sécurisés que le C comme l'Ada depuis longtemps et ça n'a pas pris. Rust a l'air mieux parti, mais il est encore trop jeune pour convaincre les milieux sécurisé, qui aiment bien les outils qui ont fait leur preuve depuis longtemps.

+1 pour l'Ada ! Après je te rejoins sur la jeunesse de Rust mais avec des Mozilla et l'ANSSI qui poussent des projets derrière ça va permettre d'accélérer l'adoption du langage notamment dans le milieu de la sécuirté à mon sens !

Interessant comme certains veulent vendre le release-early/release-often comme une mesure de sécuritée.

Le jour ou les fabricant d'avion, machin special ou reacteurs nucleaire commence dans ce domaine, on va pouvoir vraiment se preparer au pire.

Le RE/RO est l'antithese de la sécurité. En fait c'est meme le meilleur moyen de corriger ce meme truc en insinuant que ca a été fait pour etre plus sécurisé, alors qu'en fait c'est tout l'inverse.

Une partie des problemes actuels en terme de sécurité est a cause de cette politique.

Release when Ready and Tested, est la seule chose valable.

On le vois bien dans le domaine du JV par exemple. Bien sur les jeux n'etait pas bug-free a l’époque, mais le fait de devoir les livrer sur un media qu'on ne peux pas changer forçait les dev a faire plus d'effort. De nos jour, certains jeux sortent en version "finale" avec tellement de bug qu'une version alpha a l'ancienne semblerais bug-free. Mais maintenant on peux envoyer des patches 3x plus gros que le jeu d'origine, OSEF, ca corrige au moins un des probleme tout en ajoutant de nouveau, mais on pourra toujours patcher plus tard.

Voila la mentalité du RE/RO.

Le truc c'est qu'on ne peu pas comparer les release régulière pratiquées par les navigateurs (ou le compilateur Rust) avec ce qui est fait dans d'autre secteurs comme le jeux vidéo. Sortir énormément de fonctionnalité avec des betas au final peu testée, c'est pas forcément mieux qu'un nombre limité de fonctionnalité dont on est sur qu'il est resté un temps suffisant en test.

Il faut voir que les sorties périodiques ne veulent absolument pas dire que l'on fait n'importe quoi. "Release when Ready and Tested" n'est pas incompatible avec un cycle rapide, je dirais même au contraire que c'est un prérequis indispensable à un cycle rapide sérieux. Les nouveautés sont développées dans la branche Nightly qui est activement utilisée est testée, et elles peuvent y rester des années si nécessaire. Elles ne sont introduites dans la beta et donc que lorsque l'on estime qu'elles sont stabilisées ou il faudra encore plusieurs semaines de tests avant d'arriver dans une version officielle.
Au contraire de ce que tu semble supposer, il y a d'autant moins de pression pour introduire une fonctionnalité non stable, étant donné que si une fonctionnalité n'est pas prête à temps, ça ne décale sa disponibilité que de quelques semaines.

Je ne suis pas sur que tu te rende compte que des systemes de la complexité d'un navigateur web, quand tu ajoute une nouvelle feature, et que tu veux releaser, tu ne teste pas que la nouvelle feature. Il faut refaire une campagne QA sur l'ensemble du truc si tu veux etre sur qu'il n'y a aucune regression.

Et tout n'est pas automatisable.

Et en l'occurence, les navigateurs et ce que les promoteurs du RE/RO ne font pas c'est de faire ces tests de manière globale. Quand on vois a quel point la qualité des navigateur a baissé entre conso mémoire, CPU et autre ce n'est pas que lié a la complexité, c'est aussi lié au faut qu'on patche ici et la pour masquer les vrai problèmes et on fait une nouvelle feature qu'on teste, qui casse un autre truc que personne n'a vu et on continue sur la même lancé.

La mentalité RE/RO est de construire un château de carte et de s’étonner qu'il s’écroule pour refaire la même chose encore et encore et encore.

Et si le JV est pertinent car c'est exactement le meme probleme.

Godzil (./1395) :
Quand on vois a quel point la qualité des navigateur a baissé entre conso mémoire, CPU et autre ce n'est pas que lié a la complexité, c'est aussi lié au faut qu'on patche ici et la pour masquer les vrai problèmes et on fait une nouvelle feature qu'on teste, qui casse un autre truc que personne n'a vu et on continue sur la même lancé.

Je ne trouve pas, au contraire... Les moteurs de rendu des navigateurs sont éprouvés, et les évolutions majeures sont développées et testées sur plusieurs mois/années... Typiquement, il a fallu 2 ans et 2 mois avant qu'Electrolysis passe du canal Trunk au canal Release (et actif par défaut pour tout le monde) ; 1 an et 4 mois si on prend la fourchette basse pour que les premiers échantillons d'utilisateurs (1 du canal Release soient affectés. C'est tout sauf du release often à l'aveugle, je trouve...

Godzil (./1395) :
Je ne suis pas sur que tu te rende compte que des systemes de la complexité d'un navigateur web, quand tu ajoute une nouvelle feature, et que tu veux releaser, tu ne teste pas que la nouvelle feature. Il faut refaire une campagne QA sur l'ensemble du truc si tu veux etre sur qu'il n'y a aucune regression.

Sauf que la non régression suite à une nouvelle fonctionnalité est faite sur Nightly (qui n'est pas qu'une branche ou on commite ses dev). Les tests automatiques sont joués en permanence et sont très poussés au point qu'il n'y a pas besoin de tant de tests manuels que ça. Certaines fonctionnalités y restent des années. Seules les fonctionnalité considérées stabilisées passent en phase beta.

Godzil (./1395) :
Et en l’occurrence, les navigateurs et ce que les promoteurs du RE/RO ne font pas c'est de faire ces tests de manière globale. Quand on vois a quel point la qualité des navigateur a baissé entre conso mémoire, CPU et autre ce n'est pas que lié a la complexité

Tu te bases sur autre chose que ton ressenti personnel ? Parce que j'ai vraiment l'impression inverse. Je trouve les navigateurs actuels bien plus stables et moins bugués qu'à l'époque où ils faisaient des sorties événementielles. Je trouve très rarement des choses qui relèvent clairement du vilain bug dans les navigateurs actuels alors que j'en trouvais en pagaille à l'époque. C'est d'autant plus remarquable que la complexité des navigateurs Web a explosé.

Comparer la consommation mémoire, n'a aucun sens, car comme tu le dis la complexité a changé et c'est clairement un point à prendre en compte. La complexité a explosé aussi bien du coté des moteurs que des sites web, ça rend toute comparaison directe caduque.

Et puis il y avait au moins autant de problèmes de performances à l'époque des sorties évènementielles. Je me souviens notamment de Firefox 3 et 4 qui ont du subir de grosses cure d'allègement via les version mineures suivantes, justement parce la nécessité de faire de grosses sorties, avec beaucoup de fonctionnalités, dans un délai raisonnable avait obliger à privilégier les fonctionnalités aux performances.

Godzil (./1395) :
c'est aussi lié au faut qu'on patche ici et la pour masquer les vrai problèmes et on fait une nouvelle feature qu'on teste, qui casse un autre truc que personne n'a vu et on continue sur la même lancé.

La encore j'ai l'impression que cette affirmation ne repose que sur ton extrapolation personnelle du fonctionnement d'équipes que tu ne connais pas. Ce que tu décris ressemble simplement à un environnement de travail non maitrisé, et ça n'a pas grand chose à voir avec le mode de sortie. Je dirais même au contraire que pour assurer des sorties régulières sérieuses, l’environnement se doit d'être maitrisé.

Godzil (./1395) :
La mentalité RE/RO est de construire un château de carte et de s’étonner qu'il s’écroule pour refaire la même chose encore et encore et encore.

Et si le JV est pertinent car c'est exactement le meme probleme.

Non, ça c'est juste du développement à La Rache™ et c'est en effet comme ça que sont gérés beaucoup trop de jeux-vidéos de nos jour vu qu'ils ont généralement des deadlines impératives, peu de considération pour la qualité et absolument aucunes pour la sécurité. Résultat on sort des produits non finis.

Les sorties périodiques permettent justement de ne pas être autant contraint par les deadlines. Les fonctionnalité prêtes sortent, et celles qui ne le sont pas attendent simplement le prochain cycle qui n'est que quelque semaines plus tard.

En résumé, il y a une différence entre le Release Often et le Release Early, Release Often si cher à Kevin ^^


Il est possible de faire du Release Often tout en conservant la qualité… mais ça coûte cher. Du coup, quand il faut faire un choix entre « plein de fonctions utiles mais parfois bugguées » et « pas trop de fonctions utiles mais hyper fiables », je comprends que le second choix ne soit pas toujours le meilleur ^^

Je suis d'accord avec ça, RO != RERO et RO ne force pas nécessairement une mauvaise qualité.

https://langui.sh/2019/07/23/apple-memory-safety/ : sans surprise, chez Apple aussi, l'absence de sûreté mémoire est la cause majoritaire des vulnérabilités importantes.
Mais je les vois mal adopter Rust, vu qu'ils ont Swift, à ma connaissance nettement moins populaire hors de l'écosystème Apple que Go et Rust, préférés pour les logiciels portables.

Lionel Debroux (./1399) :
Mais je les vois mal adopter Rust, vu qu'ils ont Swift, à ma connaissance nettement moins populaire hors de l'écosystème Apple que Go et Rust, préférés pour les logiciels portables.

De ce que j'avais lu, dans sa dernière version, Swift intégrerait en partie certaines des fonctionnalités qui font la particularité de Rust. J'ai pas regardé en détail mais si Swift devient viable pour la programmation système sure, ça peut devenir intéressant.

Swift a toujours été pensé pour faire de la programmation système, avec. pas mal de garanties (mais pas autant que pour Rust) tout en restant très concis (on est assez proche du Python).
Ça fait quelques années qu'il fonctionne sur Ubuntu (au moins), mais c'est sûr qu'en termes de popularité sur Linux est assez loin…

et autres: une nouvelle petite variante de Spectre v1 a été publiée aujourd'hui, patchée dans les kernels Linux stables, et les updates vont arriver dans les diverses distros des divers OS.

https://googleprojectzero.blogspot.com/2019/08/down-rabbit-hole.html

TL;DR : faille massive (et présente depuis de multiples versions de l'OS) dans la gestion de l'entrée de texte de Windows. Ça permet d'exécuter du code dans un autre processus, même si ce dernier a un niveau de privilège supérieur.

Wow ! Et l'article vaut la lecture, merci pour le lien et le résumé

De rien

Et ça n'a pas l'air simple à corriger, en plus :/

Non en effet, et c'est ça qui est inquiétant

Tout refaire j’en ai peur

Les posts du blog P0 sont en général un régal. Non seulement les membres du Project Zero sont très forts techniquement, mais au moins certains d'entre eux savent bien rédiger.


Super