Archivi categoria: Patch

Bruce Perens, che accusava Open Source Security Inc. di violare la GPL con le patch Grsecurity, vince la causa

Facebooktwittergoogle_plusredditlinkedin

Avevamo parlato di questa vicenda all’incirca un anno fa: Bruce Perens aveva accusato l’azienda Open Source Security Inc. di violare la licenza GPL. In che modo? Presto detto: l’azienda annoverava tra i suoi prodotti Grsecurity, una serie di patch del Kernel Linux fornite in maniera preventiva e dedicata ai clienti. Queste patch venivano distribuite con licenza GPL, ma con un vincolo: il giorno che il cliente avesse deciso di renderle pubbliche (continuando a rispettare quindi la licenza GPL, che lo prevede) si sarebbe visto precludere l’accesso alle future patch.

A questo punto Perens, dalle pagine del suo blog, aveva accusato Open Source Security Inc. di violazione venendo subito denunciato per diffamazione.

La notizia del giorno è che la causa intentata da Open Source Security Inc. è stata persa e l’azienda dovrà risarcire quasi duecentosessanta milioni di dollari a Perens. E va sottolineato come inizialmente la cifra richiesta da Perens ed i suoi legali fosse enormemente maggiore (più di cinquecento milioni di dollari) e come in fase di giudizio questa sia stata ritenuta irragionevole dal giudice.

Certo, c’è ancora l’appello, ma sicuramente questa prima sentenza stabilisce come non ci sia stata diffamazione nelle affermazioni di Perens, poiché formulate in risposta a problemi che al momento non sono ancora considerati dalla legge.

Probabilmente la domanda giusta da porsi in questa vicenda non è tanto chi abbia ragione in questa specifica causa (che è una causa di diffamazione), quanto piuttosto: è lecito per un’azienda che fornisce un determinato servizio di accordarsi con i propri clienti in modo da non far ridistribuire ciò che viene venduto, poiché ovviamente ne va del business stesso e del valore aggiunto che l’azienda offre al mercato? Il principio stesso delle patch Grsecurity dovrebbe fondarsi sulla proattività, non sul prodotto in sé il quale, essendo GPL, è per natura ridistribuibile.

Il richiamo logico al meccanismo delle subscription di Red Hat è immediato: non è infatti forse questo ciò che ha sempre fatto CentOS? È possibile fondare il proprio business su software GPL senza imporre nulla ai propri clienti? Nel mondo ideale ci sentiamo di dire di sì, dovrebbe.

Kernel Linux: arrivano le prime patch per Spectre V4

Facebooktwittergoogle_plusredditlinkedin

Risale già a qualche settimana fa la scoperta di una nuova falla della serie Meltdown/Spectre da parte dei team di Microsoft e Google ed arrivano anche le prime mitigation nel kernel Linux.

La versione 4.17 rilasciata negli scorsi giorni infatti include anche diverse patch per arginare i problemi che hanno introdotto Spectre e Meltdown:

  • Fix per alcune CPU x86 di produzione cinese;
  • Fix per Spectre per IBM s390;
  • Fix per Spectre V4 per Power7, Power8 e Power9;
  • Fix per Spectre V4 su CPU Intel.

Per il kernel 4.18 sono previste ulteriori patch per mitigare i problemi derivanti dallo Speculative Store Bypass stavolta sulle CPU di AMD che utilizzeranno le direttive SPEC_CTRL / VIRT_SPEC MSR che verranno fornite in futuro dal produttore insieme agli aggiornamenti firmware.

Al momento, questa sembrerebbe anche l’unica mitigation inclusa nel kernel 4.18 che fa riferimento all’architettura x86. Oltre a questa, infatti, sono previsti aggiustamenti anche per Spectre V4 su ARM64 e, finalmente, per Spectre V1/V2 su ARM 32-bit.

Vedremo mai la fine di questa neverending “apply-fix-and-reboot-you-machine” story?

Anche OpenBSD riceve le patch per Meltdown

Facebooktwittergoogle_plusredditlinkedin

Quando ad inizio anno c’è stato il rush di aggiornamenti per Meltdown sui vari OS, parecchi sistemi BSD sono rimasti indietro.

Tra i sistemi Unix-like come – appunto – BSD, sicuramente il fatto di avere una base utente molto più limitata rispetto ad altre controparti (leggi Linux) ha penalizzato molto l’arrivo di queste patch, sia per una disponibilità molto minore di sviluppatori che per una base utente di test molto ridotta.

Qualche giorno fa vi avevamo parlato dell’arrivo delle patch per Meltdown su FreeBSD, che seppur non sia stato il primo di quella famiglia a riceverle (il primo BSD fu DrabgoFlyBSD che le ricevette il 5 Gennaio), sicuramente è uno dei sistemi Berkeley Software Distribution più utilizzati.

Finalmente anche il fratello OpenBSD, famoso per essere tra i più sicuri della famiglia, riceve queste patch disponibili da ieri, come si evince da un commit nel kernel da parte dello sviluppatore Philip Guenther:

When a syscall, trap, or interrupt takes a CPU from userspace to kernel the trampoline code switches page tables, switches stacks to the thread’s real kernel stack, then copies over the necessary bits from the trampoline stack. On return to userspace the opposite occurs: recreate the iretq frame on the trampoline stack, switch stack, switch page tables, and return to userspace.

Quando una syscall, una trap o un interrupt porta la CPU da userspace al kernel, il codice trampolino scambia le tabelle delle pagine, girando lo stack sul reale thread nel kernel, dopodichè copia i bit necessari dallo stack trampolino. Nel ritorno allo userspace, avviene l’inverso: viene ricreato il frame iretq sullo stack trampolino, vengono girati gli stack, scambiate le tabelle delle pagine e si ritorna allo userspace.

Tecnicismi a parte, in soldoni viene utilizzato uno stack intermedio (chiamato trampolino) per il passaggio dei dati, assicurandosi che questo avvenga solo al cambio di contesto, e mitigando quindi l’applicazione delle vulnerabilità che sfruttano Meltdown.

Su diversi forum e sistemi di commenti impazza la discussione che vede due parti contrapporsi: la prima, valutando il fatto che gli sviluppatori BSD siano venuti a conoscenza di questi bug solo da inizio Gennaio (mentre pare che le discussioni su eventuali mitigation nel kernel Linux siano partite diverse settimane prima) denoti la rapidità del fixing da parte di quegli OS, mentre la seconda sostiene che il fatto di avere patch ad inizio Gennaio per tutti gli OS e vedere i BSD arrivarci solo a fine Febbraio indichi sostanzialmente che la forza lavoro su quegli OS sia decisamente ridotta e poco reattiva.

L’importante è avere le patch, alla fine dei conti, ma ci domandiamo: questo ritardo può pilotare la scelta di uno o l’altro OS per ambienti in cui effettivamente avrebbero senso entrambi?

VMware nuova patch di sicurezza vCenter Server 6.5 U1f

Facebooktwittergoogle_plusredditlinkedin

VMware nuova patch di sicurezza vCenter Server 6.5 U1f

vmware-new-security-patch-vcenter-server-65u1f-01

VMware ha rilasciato una nuova patch di sicurezza per il sistema operativo Photon della vCSA – vCenter Server 6.5 U1f build number 7801515 – contro due vulnerabilità relative alle problematiche Meltdown e Spectre.

La nuova patch vCenter Server 6.5 U1f risolve le problematiche bounds-check bypass (Spectre-1, CVE-2017-5753) e rogue data cache load (Meltdown, CVE-2017-5754). Per la vulnerabilità branch target injection (Spectre-2, CVE-2017-5715) non c’è invece ancora nessuna patch.

package aggiornati sono i seguenti:

  • linux 4.4.110-2
  • libgcrypt 1.7.6-3
  • c-ares 1.12.0-2
  • ncurses 6.0-8
  • libtasn1 4.12-1
  • wget 1.18-3
  • procmail 3.22-4
  • rsync 3.1.2-4
  • apr 1.5.2-7

Anche la VMware security advisory VMSA-2018-0007.1 è stata aggiornata con tutti gli aggiornamenti delle appliance virtuali per le vulnerabilità Spectre e Meltdown e attualmente le sole patch disponibili sono per vCenter Server Appliance (6.5 U1f) e per vSphere Integrated Containers (version 1.3.1).

vmware-new-security-patch-vcenter-server-65u1f-02

 

Aggiornamento a vCenter Server 6.5 U1f

Per procedere copn l’aggiornamento della vCSA, bisogna accedere alla management console dell’appliance inserendo le credenziali corrette e cliccando su Login.

vmware-new-security-patch-vcenter-server-65u1f-03

Posizionarsi nell’area Update e cliccare sulla voce Check Updates > Check Repository per verificare la disponibilità di nuovi aggiornamenti.

vmware-new-security-patch-vcenter-server-65u1f-04

Quando il nuovo aggiornamento viene rilevato, cliccare su Install > Install All Updates per procedere con l’aggiornamento.

vmware-new-security-patch-vcenter-server-65u1f-05

Cliccare su Accept per accettare l’EULA.

vmware-new-security-patch-vcenter-server-65u1f-06

Cliccare Install per avviare l’installazione.

vmware-new-security-patch-vcenter-server-65u1f-07

La patch viene installata nella vCSA.

vmware-new-security-patch-vcenter-server-65u1f-08

Quando l’installazione viene completata correttamente, cliccare su OK per riavviare l’appliance.

vmware-new-security-patch-vcenter-server-65u1f-09

L’appliance si riavvia per applicare gli aggiornamenti.

vmware-new-security-patch-vcenter-server-65u1f-10

Dopo che la vCSA ha terminato il reboot, il processo di patching è completo. La build number viene ora indicata come 7801515.

vmware-new-security-patch-vcenter-server-65u1f-11

L’aggiornamento è al momento disponibile solo dal repository.

signature

Copyright Nolabnoparty. All Rights Reserved.

Patch Meltdown/Spectre: tuning da rifare sui server

Facebooktwittergoogle_plusredditlinkedin

Si torna a parlare di Meltdown e Spectre che nelle ultime settimane hanno travolto il mondo dell’IT e dai quali quasi nessuno è riuscito a salvarsi.

Le maggiori distro Linux hanno già rilasciato una serie di patch per arginare il problema ma, come c’era da aspettarsi, le performance del sistemano calano non indifferentemente.

Questo discorso si applica poco alle workstation mentre lato server la situazione è certamente più critica.

Ma di quanto vengono realmente impattate le performance? Dopo i test di Phoronix di cui abbiamo parlato qui (svolti su CentOS, Ubuntu, Debian e Clear Linux) risponde anche RedHat che ha eseguito dei benchmark su RHEL 7/6/5 dopo aver applicato le patch:

  • Alto impatto: cache memoria, buffer I/O e carico sui database OLTP impattati del 8-19%;
  • Medio impatto: Analytics sui database e macchine virtuali Java subiscono un calo del 3-7%;
  • Basso impatto: HPC (High Performance Computing) e carichi di lavoro elevati sulla CPU sono impattati del 2-5%, molti dei job vengono eseguiti nello user space;
  • Impatto minimo: le tecnologie che bypassano il kernel in favore dell’accesso diretto allo user space subiscono un impatto inferiore al 2%.

Questi cali di performance valgono sia per le installazioni bare metal che per le applicazioni containerizzate (visto che sono trattate come processi Linux generici) anche se quest’ultime sicuramente sono più impattate a causa della frequenza più elevata di operazioni user-to-kernel.

RedHat ha anche rilasciato una serie di indicazioni sui fix applicati sui propri sistemi per consentire agli utenti un tuning post-patch più rapido.

La situazione resta comunque grave su innumerevoli macchine ed appliance che utilizzano distribuzioni datate e non patchabili, inclusi tutti i vari dispositivi IoT… che comunque non se la sono mai passata particolarmente bene!

Problemi su Ubuntu dopo le patch per Spectre e Meltdown

Facebooktwittergoogle_plusredditlinkedin

Negli ultimi ultimi giorni Spectre e Meltdown sono al centro di praticamente ogni articolo del mondo IT. I bug, in tre varianti, affliggono tutte le CPU Intel ed AMD (sì, alla fine anche AMD ha ammesso di essere affetta dalle due varianti di Spectre) e trattandosi di falle a livello hardware, i produttori di software stanno correndo ai ripari rilasciando patch su base quasi giornaliera.

Tutta questa fretta sta generando non pochi disagi agli utenti che spesso si ritrovano con macchine che non fanno più boot. Inizialmente c’è stata Microsoft con una patch che rendeva inutilizzabili i computer con CPU Athlon ed ora anche Ubuntu sembra avere qualche inghippo.

Non è un gran momento per la distribuzione di Canonical, infatti questo nuovo problema segue a ruota il bug che impattava i BIOS di alcuni Lenovo per il quale venne inibito il download di ISO per il paio di settimane necessario a risolvere il problema.

Nelle ultime ore gli utenti hanno iniziato a segnalare sia sui forum sia su Launchpad come dopo aver aggiornato Ubuntu 16.04 con kernel 4.4.0-108-generic, la macchina non riesca più ad eseguire il boot.

Canonical suggerisce di procedere come segue:

  1. Avviare con l’ultima versione funzionante del kernel
  2. Rimuovere la patch buggata
  3. Installare l’ultima versione del kernel, la 4.4.0-109-generic tramite apt

State veramente riscontrando problemi dopo Spectre/Meltdown?