Hahaha, très bizzarement (non), Microsoft supprime les exploits de faille sur leur produit (uniquement) de github... Ça devait arriver, c'est arrivé, ça arrivera encore. Gitlab et concort vont, j'espère, avoir le vent en poupe !

Gloups

"An internal shell was included in BIOS image in some ThinkPad models that could allow escalation of privilege. CVE-2020-8320" ...

Une bonne explication de Kr00k, la dernière faille en date de WPA2

Jusqu'à présent, j'utilisait "netstat -tunelp" pour avoir les listes des ports ouverts sur un serveur.
Mais dans le cas d'un bind entre IPv6 et IPv4 (qui est parfois activé par défaut, voir /proc/sys/net/ipv6/bindv6only ) certains processus n'était listé QUE en tcp6/IPv6.

Il se trouve que si le bind est activité, le port est aussi en écoute (ouvert) en tcp/ipv4 ! du coup, j'aurais tendance à utiliser "ss -tunelp" qui LUI me montre un poil mieux (voir le flag v6only à la fin) :

# netstat -tunelp | grep mysql
tcp6       0      0 :::3306                 :::*                    LISTEN      113        31002      2244/mysqld

# ss -tunelp | grep mysql
tcp   LISTEN  0       80                         *:3306                 *:*      users:(("mysqld",pid=2244,fd=17)) uid:113 ino:31002 sk:7e v6only:0 <->

Décorticage d'un cryptominer sur linux assez intéressante :)

J'en avais marre de renouveller mon certificat wildcard à la main ne faisant pas confiance aux API de facon général ... J'ai craqué, ca s'est plutot bien passé, j'ai du coup également étendu mon certificat "m0le.net" dans le "*.m0le.net", plus qu'un certificat à gerer.
Grosso-merdo :
# apt install python3-pip
# cp -r /etc/letsencrypt /etc/letsencrypt.bak/
# apt purge certbot
# pip3 install certbot
# pip3 install certbot-dns-ovh

On genere son token sur : https://eu.api.ovh.com/createToken/ avec les droits (Attention, pour tous les domaines): [GET|PUT|POST|DELETE] /domain/zone/*
# vi .ovh_creds
dns_ovh_endpoint = ovh-eu
dns_ovh_application_key = xxx
dns_ovh_application_secret = xxx
dns_ovh_consumer_key = xxx
# chmod 600 .ovh_creds
# /usr/local/bin/certbot certonly --dns-ovh --dns-ovh-credentials .ovh_creds -d *.m0le.net -d m0le.net

Si tout va bien on devrait avoir un fichier de configuration pour le renouvellement dans /etc/letsencrypt/renewal/

La prochaine fois, pour renouveller il faudra (juste) faire:
# /usr/local/bin/certbot renew

Hum, CVE-2019-5525 : use-after-free or Guest-To-Host (on ALSA enabled backend)

Bon ben... On paaaatch (si dispo - _-)

ah ben tiens, une petite faille du coté de l'iDRAC chez Dell.