Le topic de la programmation: Et envoyez des sioux!

[Tramb]

OpenGL c'était que pour le CAD et c'est une state machine très très haut niveau avec énormément de shadowing. Et c'est un énorme comité tout mou qui avait/a vraiment du mal à bouger.
DirectX a filé une alternative bien supérieure pour le jeu vidéo et a servi de lièvre longtemps. Maintenant c'est fini.

D'ailleurs Vulkan c'est encore en grande partie en réaction à l'immobilisme et l'héritage d'OpenGL.

Bah chai pas je suis dans l'industrie depuis un moment maintenant, j'ai programmé sur tout ce qui bouge, serveurs en tout genre, applications mobiles, WEB, clients classiques, GPU, FPGA, servo moteurs, tout ce que tu veux

Et j'ai jamais échoué à trouver une alternative open source, et à chaque fois c'est mieux. A vrai dire y'a la moitié trucs que je saurais même pas faire sous windows et je m'y pencherai jamais.

Tu programmes tes GPU avec quels trucs open source, par curiosité ?

Lenovo a fait un pas dans cette direction, Unreal Engine de même, enfin bref, c'est un miracle que cette vieille moule de windows s'aggripe encore à son rocher.

Pas sûr que remplacer MS par Epic ou Steam soit un grand bénéfice pour le jeu vidéo (litote).

Il me semble que l'implémentation de Microsoft vérifie l'index de std::vector:perator[] quand on compile en debug par défaut. Je ne sais pas s'il y a quelque chose pour les tableaux C par contre.

Mais ça c'est du debugging, c'est pas standard, et ce n'est pas de la memory safety dans les applis shippées

[Orhin]

D'ailleurs je veux bien qu'on me cite un seul truc que Crosoft fait correctement, .Net core peut être, visual studio code.

La suite office reste pour l'instnat bien meilleure que n'importe quelle autre alternative.
La solution Teams fonctionne franchement pas mal.
Typescript est entrain de changer (en bien) l'environnement JS.
Etc.

On le voit avec des trucs comme Blender, désormais utilisé de plus en plus et qui devrait arriver à Hollywood si ça continue.

Alors j'aimerais bien que ce soit le cas hein, mais Blender n'est clairement toujours pas au niveau des outils pros utilisés par les gros studios d'animations ou de JV.
Oui ça fait le taf quand t'as pas de budget, mais y'a clairement mieux.

Ils ont complètement perdu le marché mobile alors qu'ils avaient un nouveau monopole facile à installer, Android (linux modifié) possède quasiment tout le marché now.

Cette comparaison n'a pas de sens, Microsoft n'a pas perdu le marché mobile vu qu'ils n'ont jamais été majoritaire sdessus.
Lorsqu'ils se sont lancés dans la bataille Google et Apple étaient déjà très bien installés et Microsoft s'est viandé car leur solution était effectivement un peu pourrie.
Mais ils ne sont pas fait détronner de quoique ce soit.

Au passage Android ne possède clairement pas tout le marché, iOS garde encore une très belle part du gateau.
Et aucun des 2 n'est open-source.

Ils n'ont pas du tout le monopole côté serveur (me semble que c'est du 40% pour eux désormais) et j'ai jamais rencontré un seul mec qui apprécie travailler avec des serveurs windows.

40% de part de marché côté serveur c'est juste énorme.
Azure représente une part non négligeable de leur chiffre d'affaire et est en constante croissance.

Niveau développement c'est tout simplement une blague, tout le monde déteste développer sous Windows.

Source ? À part "j4im3 p4s cro$oft lol".
C'est pas le meilleur environnement de travail mais c'est tout à fait acceptable pour des millions de devs.

Faut pas oublier qu'un téléphone c'est une machine comme une autre

Non.

les téléphones d'aujourd'hui sont plus puissants que les PCs des années 2000.

Et alors ?

Microsoft qui perd le marché mobile c'est la preuve qu'un rien pourrait leur faire perdre le marché desktop de la même manière.

Donc il leur reste que les desktops, il suffira d'un rien pour que Windows se fasse rayer de la carte comme se fut le cas sur mobile, et on n'en parlera plus.

Ça fait 20 ans qu'on entend les sirène de la mort de Windows, en attendant ça reste l'OS desktop le plus utilisé (et de trèèèès loin) dans le monde.

Je suis honnêtement ouvert à des exemples de trucs Microsoft cool

Ah bah oui, ton post est clairement un exemple d'ouverture d'esprit et d'impartialité.

Et je dis tout ça sans particulièrement apprécier Microsoft, mais ton post est tellement plein de sel et de mauvaise foi qu'il fallait rétablir un peu la balance.

[Anonyme20240202]

OpenCL/SYCL, Vulkan Compute, BrookGPU (plus niveau études)

Mais je fais aussi encore pas mal de CUDA et me semble que c'est toujours pas open source à proprement parler, et surtout les drivers nvidia sont toujours closed source pour sûr me semble

Sinon pour les trucs graphiques classiques WebGL, OpenGL, Vulkan et compagnie bien sûr

D'ailleurs pour ceux qui connaissent pas, des shaders dans ton browser qui parlent à ton GPU: https://www.shadertoy.com/

[ducon]

La suite office reste pour l'instant bien meilleure que n'importe quelle autre alternative.

Elle a toujours autant de mal à lire ses propres anciens formats ou ça s’est calmé ?
Parce qu’on peut critiquer LibreOffice autant qu’on veut (et il y a de quoi), au moins il sait lire ses formats d’il y a vingt ans. Perso, j’ai du mal avec l’interface de la suite Office.
À propos, un collègue m’a un jour demandé si je tapais mes documents avec LaTeX. Eh non, c’est LibreOffice.

[Orhin]

Elle a toujours autant de mal à lire ses propres anciens formats ou ça s’est calmé ?

Pas eu de soucis depuis un certains temps, après j'ai rarement à ouvrir des documents écrits dans un format d'il y a 5 versions.

Mais de toute façon je l'utilise assez peu au final, la grand majorité de ma doc est soit sur des outils en ligne (Confluence notamment) soit sur du markdown intégré aux sources (avec de la génération automatique de pdf et docx pour fournir aux vieux).

[Nilsou]

Nan, quand même, safe par default c'est mieux.
Le nombre de bugs de sécurité parce que [] est unchecked par défaut en C et en C++ est faramineux.
Le unchecked devrait être opt-in.

Oui mais bon, tout le monde compile du C avec tout les check optionnels des compilo activé désormais... il te préviens quasi tout le temps quand tu va faire de la merde à l'étape de la compilation.
Et dans les autres cas on aime bien que ça passe quand même quand on utilise le [] pour faire du décalage aisé sur des adresses mémoires qui servent de tampon avec quelqu'un d'autres (mémoire partagés, autre thread etc.) et là je vois mal comment un compilateur, quel qu'il soit, pourrait vérifier que tu ne fais pas de la merde.

[ducon]

Ça commence à dater pour moi aussi mais je me souviens de versions plus récentes qui n’arrivaient pas à créer correctement un format plus ancien pour une version de Word plus ancienne (l’ancien n’arrivait pas à le lire).

[Anonyme20240202]

Ouais les "sanitizers" sont de plus en plus à la mode pour revoir du code legacy ou éviter les erreurs bêtes. S'pas encore parfait.

Perso j'utilise les trucs google: https://github.com/google/sanitizers

Ensuite t'as juste à passer un argument à ton compilateur et paf, ça instrumente tout ton code et tu peux l'analyser

AddressSanitizer (detects addressability issues) and LeakSanitizer (detects memory leaks)
ThreadSanitizer (detects data races and deadlocks) for C++ and Go
MemorySanitizer (detects use of uninitialized memory)

[Nilsou]

Mais ça c'est du debugging, c'est pas standard, et ce n'est pas de la memory safety dans les applis shippées

Mais sur Rust c'est au niveau de la compilation de toute façon, c'est ni plus ni moins qu'un debugging avec le warning passé en erreur et voila...
Et sinon la plupart des classes de la librairies standards, celles qu'on utilise en pratique actuellement finalement, font des vérifications explicites ... et n'importe qui faisant une nouvelle classe et formé au C++ a tendance à redéfinir [].

Ouais les "sanitizers" sont de plus en plus à la mode pour revoir du code legacy ou éviter les erreurs bêtes. S'pas encore parfait.

Perso j'utilise les trucs google: https://github.com/google/sanitizers

Ensuite t'as juste à passer un argument à ton compilateur et paf, ça instrumente tout ton code et tu peux l'analyser

Perso j'utilise ceux qui sont par défaut dans Gcc depuis quelques années, Je me fais de très grosses appli depuis des années avec de très nombreux thread, de la communication en mémoires partagées en veut tu en voila. Les bugs mémoires sont resté rarissime en tout depuis. Je ne pense pas que j'échangerais de la légèreté de programmation pour les éviter.

La suite office reste pour l'instnat bien meilleure que n'importe quelle autre alternative.
La solution Teams fonctionne franchement pas mal.
Typescript est entrain de changer (en bien) l'environnement JS.
Etc.

Libreoffice est de plus en plus utilisé autour de moi perso. Et pour les gros rapports pas mal de gens utilisent Latex ...
Il y a encore pas mal de monde sous word et excel, mais vu la trajectoire de Libreoffice au fur et à mesure des années, amha, l'avance de crosoft est de plus en plus maigre. (perso c'est d'ailleurs mon premier système ou je ne me suis pas donné la peine d'installer word, je fais tout en libreoffice maintenant, ce qui m'aurait semblé être une aberration il y a quelques années)

Il n'y a que Windows qui conserve une avance confortable sur les systèmes grand public Linux façon Ubuntu. Mais là aussi, ça se réduit, il y a 10 ans Linux était inutilisable par un débutant, aujourd'hui on a les distrib ubuntu et mint installé par défaut dans pas mal de fac et les étudiants, même pas en informatique, s'y adapte en quelques minutes... c'est le jour et là nuit avec la situation antérieure.
Donc une avance confortable mais qui fond comme neige au soleil.

[Orhin]

Libreoffice est de plus en plus utilisé autour de moi perso. Et pour les gros rapports pas mal de gens utilise Latex ...
Il y a encore pas mal de monde sous word et excel, mais vu la trajectoire de Libreoffice au fur et à mesure des années, amha, l'avance de crosfot est de plus en plus maigre.

J'aime bien LaTeX mais en dehors du monde de la recherche c'est quand même très marginal.

Pour LibreOffice, ça a tendance à percer dans le public (car $$$) mais dans le privé je ne le vois quasiment jamais.
D'ailleurs même les clients étatiques (ou assimilés) types DGA/CEA/IRSN/etc utilisent très souvent la suite office (ou alors ils s'emmerdent à tout convertir avant de nous envoyer leurs documents ).

Après pour l'utilisation personnelle, effectivement Libre Office avait pas mal progressé ces 10 dernières années mais j'ai l'impression que Microsoft a renversé la vapeur avec beaucoup d'offres aggressives pour les étudiants (notamment via Office360).

[Nilsou]

Ha bon ? J'ai du passer entre les mailles du filets, j'ai rien remarqué

[Tramb]

Oui mais bon, tout le monde compile du C avec tout les check optionnels des compilo activé désormais... il te préviens quasi tout le temps quand tu va faire de la merde à l'étape de la compilation.

Bah non il peut pas, à l'étape de la compilation, dans le cas général.

Et dans les autres cas on aime bien que ça passe quand même quand on utilise le [] pour faire du décalage aisé sur des adresses mémoires qui servent de tampon avec quelqu'un d'autres (mémoire partagés, autre thread etc.) et là je vois mal comment un compilateur, quel qu'il soit, pourrait vérifier que tu ne fais pas de la merde.

Ouais on fait beaucoup de undefined behaviour en C, je te l'accorde. Mais il devrait être encapsulé pour être différencié des cas classiques.

- - - Mise à jour - - -

Mais sur Rust c'est au niveau de la compilation de toute façon, c'est ni plus ni moins qu'un debugging avec le warning passé en erreur et voila...
Et sinon la plupart des classes de la librairies standards, celles qu'on utilise en pratique actuellement finalement, font des vérifications explicites ... et n'importe qui faisant une nouvelle classe et formé au C++ a tendance à redéfinir [].

Nope, c'est au runtime dans Rust, c'est juste qu'il peut gauler certains problèmes à la compilation effectivement.
Rust a le mot clé "unsafe" pour encapsuler ce qui n'est pas garanti.

Perso j'utilise ceux qui sont par défaut dans Gcc depuis quelques années, Je me fais de très grosses appli depuis des années avec de très nombreux thread, de la communication en mémoires partagées en veut tu en voila. Les bugs mémoires sont resté rarissime en tout depuis. Je ne pense pas que j'échangerais de la légèreté de programmation pour les éviter.

Si tu considérais qu'il y avait un third hostile c'est plus du tout la même.
Tu valgrindes ton appli tes fois ou tu utilises les sanitizers ?

Je pense que tu sous-estimes la difficulté de faire du code solide (surtout dans un contexte multithread)

[Nilsou]

Ouais on fait beaucoup de undefined behaviour en C, je te l'accorde. Mais il devrait être encapsulé pour être différencié des cas classiques.

Ouais, dans l'idéal, mais c'est là ou ça commence à être lourdingue...

- - - Mise à jour - - -

Nope, c'est au runtime dans Rust, c'est juste qu'il peut gauler certains problèmes à la compilation effectivement.
Rust a le mot clé "unsafe" pour encapsuler ce qui n'est pas garanti.

Ce qui revient à ce que je disais : quand un langage te dis être safe mais que tu te met à utiliser des balises partout pour lui dire de redevenir non sécurisé ... tout ça pour ça quoi ...

Si tu considérais qu'il y avait un third hostile c'est plus du tout la même.
Tu valgrindes ton appli tes fois ou tu utilises les sanitizers ?

Ha mais si on commence à discuter du cas très spécifique d'applications qui doivent être résistante au piratage, c'est tout autre chose. Et c'est quand même ultra spécifique, la plupart des devs n'en ont rien à fiche.
Et sinon, oui, je valgrind

[Tramb]

Ouais, dans l'idéal, mais c'est là ou ça commence à être lourdingue...

Bof

Ce qui revient à ce que je disais : quand un langage te dis être safe mais que tu te met à utiliser des balises partout pour lui dire de redevenir non sécurisé ... tout ça pour ça quoi ...

Tu ne les mets quasi nulle part, tu encapsules les trucs sales. Et souvent y a même pas besoin.
En C tout le code est potentiellement teinté.
Tiens, tu peux mater ça c'est intéressant : https://www.chromium.org/Home/chromi.../memory-safety

Ha mais si on commence à discuter du cas très spécifique d'applications qui doivent être résistante au piratage, c'est tout autre chose. Et c'est quand même ultra spécifique, la plupart des devs n'en ont rien à fiche.

C'est de la correctness. Et malheureusement effectivement la plupart des dev n'en ont rien à fiche en effet
Et beaucoup beaucoup de code pas prévu pour se retrouve dans des objets connectés par exemple.

Et sinon, oui, je valgrind

Du coup tu ne trouves rien, avec, hein ?

[gros_bidule]

J'avoue que dans mon domaine (info de gestion en Java, souvent des API et des batchs Spring Boot), la sécurité est prise à la légère par les décideurs, tant en grosse SSII qu'en PME.
Je n'ai jamais eu d'expert en sécu en face, à part un mec qui :
- me demande de passer 1 ou 2h sur un site qui t'apprend les bases. Vous savez, les sites qui vous montrent des cas d'exploit' sur du code que l'on ne voit jamais en prod, comme des requêtes SQL jouées à la main et non avec un ORM (qui lui éviterait plein d'injections), ou des API et sites faites avec de bonnes vieilles servlets de Java EE, et surtout pas du Spring Web, ni même de Spring Security.
- joue les règles pas défaut d'analyseurs (Sonar, et surtout des outils obscurs dont j'ai oublié le nom), qui vont te sortir pleiiiiin de faux positifs, par exemple parce que tu n'escape (XSS, etc) pas toutes les chaînes de caractères, même celles qui ne viennent pas de l'extérieur. Ou plus drôle, on t'interdit de nommer un champ ou une propriété "password". Pfiou... en pratique, on appelle le gars au téléphone et pour peu qu'il soit sympa, on signale tous ces trucs comme faux-positifs et on passe à la suite.

Et nous n'avons ni le temps ni la culture pour être à l'aise sur la sécurité. On pense avoir des bases, certainement (ne pas faire confiance à tout ce qui vient de l'extérieur, comme l'url, payload, fichiers, etc), mais ça ne va pas plus loin.

On tient à jour les libs, et les logiciels, si on a la main dessus : j'ai déjà bossé (en SSII) sur un projet du gouvernement où les libs et logiciels serveurs (tomcat, postgres, jvm...) n'avaient pas été mises à jour depuis le début du projet, c'est à dire 5 ans. Et je me suis fait engueuler parce que j'avais remonté le soucis et même listé des CVE, donné une idée du boulot pour l'upgrade, et qu'un expert a sorti "nan mais y'a un nginx en frontal, il filtre, c'est sécurisé" (alors que nginx ne fait que passe-plat, hein, on peut s'amuser avec des fichiers et requêtes vérolés).

J'aimerais vraiment bosser un jour avec qqun dont la sécurité est le métier, de la même manière que le backend ou frontend est un métier pour d'autres. Pas un mec lambda catapulté chef de la sécurité et qui fait chier tout le monde avec des règles débiles pour être tranquille, et qui ne sait même pas justifier ses propos autrement qu'en disant "c'est les bonnes pratiques".

Qui sait, peut être un jour
Peut être que des coincoins conaissent Bell Canada. Je commence chez eux lundi, et pour voir la moyenne d'âge et le profil linkedin des gens, je serai enfin entouré de gens expérimentés et barbus qui parlent de Kotlin, Rabbitmq, parallélisme, etc. Ca fait trop méga plaisir de ne plus être l' "expert" (juste parce que 35 balais, je trouve ça idiot) parmi des jeunes ingés de ~23 ans. Ca va roxxer entre pros !

[gros_bidule]

Mais pour en revenir à ce dont vous parliez : étant néophyte sur le sujet, en quoi des langages sont-ils sécurisés ? (j'ai Rust en tête, à force de survoler des articles "promotionnels" de Mozilla)
Naïvement, je penserais plutôt que ce sont les compilos et les éventuels runtimes qui ont des règles et technos de sécurité, comme des sandbox, etc.
Le langage, lui, même s'il t'offre des process sécurisants, à priori rien ne t'empêche de faire du code crade et vulnérable ? Et puis de quelles vulnérabilités parle t-on ?
Aussi, si des langages sont vraiment intéressants pour la sécurité, pourquoi qu'on n'a pas ça en Java ou Kotlin ? Est-ce déporté sur des outils comme Sonar, Checkmarx ? Ca serait quand même un truc hyper intéressant, si je n'ai pas tout compris de travers.

Merci pour vos lumières !

[Orhin]

Peut être que des coincoins conaissent Bell Canada.

Ah bah plutôt car j'ai justement un projet qui va commencer bientôt avec eux.

[Anonyme20240202]

Ça parlait pas vraiment de sécurité stricto sensu là haut, c'tait plus niveau "qualité"/caractère error-prone du code, mais effectivement ça peut revenir à la même chose.

Y'a un article wikipédia entier qui s'attarde à définir ce qui constitue une "vulnérabilité": https://en.wikipedia.org/wiki/Vulnerability_(computing)

Je pense que parler de sécurité au niveau du langage n'est pas très pertinent la majorité du temps (comme tu le soulignes déjà dans ton post). Ton langage est compilé ou interprété par un autre outil, exécuté dans le contexte d'un OS/système donné, sur un hardware donné, et est manipulé par des êtres humains souvent (social engineering rentre en compte donc). Et en plus de ça, ton langage est très souvent, extrêmement, très largement, étendu par les librairies qui viennent le compléter, et l'utilisateur intéragit plus souvent avec une abstraction de plus haut niveau que le langage lui même, donc si cette abstraction est vulnérable, ce n'est pas un problème inhérent au langage.

Ultimement la question c'est quel language permettrait au mieux de refléter les intentions du programmeur, sachant que même avec de très bonnes intentions tu peux toujours faire un design qui est vulnérable d'un certain point de vue. Autrement dit la syntaxe même du langage humain/du langage des spécifications, est vulnérable.

Par exemple, disons que tu travailles sur une application critique embarquée, genre un software pour une fusée, dans le cas de la fusée ton souci principal ça va être de faire en sorte qu'elle n'explose pas en plein vol. Alors que si on parle d'un produit comme Alexa d'Amazon, ou autres devices IoT, ton principal soucis ça va être que tu distribues en masse un device qui va parfois contenir des infos privées et se retrouver dans un sous-réseau privé "intéressant" (le sous réseau de ta maison, derrière ta box internet), donc très susceptible aux attaques, contrairement à la fusée, et où l'exécution déterministe importe peu, contrairement à la fusée.

Donc on en revient à l'éternel problème des spécifications précises de ce que tu souhaites faire avec le language, et de quelle manière tu imposes/enforce ces spécifications. Sachant que les spécifications en elle même peuvent être vulnérable si incomplètes, etc.

Sécurité c'est polysémique, là j'imagine que tu parles de sécurité surtout en terme d'intrusion/d'attaques en gros

Selon le contexte, comme l'exemple de la fusée, on peut aussi parler de sécurité d'un autre point de vue. Tu programmes une application critique genre de l'équipement médical, militaire ou un software pour de l'aviation, la sécurité peu vite devenir une question de précision numérique. Dont les fameux exemples avec les erreurs d'arrondi, notamment Ariane 5:
http://ta.twi.tudelft.nl/users/vuik/...disasters.html
https://itsfoss.com/a-floating-point...alf-a-billion/

Donc bref, tout ça pour dire qu'à mon avis en pratique la sécurité à assez peu à voir avec le language, généralement la sécurité se retrouve surtout à un autre niveau.

À un niveau d'abstraction plus élevé: l'operating system que tu utilises, frameworks, etc:
https://en.wikipedia.org/wiki/VxWorks
Selon l'OS ton langage va être compilé/interprété/exécuté différement, donc le même code avec le même langage va changer de comportement selon le contexte.

Où tout simplement au niveau du hardware:
https://en.wikipedia.org/wiki/Hardwa...on#Secure_boot
https://en.wikipedia.org/wiki/Trusted_Platform_Module

Et de manière classique, au niveau des tests que tu fais, en n'oubliant pas qu'ultimement des tests ne sont jamais qu'une manière de spécifier et d'imposer/garantir un comportement.

---------------------------------------------------------------------------

On va parler d'exemples concrets où on peut considérer que le langage intervient directement dans la "sécurité".

Très souvent tu vas travailler sur des projets open-source, où tout du moins, sur des projets où les sources sont partagées avec de multiples parties.

Et y'a de fameux exemples, d'attaquants qui essayent de créer des failles en introduisant des bugs dans le code source directement, notamment le fameux exemple d'un mec qui avait soumis un code en remplaçant un "==" avec un "=" dans une condition "if", du coup à la revue, le code pouvait passer sur une mauvaise lecture du code. Mais surtout si le code n'est pas testé ou analysé par un outil approprié.

https://freedom-to-tinker.com/2013/1...tempt-of-2003/

Mais on peut imagine un langage qui rend la différence entre "==" et "=" extrêmement explicite, et de manière générale, un langage qui forcerait une syntaxe "sécurisée" c'est à dire qu'il serait plus difficile avec ce langage de manipuler la syntaxe existante pour injecter des comportements non souhaités ou ambigus à la lecture du code par un humain.

Un autre fameux exemple, c'est les injections SQL, vu qu'on est sur des instructions interprétées, le jeu devient d'injecter tes instructions, ou t'intéragir d'une manière non prévue avec l'interpréteur. Ce qui ultimement, est le cas pour n'importe quel processeur, au bout d'un moment dans la vie du code, ce code va se retrouver sous une certaine forme, directement exécuté par ta machine. Donc il va falloir décider de tout la chaine d'autorisation qui permet à du code de s'éxecuter sur ta machine et sous quelle forme il s'éxecute, avec quelles contraintes, etc.

---------------------------------------------------------------------------

Le mieux pour s'informer en terme de sécurité, c'est simplement de regarder l'histoire des failles de sécurité.
Et là on voit bien que la majorité du temps, le langage en lui-même intervient peu.

Social engineering:
- https://en.wikipedia.org/wiki/Kevin_...mputer_hacking
Failles hardware:
- https://en.wikipedia.org/wiki/Meltdo...lity)#Overview
- https://en.wikipedia.org/wiki/Spectr...vulnerability)
- http://wololo.net/2017/08/24/nintend...s-downgrading/
Failles software diverses (là encore c'est un problème de spécifications incomplètes/incorrectes finalement, donc erreur humaine au final):
- https://en.wikipedia.org/wiki/Heartbleed#Behavior
- https://en.wikipedia.org/wiki/DROWN_attack
- https://en.wikipedia.org/wiki/EternalBlue
- https://en.wikipedia.org/wiki/Shellshock_(software_bug)

---------------------------------------------------------------------------

Un point important c'est que la majorité du temps, la personne qui possède le hardware, pourra a priori toujours (avec plus ou moins d'effort), avoir le contrôle total sur le hardware.

Aucune console à ce jour n'a resisté au hacking.

99% des devices IoT (imprimantes ou tout ce que tu veux) sont hackables avec une simple connexion UART:
https://www.youtube.com/watch?v=h5PRvBpLuJs

Et donc même pour des trucs très sécurisé comme ta carte de crédit, ou les TPM que j'ai linké plus haut. Ultimement ça restera de la "simple" obfuscation.

Donc les spécifications des circuits sont difficilement disponibles, et les circuits sont obfusqués physiquement en foutant des couches physiques par dessus dans tous les sens pour empêcher une observation au microscope par exemple.

https://www.usenix.org/system/files/...ot14-grand.pdf

Rayons X, bains d'acide, etc.

Donc par exemple:

Tu veux livrer une console sur le marché, cette console permet de jouer à des jeux. Et cette console a tout un tas de services associés, comme par exemple un système de chat accessible via d'autres appareils, comme ton téléphone (ce qui implique des serveurs publics en gros).

Spécification #1, on ne doit pas pouvoir exécuter de code étranger sur la console en remplacement du firmware propriétaire.

C'est la base, donc en #1, si le mec peut mettre son software sur ta machine, bah quoique soit les sécurités que t'as mis en place, ça sautera.

Comme l'histoire l'a montré, c'est """impossible""" à faire autrement que via de la "bête" obfuscation. Quand l'utilisateur a physiquement le hardware sous la main, tu ne peux plus faire grand chose.

Donc là ce qu'on pourrait imaginer pour vraiment résoudre le truc, c'est un produit du genre Shadow ou Google Stadia. Tu ne donnes à l'utilisateur qu'un hardware pourri, qui lui permet de se connecter/s'authentifier, et ensuite toi tu possèdes le vrai hardware dans tes locaux, qui exécute le jeu à distance.

Mais même en faisant ça, tu devrais toujours gérer les tentatives d'attaque liées à l'authentification, donc par exemple, que faire si un mec clone complètement le hardware de son voisin, et se connecte pour jouer. Dans ce cas on voit que tu vas peut être vouloir interdir une double connexion simultanée venant du même appareil.

Tu peux aussi introduire une forme de localisation géographique/triangulation, pour vérifier qu'un appareil n'est utilisé que depuis un même emplacement physique, et détecter un petit malin qui aurait dupliqué le hardware d'authentification à moindre frais.

Et on peut même partir loin dans le délire et forcer une authentification biométrique, pour t'empêcher de partager la console avec ton petit frère.

Ce qui très honnêtement, se rapproche des délires de Microsoft et autres.

Et même là, encore une fois, tu peux imaginer une attaque MITM, où quelqu'un intervient sur la connexion physique entre l'utilisateur et les serveurs de jeu.

Donc bref, stricto sensu, ce n'est pas vraiment faisable parfaitement.

Spécification #2, la console étant connectée, il faut prévenir les attaques réseaux.

Là encore c'est stricto sensu "impossible".

Tu as beau être celui qui livre le hardware, tu es dépendant du contexte réseau où la console se trouve. Donc si y'a un MITM qui écoute la connexion, il pourra en gros facilement savoir quand la console est allumée ou éteinte par exemple.

De même, et on retrouve cet exemple dans les browser internet, si l'utilisateur de la console est un peu neneu et accepte un certificat pourri, un MITM pourra voir toute la connexion en clair.

Ensuite comment tu te préviens des attaques de types denial of service. Si t'as tout un tas de monstres qui s'attaque à tes serveurs, tu pourras difficilement garantir la qualité de ton service pour les utilisateurs de ta console.

Et bref, je me rends compte que je pars hors sujet, mais on voit qu'il est difficilement de garantir quoique ce soit niveau sécurité quand le hardware n'est pas physiquement en ta possession. On pourrait continuer longtemps avec d'autres exemples.

Et de même quand tu livres un software payant closed-source (photoshop, un jeu vidéo, etc.), il est impossible de se prévenir du reverse engineering autrement que via de l'obfuscation. Tous les jeux finiront par être crackés.

Quand le hardware est en ta possession, genre un service de stockage en ligne que tu proposes, y'a bien évidemment tout un tas d'autres problèmes bien connus qui se posent. Mais généralement rien qui n'est lié au langage encore une fois.

Et même dans le cas d'un hardware fermé à tout communication comme un truc qui pilote un servo moteur, on pourrait partir dans des délires d'EMP bomb https://en.wikipedia.org/wiki/Electromagnetic_pulse ou autre. Ou encore une fois d'une faille introduite en interne, par erreur ou autre (social engineering).

- - - Mise à jour - - -

Pour finir, une des implémentations les plus élégante que j'ai vu concernant la sécurité, c'est le Pledge de BSD:

https://man.openbsd.org/pledge.2

En gros tu déclares au tout début du programme quelles sont tes limitations (j'ai le droit d'utiliser tel ou tel composant, de telle manière), et tu t'y astreins de manière garantie.

[Tramb]

Mais pour en revenir à ce dont vous parliez : étant néophyte sur le sujet, en quoi des langages sont-ils sécurisés ? (j'ai Rust en tête, à force de survoler des articles "promotionnels" de Mozilla)
Naïvement, je penserais plutôt que ce sont les compilos et les éventuels runtimes qui ont des règles et technos de sécurité, comme des sandbox, etc.
Le langage, lui, même s'il t'offre des process sécurisants, à priori rien ne t'empêche de faire du code crade et vulnérable ? Et puis de quelles vulnérabilités parle t-on ?
Aussi, si des langages sont vraiment intéressants pour la sécurité, pourquoi qu'on n'a pas ça en Java ou Kotlin ? Est-ce déporté sur des outils comme Sonar, Checkmarx ? Ca serait quand même un truc hyper intéressant, si je n'ai pas tout compris de travers.

Merci pour vos lumières !

Java et Kotlin sont sandboxés sur la JVM donc ils n'ont pas non plus toute cette classe de bugs mémoire dont google et mozilla ont considéré qu'ils étaient le plus gros problème à éliminer. Après la JVM et son jit peuvent avoir des bugs, mais la surface de code est bien plus faible que la masse de Java écrite donc Java est bien bien plus safe que le C++.
Mais ça se paye

- - - Mise à jour - - -

Mais pour en revenir à ce dont vous parliez : étant néophyte sur le sujet, en quoi des langages sont-ils sécurisés ? (j'ai Rust en tête, à force de survoler des articles "promotionnels" de Mozilla)

Bah en fait y a plein de vulnérabilités possibles. Et certaines sont rendues impossibles par le langage. Par exemple un langage qui ne supporte pas le multithread n'aura pas de bug multithreads
Un langage qui boundcheck tous les accès à des containers ne permettra pas d'attaquer la stack ou le heap.
Un langage avec des règles de lifetime comme Rust interdira les "use-after-free".

[ducon]

Ada est réputé sécurisé.

[Tramb]

Ada est réputé sécurisé.

Ouaip tout est fait dedans pour éviter de se tirer dans le pied.

[Helix]

Ouaip tout est fait dedans pour éviter de se tirer dans le pied.

Si on n'oublie pas de s'en servir (coucou Ariane 5 )

[Tramb]

Si on n'oublie pas de s'en servir (coucou Ariane 5 )

Ouais c'est pour ça qu'on parle de "classes de vulnérabilités".

[Anonyme20240202]

Ouais après pour reprendre l'exemple du multithread tu peux assez facilement imaginer simplement 2 instances de ton languages qui communiquent, et paf, t'as des problèmes de concurrence. Et puis tu peux parfaitement émuler une execution concurrente sur un seul thread si tu voulais vraiment te créer des problemes.

Et vice versa, si tu respectes les scopes dans C++ et RAII, bah tu pourras jamais faire de use after free, et s'pas non plus compliqué à suivre comme principe.

Juste pour souligner que tu peux pas vraiment échapper au fait de responsabiliser le développeur, et que le langage ne pourra jamais pallier plus que ça par lui même. Non seulement la sécurité mais tout un tas d'autres trucs

[Tramb]

Ouais après pour reprendre l'exemple du multithread tu peux assez facilement imaginer simplement 2 instances de ton languages qui communiquent, et paf, t'as des problèmes de concurrence. Et puis tu peux parfaitement émuler une execution concurrente sur un seul thread si tu voulais vraiment te créer des problemes.

Et vice versa, si tu respectes les scopes dans C++ et RAII, bah tu pourras jamais faire de use after free, et s'pas non plus compliqué à suivre comme principe.

Mais c'est de l'ordre de la guideline.
Et en fait c'est faux, car tu as la notion d'invalidation des itérateurs qui est exactement isomorphe à un use after free. Sans aucune utilisation de pointeur.

Juste pour souligner que tu peux pas vraiment échapper au fait de responsabiliser le développeur, et que le langage ne pourra jamais pallier plus que ça par lui même. Non seulement la sécurité mais tout un tas d'autres trucs

Même les meilleurs programmeurs C du monde font des erreurs qui seraient rendues impossibles dans d'autres langages et qui ont des conséquences graves.
Et y en a pas beaucoup des excellents programmeurs C.

[Helix]

Et en fait c'est faux, car tu as la notion d'invalidation des itérateurs qui est exactement isomorphe à un use after free. Sans aucune utilisation de pointeur.

Mazette, c'est en lisant une phrase comme celle-ci que j'ai la preuve que je ne suis pas un vrai développeur

[Tramb]

Oh bah c'est juste du jargon, il "suffit" de le connaître. Il faut bien commencer quelque part !

https://godbolt.org/z/UC8-Y9
Voilà un exemple de use-after-free sans aucun pointeur, et avec du RAII.

[Cwningen]

N'importe quoi qui contient un pointeur/référence emprunté est dangereux : itérateurs, vues (string_view, span, match_results, ...), lambdas avec capture par référence, ... C'est plus simple d'utiliser un borrow checker que de se priver de tout ça.

[Tramb]

Yep, ce qui est intéressant là je trouve c'est le faux sentiment de sécurité donné par le C++. Au moins le C ne donne pas ça ^^

[Anonyme20240202]

Ouais ouais on est d'accord même si l'exemple en question est très forcé, tu utilises les range ou n'importe quel algorithme de la librairie standard. T'as jamais vraiment besoin de manipuler des itérateurs.

M'enfin c'est un autre débat tout ça, cet exemple en particulier, bonnes pratiques vs spécifications du langage directement. Fondamentalement on est d'accord, je vais certainement pas commencer à défendre le C/C++ concernant la facilité à se tirer une balle dans le pied.

Y'a sûrement mieux à faire niveau langage c'est clair, mais va falloir un moment.

Sinon j'aurais dit:

{
    auto iterator = a_map.find(2);
    a_map.erase(iterator);
} // plus possible de se tirer une balle dans le pied, similaire à RAII

Parce qu'autrement c'est pour moi l'équivalent de:

#include <iostream>

class Example {
  public:
    void use() { std::cout << data; }
    ~Example() { data = "invalid"; }
  private:
    std::string data = "valid";
};

int main() {
    Example instance{};
    instance.~Example();
    instance.use(); // undefined
    return 0;
}

Voire même fondamentalement de:

#include <map>

int main() {
    std::map<int, std::string> a_map;
    a_map[2] = "Youpi";
    auto it = a_map.find(4);
    a_map.erase(it); // Segfault
    return 0;
}

Car y'a une distinction à faire entre l'implémentation de l'itérateur et la volonté du dev derrière. Accéder à un élément invalide c'est un peu comme cet accès à un itérateur invalide de manière plus abstraite.

Mais bref, c'est complètement hors sujet, je suis tout à fait d'accord que y'a potentiellement du travail à faire concernant la "sécurité" des langages. Et que C/C++ ont toujours été à la rue à beaucoup de niveaux.

Dans les faits ça se fait en C++ via des trucs externes, les core guidelines où des outils d'analyses du code voire des améliorations des compilo directement, mais clairement rien n'est imposé dans les spécifications du langage en lui-même.

Genre le sujet est connu et des gens bossent dessus quoi, c'est pas laissé à l'abandon

- - - Mise à jour - - -

D'ailleurs je dois bien avouer que je m'attendais à voir l'exemple que tu as pris, traité dans les core guidelines (https://github.com/isocpp/CppCoreGui...eGuidelines.md)

Mais ils ne le traitent pas encore :/ ...

To-do: Unclassified proto-rules
[...]
pointer/iterator invalidation leading to dangling pointers: