Cloudbleed e SHAttered

Questa settimana è stata molto critica per il mondo della sicurezza, infatti sono successe 2 cose molto importanti.

Cloudbleed

Il 17 Febbraio 2017 è stato scoperto un bug di sicurezza nel reverse proxy di Cloudflare che causava la fuoriuscita di dati residenti in memoria come cookies HTTP, tokens, data in POST, ecc…
La scoperta è stata fatta da Tavis Ormandy facendo immediatamente il giro del mondo, il tutto è degenerato quando si è scoperto che questi dati sono stati salvati nelle cache dei vari motori di ricerca (Cloudflare ha collaborato con Google per mitigare questo effetto collaterale).
Attualmente navigando tra la cache di Bing e Yahoo si può ancora incorrere in qualche frammento di memoria sparso tra il contenuto in quanto è difficile riconoscerlo sistematicamente (e quindi eliminarlo).

SHAttered

Il 23 Febbraio 2017 Google ha annunciato la prima collisione in SHA-1, che cosa vuol dire? Quando 2 file diversi hanno lo stesso hash siamo davanti ad una collisione e Google infatti è riuscita a creare 2 PDF diversi con lo stesso SHA-1.
SHA-1 (come altri sistemi di hashing) viene usato per dimostrare che un determinato file non è stato modificato oppure che è stato scaricato correttamente, le implicazioni di sicurezza sono ovvie.
Divertente come WebKit abbia messo in crisi la propria repo SVN committando un test riguardante proprio le collisione SHA-1.
Git è meno sensibile alle collisioni SHA-1 in quanto i 2 file dovrebbero avere anche le stesse dimensioni (rendendo la sfida molto più difficile).

GitLab cancella accidentalmente il database di produzione

Se andate su GitLab adesso troverete il seguente messaggio:

GitLab.com is currently offline due to issues with our production database.
We’re working hard to resolve the problem quickly. Follow GitLabStatus for the latest updates.

Comunicando attraverso Google Docs scopriamo maggiori dettagli:

  • LVM snapshots are by default only taken once every 24 hours. YP happened to run one manually about 6 hours prior to the outage
  • Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored. According to JN these don’t appear to be working, producing files only a few bytes in size. It looks like pg_dump may be failing because PostgreSQL 9.2 binaries are being run instead of 9.6 binaries. This happens because omnibus only uses Pg 9.6 if data/PG_VERSION is set to 9.6, but on workers this file does not exist. As a result it defaults to 9.2, failing silently. No SQL dumps were made as a result. Fog gem may have cleaned out older backups.
  • Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.
  • The synchronisation process removes webhooks once it has synchronised data to staging. Unless we can pull these from a regular backup from the past 24 hours they will be lost
  • The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented. The staging DB refresh works by taking a snapshot of the gitlab_replicator directory, prunes the replication configuration, and starts up a separate PostgreSQL server.
  • Our backups to S3 apparently don’t work either: the bucket is empty

So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.

A quanto pare le repo sono salve mentre non si può dire la stessa cosa per gli issues e i merge requests, morale della favola?
E’ giusto fare i backup ma è altrettanto importante testarli!

UPDATE: GitLab ha scritto un post dopo la tempesta. Un applauso per la trasparenza e per il modo in cui hanno affrontato il problema.

Fossdroid.com è ora open source

Ciao ragazzi,
dopo aver ricevuto un sacco di mail a riguardo ho provveduto a rendere open source il codice di Fossdroid.com.

Enjoy!

NetBeans: dark look and feel with Darcula LAF

Darcula is a dark look and feel that first appeared in the 2012 release of IntelliJ IDEA 12 and now it’s available for NetBeans thanks to Revivius (plugin owner) and to Konstantin Bulenkov (for open sourcing original Darcula LAF).

If you want more info about Darcula LAF you can read the interview with Konstantin Bulenkov.

TIM decurtazione credito traffico promozionale

Bene ragazzi,
vi avviso che se vi siete visti decurtare tutto o parte del credito telefonico da parte di TIM, dovrete lottare un sacco per ricevere un rimborso (e non parliamo nemmeno di un bonus per il disservizio causato).
Praticamente il 30 Ottobre, a causa di un apparente problema della TIM, chi ha piani con connessioni dati flat o pseudo tali (es: Tim Special e compagnia bella dove con un fisso mensile vi danno 1/2/x Gb al mese) si è visto decurtare parecchi euro (o tutti) dalla propria SIM.
Io me ne sono accorto per caso in quanto avevo lasciato il cellulare a casa per andare a fare una camminata ed al rientro non avevo più la connessione dati, da li a poco ho ricevuto un simpaticissimo SMS:

TIMInforma: Il tuo credito è quasi esaurito. Per avere 5 euro di CREDITO da Tim che restituirai alla prima ricarica (+costo 1,5E) rispondi SI

Con mezzi di fortuna riesco a connettermi ad internet per andare su MyTIM e vedo questo:

Inutile dire che la rabbia ha preso il sopravvento, dopo aver bombardato l’assistenza TIM (ricevendo risponde evasive), il giorno dopo scopro che la decurtazione è avvenuta a causa di “traffico promozionale”:

Da poco ho avuto conferma che TIM ammette l’errore e procederà con un eventuale rimborso, stay tuned!

Aggiornamento 31 Ottobre 2016: Ricevuto appena adesso un SMS che chiude definitivamente la questione:

Gentile cliente, ti informiamo che a seguito di un errato addebito del 30/10/2016 abbiamo effettuato un rimborso sulla tua linea. Grazie

Aggiornamento 4 Novembre 2016: Ricevuto ulteriore SMS dalla TIM che mi avvisa che per scusarsi mi regalerà 3Gb di Internet per 3 mesi (senza rinnovo automatico):

Gentile cliente, per scusarci ancora dell’errato addebito nei giorni scorsi, riceverai in regalo 3 GIGA di internet per 3 mesi. Nella prossime ore un SMS ti confermerà l’attivazione.