Rhaa... non... le même bug que chez Debian: un tout petit bug sur le générateur de nombres pseudo-aléatoire, et c'est la faille SSL.
(<troll> Le plus amusant, c'était les commentaires des BSDiens sur Debian quand la faille était arrivée chez Debian: "Ah, c'est pas chez BSD que ça arriverait. BSD c'est super sécurisé !" </troll>)

EDIT: à propos des générateurs de nombres aléatoires: http://sebsauvage.net/rhaa/index.php?2011/08/25/07/32/33-le-hasard-est-une-chose-difficile-pour-un-ordinateur

GitHub subit actuellement un DDOS.

Ah... pas glop. J'espère juste que des services comme OpenDNS savent contrer les attaques par amplification (même si je ne vois vraiment pas comment).
Ou alors il faudra probablement déclarer son IP sur leur site web avant de pouvoir utiliser leurs DNS   :-/
(source: http://blog.cloudflare.com/good-news-open-dns-resolvers-are-getting-clos)

Haha ! Super EA: Visiblement on peut bidouiller les fichiers côté client dans SimCity... et cela affecte les jeux côté serveur. Conséquence: VOUS POUVEZ FOURTRE LA MERDE DANS LES VILLES DES AUTRES JOUEURS.
Bien joué EA.
On est en 2013, et malgré son jeu qui exige une connexion internet permanente, EA n'a toujours pas compris un des principes de base de sécurité du mode client/serveur: Ne jamais faire confiance aux données client.

Oups...

Ça y est, j'ai enfin réinstallé Certificate Patrol dans Firefox, car ils ont enfin implémenté ce que j'attendais: La possibilité d'ignorer certains changements de certificats pour des domaines spécifiques, tant que l'autorité racine ne change pas (merci à Google qui - avec ses CDN à la con - n'est pas foutu d'avoir des certificats synchronisés sur ses différents serveurs pour un même domaine -- d'où des alertes incessantes avec les anciennes versions de CertPatrol.)

Pour ceux qui ne seraient pas au courant du problème posé par les certificats racines SSL, je vous recommande la lecture de ces articles:
http://sebsauvage.net/rhaa/index.php?2010/08/18/11/16/54-des-extensions-firefox-pour-controler-les-certificats-https
http://sebsauvage.net/rhaa/index.php?2010/11/08/19/54/41-je-suis-content-d-utiliser-certpatrol

Avec ce qui se passe de nos jours (surveillance des gouvernements, vente de matériel de surveillance, certificats frauduleux, autorités racines douteuses ou piratées...), je considère que cette extension devient aussi indispensable que WOT ou AdBlockPlus.

LOL.

Et voilà une nouvelle source pour le Rainbow Cracking.
http://crackstation.net/

Sauf que - je le répète - si votre système de stockage de mots de passe utilise un salt, ces jolies tables de hash sont inutilisables pour retrouver les mots de passe.

Tiens... la nouvelle version d'Avast vérifie la version des logiciels installés afin de vous prévenir de vulnérabilités. D'autres éditeurs ont-ils eu cette excellente idée ? Parce que c'est un des points d'entrée majeur des infections: Je veux parler de vieilles versions de Java, Flash, Shockwave et autres.

LOL

CloudFlare donne les raisons techniques de sa panne (cf.http://sebsauvage.net/links/?URz2-w). S'il y a une chose à leur crédit, c'est qu'ils sont toujours totalement transparents quand il y a des problèmes ou des piratages chez eux. C'est à ce prix qu'ils gagnent la confiance de leurs clients.
Et ils ont raison: La sécurité par l'obscurité ne marche pas.

Si vous pensiez vous mettre à l'abri des scans en déplaçant le port de votre serveurs ssh de 22 à 2222, vous avez tout faux. Tout le monde utilise déjà 2222. Prenez carrément des ports beaucoup plus élevés (hé... vous pouvez aller jusqu'à 65535 !), et surtout n'oubliez pas: Installez fail2ban !
(ou encore, connectez-vous avec des certificats et désactivez les mots de passe.)

Voilà (coucou tester): Java est désormais la principale source d'infection.

J'étais complètement passé à côté de ça (merci Nono): Malekal et botnets.fr se sont associés pour lancer ce site à destination du grand public pour sensibiliser les internautes à la sécurité. Je ne peux qu'approuver (ayant moi-même fait ce genre de page, mais sans doute en moins didactique et attrayant: http://sebsauvage.net/safehex)

Mais enfin... NON !  On utilise JAMAIS un UUID comme token !  Rhhâââ...
Les UUID offrent la garantie d'unicité, mais en **aucun cas** d'aléa non prédictible.
Ou alors il faut recourir à des fonctions crypto, par exemple en concaténant un salt à l'UUID et en hashant le tout (sha1 ou autre). Là on a un token assez solide (et résistant à l'attaque d'anniversaire). L'idéal étant tout de même un véritable générateur aléatoire, mais ce n'est pas à la portée de tous.
(Et là je viens de m'apercevoir que dans Shaarli, comme un con, j'ai oublié d'ajouter un salt avant de hasher pour générer les tokens ...  doh. Rassurez-vous, le risque sécurité est très faible (Je vois mal quelqu'un lancer une attaque d'anniversaire à travers une attaque CSRF... ou alors je me trompe ? En javascript ? ça me paraît assez peu réaliste.)

(Oui j'ai bien conscience que j'ai dû perdre quelques lecteurs depuis le début de cet article.)

EDIT: Si vous voulez patcher Shaarli tout de suite, dans la fonction getToken() modifiez la ligne:
$rnd = sha1(uniqid('',true).'_'.mt_rand());
en:
$rnd = sha1(uniqid('',true).'_'.mt_rand().'####CE QUE VOUS VOULEZ, ÇA PEUT MÊME ÊTRE ASSEZ LONG####');

Et voilà. Bye bye l'attaque d'anniversaire.

Un bug de "privilege escalation"... provoqué par un pilote de carte graphique. Doh.

Bloqué à 200 km/h pendant 200 km dans sa Renault Laguna.
Mais à part ça, tout va bien, les millions de lignes de code des automobile n'ont pas de bug. Non non, ce n'est pas possible.
EDIT: ça pourrait être une manœuvre de la part du conducteur (merci : http://www.courrier-picard.fr/courrier/Actualites/Info-regionale/Miracule-mais-sans-permis-de-conduire (via g.neuromancien.free.fr)

Pourquoi, hein, pourquoi les Chinois ont-ils le plus gros taux d'infection par des malwares ? Parce que ce sont les plus gros utilisateurs d'Internet Explorer.
Et quand je parle d'IE, je parle aussi d'IE6. Oui oui, vous avez bien lu.
Quand IE6 est à 0,4% aux USA ou 0,1% en Norvège, est il à 21,3% en Chine (!).
(source: ie6countdown.com)

Et vous vous doutez bien que s'ils sont aussi en retard sur les navigateurs, ils doivent avoir aussi plusieurs versions de retard sur Flash, Java et Acrobat Reader.  Je vous laisse imaginer la boite de pétri que ça donne.  Pouah.

Et après ont s'étonne de voir des attaques ou du spam venir d'IP chinoises...

Cette page recense différentes formes d'attaque (dont XSRF). Pas encore eu le temps de lire mais ça a l'air bigrement intéressant.
Ça explique aussi la raison pour laquelle Google ajoute while(1); au début de tout json renvoyé par des services comme GMail: http://stackoverflow.com/questions/3146798/why-do-people-put-code-like-throw-1-dont-be-evil-and-for-in-front-of

à mon avis, une lecture à garder sous le coude sur la sécurité web.

Héhé... Je n'avais pas regardé mes logs de connexion Shaarli, et j'y ai vu ça:

2012/08/18_13:51:38 - 82.242.x.x - Login successful
2012/08/18_14:39:50 - 82.242.x.x- Login successful
2012/08/18_15:18:02 - 92.147.x.x- Login failed for user sebsauvage' --
2012/08/18_15:18:17 - 92.147.x.x- Login failed for user sebsauvage" --
2012/08/18_15:38:51 - 82.242.x.x- Login successful
2012/08/18_16:10:54 - 82.242.x.x- Login successful

C'est mignon   :-D

Héhé... le patron de Mega offre 10 000 euros à qui arrivera à casser la sécurité de sa nouvelle plateforme.
Y'a pas à dire, il sait communiquer. C'est une bonne manière de contrer les très nombreuses critiques envers le nouveau Mega.

Sauf Flash ?   :-/
C'est quand même l'une des principales sources d'infection.

Énorme. Absolument énorme. Les mots de manquent. Ça c'est du business de pro. Leur offre "cloud" me semble d'autant plus tentante.
(merci à Jérôme R. pour la capture).
EDIT: Nous sommes en novembre 2013, SFR n'a pas changé: http://bluetouff.com/2013/11/20/le-message-hilarant-de-linterface-de-gestion-des-dns-chez-sfr-business-team/

Mega répond sur les nombreuses critiques concernant la faiblesse de leur crypto et leur sécurité.

moui, à voir: https://detectify.com