1350

xD
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

1351

1352

Bravo c’est connus depuis en gros la sortir du film 😅
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

1353

mais je n'ai vu aucun film de la série terminator embarrassed

1354

Batator embarrassed
avatarQue cache le pays des Dieux ? - Ximoon's Box - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

1355

avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1356

\o/
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

1357

perso viré depuis un moment en faveur de mpv <3

1358

MPC tu veux dire ?
avatar

1359

Euh... "heap-based buffer over-read" qui permettrait de réaliser de l'ACE, donc RCE si le fichier incriminé fait partie d'une playlist distante, et reçoit un CVSSv3 de 9.8 ? Avec un seul bug d'over-read, je peux comprendre infoleak (de quelques octets, à moins qu'il y ait moyen de répéter l'opération qui leake et d'exfiltrer facilement les données), je peux admettre DoS (même si ce n'est pas toujours le cas hors de builds spéciaux type AddressSanitizer)... mais manipulation de fichiers, et a fortiori ACE/RCE, WTF ? Ou alors, c'est autre chose qu'ESET a trouvé. Aux chiottes les fabricants de pro-virus bourrés de vulnérabilités, au fait.

A https://trac.videolan.org/vlc/ticket/22474 , linké depuis https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13615 et qui confirme que c'est un over-read, les devs de VLC ne semblent pas très contents... et à leur place, je penserais la même chose, si encore une fois, c'est bien le testcase reporté qui pose problème.

Tiens, il faudra que je regarde si VLC a fini par arrêter de packager libmodplug (en la remplaçant par libopenmpt, qui offre un rendu nettement plus fidèle et surtout qui est du code beaucoup plus sûr), comme le fait Debian, ou si au moins, VLC upstream tel qu'il est utilisé sous Windows et MacOS X package un build de libmodplug Git HEAD. Sans ça, de mémoire, il n'y a pas que des OOB reads, dans libmodplug...
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1360

Mmh, ouais, en y regardant de plus près c'est pas clair.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1361

./1358 non non mpv léger rapide ergonomique et n'a jamais de soucis à la pause durant la lecture d'url distantes au contraire de vlc

mpc c'etait il y à bien longtemps, largement remplacé ensuite par totem jusqu'à son nettoyage profond bien débile pour se conforter au minimalisme de gnome ...
j'y regrette fortement le collage auto d'url à l'ouverture de fichier, chose ensuite absente de vlc qui se contente de mettre la dernière url lue ...

./1359 oula c'est velu xD un autre level
fidèle oui et non, modplug tracker certes ne se confortait pas au standard mod mais nombre de modules ont été écrits avec, ce n'est donc pas négligeable
niveau lecture la référence pour moi restera xmplay (donc bass) qui bien que n'étant pas ouvert est incomparable en fidélité, la bonne époque

1362

(y'a pas de standard de référence pour les MOD, y'a toujours eu des différences entre les lecteurs)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1363

bah si c'est clairement standard, tu vas certes trouver des variations sur le nombre de channels et samples mais c'est facilement identifiable car remplaçant le M*K* original

mais modplug à quant à lui sa propre manière de lire le rendant alors *incompatible*, ça avait je crois même fait polémique à l'époque, l'auteur (fr ?) refusant de se conforter au reste du monde ?!

1364

Non, y'a des effets que différents lecteurs n'interprètent pas de la même façon, ou qui sont supportés par certains mais pas par d'autres, etc. Pareil pour les cas spéciaux ou un peu tordus.

C'est un format qui s'est bâti et qui a évolué au fil des implémentations des lecteurs et trackers, personne n'est officiellement chargé de le maintenir et d'en donner une interprétation "officielle".
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1365

En effet, il n'y a pas, à ma connaissance non plus, de standards pour MOD, S3M, XM, IT et MPTM, sans parler des nombreux autres formats moins répandus smile
libmodplug est très bas dans la liste des librairies de rendu recommandées par Saga Musix ( https://sagamusix.de/en/music/ ), et ce n'est pas seulement parce qu'il est un des mainteneurs d'OpenMPT / libopenmpt: bien que contrairement à libxmp, libmodplug gère le format MPTM qu'elle a introduit, elle produit des erreurs de rendu assez nettes sur plusieurs modules IT - même pas MPTM - de Saga Musix, que libxmp ne produit pas.
Je n'ai pas utilisé libbass pour jouer des modules, je l'ai utilisée seulement avec afl-fuzz -n puisqu'elle est closed-source et qu'à l'époque, je n'utilisais pas honggfuzz et son instrumentation basée sur les capacités de tracing hardware des processeurs (qui ne vaut pas les builds instrumentés avec AddressSanitizer, mais c'est mieux qu'un fuzzer idiot). Le mainteneur avait été très réactif, corrigeant les crashes en moins de 48h. Mais là, j'ai une autre session de fuzzing en cours, on verra plus tard ^^
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1366

Est là oublie je ne suis pas d’accord, le format mod de par ses origines et évolution n’as pas vraiment de stand il est vrai, autant S3M, IT, XM et quelques autres ont un tracker de référence qui est le standard.
Enfin on peu prendre un standard pour le MOD: si on ne peux pas le lire sur un AMIGA, il n’est pas standard wink
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

1367

donc un même fichier mod stocké sur floppy ou clé usb peut être standard ou pas ?
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

1368

je ne connaissait le principe de fuzzer, intéressant smile

le standard c'est le MK d'origine, ensuite toutes les variations ne changent en rien le format du fichier, il faut juste identifier le nombre de samples et channels via la signature MK alternative
pour les effets ok si les nouveaux ajouts diffèrent ou ne se sont pas accordés et collisionnent c'est pas top, mais la structure du fichier elle restera dans tous les cas identique à l'originale

alors certes personne ne revendique le maintiens du format mais d'autres se sont attelés depuis longtemps à le décrire précisément avec ses variations
http://lclevy.free.fr/mo3/mod.txt
M.K. signature variations
2.6 File format tag
_______________________________

This is the most controversial field in the file. This field has been
the most 'ravaged', with many people using it in non-standard ways for
their own purposes. There are a few standard tags which you can find
here which tell you DEFINITELY what file format the file is, but there
are many more non-standard tags. This makes the job of deciding what
format a MOD is a difficult one. I will attempt to describe the known
formats below. If you know of one I miss, please let me know.

'M.K.', 'FLT4',
'M!K!', '4CHN' : 4 channels, 31 instruments

'6CHN' : 6 channels, 31 instruments

'8CHN', 'OCTA' : 8 channels, 31 instruments

// Another annotion about these tag fields: here you got some other fields.
// If you don't want to support them in your player, you should at least de-
// tect them. All these MODs have of course 31 instruments.
// 'FLT4', 'FLT8': Startrekker 4/8 channel file. ('FLT6' doesn't exists)
// 'CD81' : Falcon 8 channel MODs
// '2CHN' : FastTracker 2 Channel MODs
// 'yyCH' where yy can be 10, 12, .. 30, 32: FastTracker yy Channel MODs
// 'yyCH' where yy can be 11, 13, 15: TakeTracker 11, 13, 15 channel MODs
// 'TDZx' where x can be 1, 2 or 3: TakeTracker 1, 2, 3 channel MODs
// 'xCHN' where x can be 5, 7 or 9: TakeTracker 5, 7, 9 channel MODs
//
// Thanks must go to Inertia for most of these extra tag fields.
//
// All these formats, except for the FLT8 format, are *EXACTLY* the same as
// the standard M.K. 4 channel format; the only difference is the size of
// one pattern. The size of one pattern is calculated w/ the following
// "formula":
// (Nr_Of_Channels shl 8)
//
// ( Nr_Of_Channels shl 8 <====> Nr_Of_Channels*4*64
// ^ ^^
// | ||
// Note length: 4 bytes -----+ ||
// Lines/patttern: 64 ---------++
// )
// The tag '4CHN' doesn't exists.
//
// Some extra information about the "FLT8" -type MOD's:
//
// These MOD's have 8 channels, still the format isn't the same as the
// other 8 channel formats ("OCTA", "CD81", "8CHN"): instead of storing
// ONE 8-track pattern, it stores TWO 4-track patterns per logical pattern.
// i.e. The first 4 channels of the first logical pattern are stored in
// the first physical 4-channel pattern (size 1kb) whereas channel 5 until
// channel 8 of the first logical pattern are stored as the SECOND physical
// 4-channel pattern. Got it? ;-).
// If you convert all the 4 channel patterns to 8 channel patterns, do not
// forget to divide each pattern nr by 2 in the pattern sequence table!


Other information that is found in this field can be assumed to be
somebody's attempt at protection, or some other information that was used
in the 'older' file format. If you can't find any of the above
information, it is best to assume that it's a 4 channel file. As for how
many instruments there are, check the bytes at location 471 in the file.
If there is text there (ASCII $20-$7E (32-126)), then you can probably
assume it's a 31-instrument file. Otherwise, it's an older 15 instrument
file.

// The method described above works lovely!

pour le s3m le format est officiel http://lclevy.free.fr/mo3/s3m.txt
pour le xm je pense aussi, vu que c'est gars de triton qui a écrit la doc http://lclevy.free.fr/mo3/xm.txt
it est aussi trouvable au même endroit mais je n'en sais rien http://lclevy.free.fr/mo3/it.txt

edit > ok certain changent un peu le calcul des offset et autres, mais ca reste détectable

1369

C'est en partie le fuzzing de bases de code C/C++, et afl qui a popularisé le fuzzing grâce à sa puissance et sa facilité d'utilisation, même si le concept date des années 1980, qui est derrière l'augmentation du nombre de CVE IDs (pour ce qu'ils valent...) ces 3 dernières années. Honggfuzz est plus ancien qu'afl, et dispose de capacités qu'afl n'a pas, mais n'a pas eu le même impact.
MS est en train de s'intéresser à Rust pour éliminer une proportion significative des vulnérabilités graves - c'était le but de Mozilla en concevant Rust, d'ailleurs: https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ et posts plus anciens de la même série, linkés depuis celui-ci.

Intéressants, tes liens décrivant les principaux formats smile
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1370

https://trac.videolan.org/vlc/ticket/22474 : le problème de VLC relayé ci-dessus est donc plutôt un problème de libebml, dont sont exempts les binaires VLC officiels depuis plus d'un an. Les packages libebml de Debian Stretch et Ubuntu 18.04 sont actuellement obsolètes. MITRE, Cert Bund et beaucoup de soi-disant journalistes ont fait gravement de la m*.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1371

ce sera à terme obligatoire dans certains milieux d'utiliser de tels langages ?

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.
avatar

1373

Le coût de la gestion de l'insécurité des langages non sûrs continue d'augmenter. Pour du nouveau code, c'est de moins en moins facile de justifier de continuer à écrire du C/C++, plutôt que des langages plus sûrs (Rust en particulier) / moins pas sûrs (Go), même si évidemment, il est bien plus facile de trouver des gens qui pondent du code C/C++ que des gens qui pondent même du code Go...
C'est une question de répartition des coûts dans le temps: en temps de codage, Rust est moins productif sur certains aspects que C++, mais certains bugs ne sont pas à debugger puisqu'ils sont éliminés en temps de codage, et il y a moins besoin de déployer des mises à jour de sécurité - ce qui est un processus coûteux si on veut le faire comme il faut - puisqu'il y a moins de vulnérabilités. Ca, c'est très difficile à faire comprendre au management...

Je ne sais pas comment les milieux sécurisés considèrent les outils qui font de nouvelles releases toutes les quelques semaines à quelques mois, et qui se basent sur des librairies open source qui font également au moins 2 releases par an grin
D'un autre côté, cet état d'esprit "il faut que ça ait été testé pendant des mois" est incompatible avec les mises à jour de sécurité des logiciels existants qui sont bourrés de vulnérabilités, il est donc néfaste et doit mourir.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1374

Lionel Debroux (./1373) :
D'un autre côté, cet état d'esprit "il faut que ça ait été testé pendant des mois" est incompatible avec les mises à jour de sécurité des logiciels existants qui sont bourrés de vulnérabilités, il est donc néfaste et doit mourir.
Rien que ça ? grin

Tu es conscient que ça ne s'applique pas partout ? Va dire à un responsable de chaîne de production que tu vas mettre à jour les softs toutes les semaines, avec le risque que ça casse quelque chose et que ça génère des frais importants, pour éviter une vulnérabilité potentielle (qui peut potentiellement être mitigée par d'autres moyens). On va bien rigoler grin

Folco a été invité sur ce sujet.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1375

Surtout quand il y a des contraintes spécifiques. Chez nous en aggro c’est la stérilité, avec la vie des gens derrière. Les satellites de Xim c’est des chèques en millions. Les avions c’est les deux à la fois.
Donc non on ne pousse pas une maj pour le plaisir.

Et même quand on fait des simples bougies de paraffine, les rendements de prod ne peuvent pas être impactés par une mise à jour d’une lib obscure ^^
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

1376

Bah parfois c'est juste que c'est pas tenable par de petites équipes ; je connais des endroits où "on" sait très bien qu'"on" travaille dangereusement mais où les serveurs web tournent sur de l'Ubuntu Server 8.04LTS (donc sans support depuis 2013).
avatar

1377

Il y a des milieux (rares, je pensej'espère) où les mises à jour de sécu se préparent pendant 10 ans (si, si).

Lionel Debroux (./1373) :
D'un autre côté, cet état d'esprit "il faut que ça ait été testé pendant des mois" est incompatible avec les mises à jour de sécurité des logiciels existants qui sont bourrés de vulnérabilités, il est donc néfaste et doit mourir.
Avant de vouloir faire de la sécurité informatique, il faut quand même faire une étude de risques.

Si elle montre que les probabilités d'être attaqué ou que les conséquences d'une telle attaque sont faibles, plus faibles en tout cas que des interruptions de services (ou les bugs) qui seraient plus fréquentes à cause des mises à jour de sécu, ça n'a pas d'intérêt de faire de la sécu.
C'est comme les tests unitaires : ça n'a pas de sens de perdre du temps sur du code dans lequel un bug n'a aucune conséquence notable.

Après, il faut bien soigner son étude de risque grin
N'importe quelle boîte peut se faire attaquer, pour plein de raisons différentes (ransomware, concurrent, employé mécontent, victime collatérale, ou même victime qui sert d'exemple pour la dissuasion informatique, …).
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

1378

pencil
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1379

@Flanker > Oui, l'étude de risque et l'efficacité de l'action est primordiale. Typiquement, vu les risques qu'"on" pouvait avoir, "on" a assuré autant que possible la sécurisation des vecteurs d'entrée les plus courants et les plus impactants (un serveur web isolé qui se fait pirater, c'est moche mais pas grave ; un agent qui ouvre une pièce vérolée qui chiffre des dossiers partagés pour "Tout le monde", c'est critique ; "on" a préféré mettre l'énergie là où c'était critique).
avatar

1380

Ah mais si, il faut absolument installer les mises à jour de sécurité au plus vite, même pour les centrales nucléaires (je connais) et autres éléments critiques grin
Comment ça, il n'y a pas de support sécurité pour les machines des années 1970-1980 qui sont en DS1 et DS2 ?

Ma remarque que vous citez, dans la ligne de la phrase précédente, concernait davantage le côté développement du code (où quelles que puissent être leurs qualités, 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, et des mises à jour de sécurité plus fréquentes que ça - c'est sûr que mieux vaut rester sur du C/C++, utiliser un compilo antédiluvien, ne jamais mettre à jour les dépendances externes...) que le côté déploiement en production, sans filtre, des mises à jour de sécurité.

Ceci étant dit, on sait que le côté production ne va pas du tout. J'ai tendance à penser que l'impact des régressions dues à des mises à jour de sécurité est sur-estimé (sur des dizaines de machines Linux et des années, la plupart dans des DMZ Internet où il faut donc faire un peu attention, je ne me souviens vraiment pas de grand chose de ce type; si ça a cassé indirectement du code peu sûr qui dépendait d'autre code, c'est une bonne occasion de le corriger), et le coût de ne pas faire les mises à jour de sécurité est sous-estimé - bref, l'étude de risque est mal faite.
En lisant les news, on entend parler des responsables de production qui perdent des jours de production, et des données indispendables, à cause d'un ransomware qui a pu s'installer parce que le réseau n'est pas architecturé (tout à plat, ou presque), et que le parc n'est pas géré, et que des machines vulnérables à EternalBlue, BlueKeep et autres vulnérabilités critiques corrigées depuis des mois à des années n'ont jamais été patchées. L'impact de ce genre d'événements (probabilité plus ou moins élevée * gros dégâts) est élevé. Je ne sais plus la proportion, mais pour les PME, une attaque de ransomware ou une exfiltration de données sont un coup très dur, sinon fatal à la structure. Tout ça a un coût, qui est mal pris en compte et mal géré...
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.