patrizio.tufarolo

BlueBorne, milioni di dispositivi Bluetooth sono vulnerabili

Rivelato da Armis Lab, tale vettore di attacco pu˛ permettere ad un malintenzionato di prendere il controllo di PC, smartphone e dispositivi IoT, sfruttando vulnerabilitÓ implementative sul protocollo Bluetooth. Di seguito la nostra analisi tecnica

BlueBorne, milioni di dispositivi Bluetooth sono vulnerabiliRoma - I ricercatori della californiana Armis (Palo Alto) hanno rilasciato un white paper che descrive otto vulnerabilità (per i quali sono disponibili exploit) riguardanti le implementazioni dello standard Bluetooth in Linux (e Android), Windows e iOS.

Raggruppate sotto il nome di BlueBorne (da Bluetooth e Airborne, termine che identifica gli attacchi effettuati per via aerea), sono caratterizzate da una superficie di attacco molto vasta e un impatto potenziale elevato: oltre a influenzare gran parte dei sistemi operativi presenti sul mercato, gli eventuali attacchi non richiedono interazioni con la vittima; tali vulnerabilità, inoltre, consentono la possibile esecuzione di codice arbitrario enon sono risolvibili con modifiche alle configurazioni.

Common Vulnerability Exposure CVE-2017-1000251
Si tratta di una remote code execution su Bluez, il componente del kernel Linux che fornisce le funzionalità relative alla gestione di periferiche Bluetooth. La vulnerabilità, causata da un buffer copiato senza controllarne la dimensione nell'implementazione del livello L2CAP dello stack, colpisce le versioni più recenti del kernel (dalla 3.3-rc1 in poi).
L2CAP è il livello di rete dello stack protocollare di Bluetooth, che offre anche funzionalità avanzate generalmente collocabili nel livello di trasporto (ad esempio la possibilità di gestire la frammentazione dei pacchetti e di gestire politiche QoS).
La comunicazione avviene su più canali logici asincroni, contrassegnati da un Channel ID, l'equivalente di un numero di porta per le connessioni TCP o UDP.
Tutti gli altri servizi (RFCOMM per le comunicazioni seriali, SDP per la discovery dei servizi nell'area circostante, OBEX per il trasferimento dei file) eccetto il servizio Audio sono costruiti sopra al layer L2CAP.
Nello stabilire una connessione L2CAP i due peer possono negoziarne i parametri mediante lo scambio di pacchetti di tipologia L2CAP_ConfReq (richiesta) e L2CAP_ConfResp (risposta) o tramite la funzionalità EFS (Extended Flow Specification).
In tal caso ciascuno dei peer effettua una validazione dei parametri prima di inviare il segnale di conferma per stabilire la comunicazione; nel frattempo, lo stato del peer è PENDING.




╚ proprio qui che sopraggiunge la vulnerabilità: all'arrivo di una richiesta di configurazione, la funzione l2cap_parse_conf_rsp riceve in input un buffer (void *rsp) e la sua grandezza (int len); scompone quindi il contenuto del pacchetto, lo valida e ricompone il pacchetto di risposta.
La dimensione del buffer di risposta, però, non è specificata nella funzione. Il contenuto del pacchetto, inoltre, può contenere dati duplicati e concede all'attaccante di manipolare a proprio piacimento sia la dimensione del buffer che i dati contenuti.

La funzione, invocata da l2cap_config_rsp quando il dispositivo è nello stato PENDING, può essere triggerata inviando una richiesta in cui il campo stype assume il valore L2CAP_SERV_NOTRAFIC, in modo da sostituire il buffer buf allocato con dimensione 64 con uno arbitrario e portare a termine il buffer overflow.




I ricercatori fanno notare come molto spesso una vulnerabilità del genere non porti immediatamente a una remote code execution, in quanto possono essere adottate misure di sicurezza nei confronti del codice come le "variabili canarino" (che, se abilitate, vengono posizionate appena fuori della porzione di memoria da proteggere e hanno il ruolo di segnalare eventuali riscritture fuori dal buffer protetto) e la randomizzazione del kernel space (KASLR); questo, però, non viene spesso applicato soprattutto in dispositivi con quantitativi di memoria limitati.

L'impatto della vulnerabilità, inoltre, è alto poiché il codice iniettato viene eseguito direttamente in kernel-space.

Di seguito un video illustrativo dell'attacco:



CVE-2017-1000250
Tale vulnerabilità consiste in un possibile leak di informazioni su BlueZ dato da una lettura out-of-bound nell'implementazione, questa volta, del protocollo SDP.

SDP, come precedentemente anticipato, è il componente per la discovery dei servizi offerti dai dispositivi bluetooth nelle vicinanze, censiti tramite un meccanismo basato su identificatori univoci sulla base della tipologia di servizio. Anche tale meccanismo è basato su un approccio domanda-risposta; inoltre definisce un metodo di frammentazione proprietario, denominato nella specifica protocollare "SDP continuation", che, qualora il messaggio inviato risultasse di dimensione eccedente rispetto all'MTU negoziato dal sottostante L2CAP, duplica il messaggio appendendovi un tag denominato "continuation state", il cui valore è contenuto nel frammento di risposta ottenuto inizialmente.
Non è ben chiaro perché sia stato implementato un simile metodo di frammentazione, ulteriore alla segmentazione di L2CAP, sta di certo che la sua implementazione in BlueZ presenta qualche problema.




Nel demone bluetoothd di bluez (eseguito in userspace), è presente un errore nella validazione del campo maxByteSent del continuation state (che l'utente può tranquillamente manipolare) che può causare un buffer overflow nell'esecuzione della funzione memcpy, fornendo la possibilità all'utente di leggere dati dallo stack analogamente a quanto accade per l'exploit Heartbleed di SSL.

CVE-2017-0785
Tale vulnerabilità è analoga alla precedente - ancora una volta sull'implementazione di SDP - tuttavia il bug è di natura diversa. Nell'SDP server di Android, la CVE-2017-1000250 non è sfruttabile, a causa del fatto che la frammentazione è implementata in maniera leggermente diversa: è presente un campo cont_offset che contiene l'offset del record SDP inviato per ultimo nel pacchetto.




All'interno del codice, questo valore viene sottratto al numero di record SDP totali (num_rsp_handles), per determinare quelli rimanenti da trasferire, memorizzati in rem_handler, di tipo uint16.

Il valore num_rsp_handles è ovviamente determinato per ogni ricerca, ma a differenza di cont_offset è dichiarato fuori dallo scope della funzione e rimane sempre lo stesso durante la lettura dei vari frammenti. L'implementazione ha come presupposto, quindi, che sia num_response_handles e cont_offset siano riferiti alla stessa risposta effettivamente inviata.

Un attaccante può pertanto creare una situazione di confusione effettuando una ricerca SDP su un servizio, nella risposta (la cui dimensione sarà pari all'MTU della connessione, negoziato su decisione dell'attaccante stesso) otterrà un continuation state che allegherà in una successiva scansione SDP su un servizio differente, la cui risposta sarà di dimensione inferiore.
A questo punto rem_handles, di tipo unsigned, assumerà un valore negativo e andrà in underflow assumendo un valore molto alto se considerato in complemento a due.
Il ciclo successivo, il cui compito è quello di copiare i record trovati nella risposta, avrà un numero di iterazioni molto elevato ed andrà a leggere (ed includere nella risposta stessa) porzioni di memoria fuori dal buffer.

CVE-2017-0781 e CVE-2017-0782
Trattasi entrambe di remote code execution su Android incluse nella gestione del protocollo BNEP (Bluetooth Network Encapsulation Protocol), utilizzato per costruire reti PAN (Personal Area Network) e consentire l'incapsulamento di pacchetti Ethernet in L2CAP.
BNEP supporta sia il trasporto di frame Ethernet (MTU di 1500 bytes) che il trasporto di messaggi di controllo, utili a negoziare la creazione della PAN e alla gestione dei flussi. ╚ possibile includere più messaggi di controllo all'interno dello stesso pacchetto L2CAP, mediante l'utilizzo di "header estesi". Entrambe le vulnerabilità in oggetto riguardano proprio questo aspetto.




La conseguenza della gestione di più header estesi in una volta sola, consiste nel fatto che la connessione può cambiare di stato tra la gestione di uno header e l'altro.
Alcuni di questi, tuttavia, possono essere trattati solo quando la connessione è in uno stato specifico; per gestire tale problematica gli sviluppatori di Android hanno deciso di tenere in memoria la parte del messaggio non ancora trattata per effettuarne il parsing nel momento opportuno, memorizzandola in p_pending_data (tipo BT_HDR, di dimensione 8 byte).
Tale campo è memorizzato nello heap, ed ha lunghezza rem_len (che contiene la dimensione dei dati rimanenti del quale non è ancora stato effettuato il parsing, ed il valore può essere controllato dall'utente agendo sulla dimensione del pacchetto inviato). Successivamente viene effettuato il memcpy della zona di memoria partendo dall'indirizzo di p_pending_data+1, utilizzando rem_len come dimensione. Ciò dà luogo alla prima vulnerabilità: memcpy corrompe lo heap ogni volta che il codice viene eseguito. Il buffer overflow può essere scatenato inviando un pacchetto così formato:




Il campo type è composto dal bit extension_present, che assume valore 1, e dal tipo di frame segnato come BNEP_FRAME_CONTROL (01). Il campo ctrl_type è impostato a BNEP_SETUP_CONNECTION_REQUEST_MSG, per raggiungere la porzione di codice vulnerabile. len viene impostato a 0, per manipolare il campo rem_len, mentre il campo Payload conterrà i byte da iniettare nel buffer.

La seconda vulnerabilità è di nuovo un underflow che risiede nella funzione bnep_process_control_packet, il cui compito è quello di elaborare i pacchetti di controllo e gli header estesi, al fine di riconoscere eventuali sotto-messaggi del messaggio BNEP principale. L'intero rem_len è definito, ancora una volta, come unsigned short a 16 bit.




Manipolando il valore di ext_len (8 bit, unsigned), è possibile mandare in underflow rem_len sfruttando il complemento a due così da fargli assumere valori sull'ordine di 0xff00. Il valore di tale variabile verrà poi utilizzato per assegnare la grandezza al buffer p_buf (pbuf->size), che verrà passato ai layer protocollari sottostanti. Questi si troveranno a gestire un buffer esageratamente grande, che non verrà più controllato e sarà passato alla funzione memcpy così com'è. Il contenuto effettivamente copiato con memcpy non è sotto il controllo dell'attaccante, ma è possibile, in tal caso, realizzare un attacco di tipo heap spray.

Per scatenare l'attacco è possibile inviare un pacchetto così formato:



Il campo type indica BNEP_FRAME_COMPRESSED_ETHERNET, con flag extension_present settato.
ext_len contiene il valore controllato dall'attaccante per causare l'underflow della variabile rem_len. control_type ha valore 0x10 per raggiungere la porzione di codice vulnerabile. Raggiungendo l'underflow, rem_len verrà copiata in pbuf->size che, passato al layer sottostante, chiamerà la callback che eseguirà la memcpy.

Entrambe le vulnerabilità possono causare l'esecuzione di codice remoto, con i privilegi del servizio Bluetooth (com.android.bluetooth).
Tale servizio ha privilegi di accesso al filesystem e controllo completo dello stack di rete a basso livello, può simulare input ed è gestito dal demone Zygote che, anche in caso di crash, ne ripristina l'esecuzione; questo concede all'attaccante di effettuare infiniti tentativi di intrusione.

CVE-2017-0783 e CVE-2017-8628 Bluetooth Pineapple Logical Flaw (Android e Windows)
Tali vulnerabilità consentono di effettuare attacchi man-in-the-middle. La prima, per Android, riguarda le versioni del sistema operativo compilate prima del 9 settembre: Google ha infatti rilasciato la patch per tali vulnerabilità nello scorso security bulletin. La seconda, per Windows, riguarda tutte le versioni del sistema di Redmond comprese tra Windows Vista e Windows 10. Curioso, in tal senso, è il fatto che la stessa tipologia di vulnerabilità sia presente su due sistemi operativi che non hanno nulla in comune; si tratta infatti di un difetto di design dovuto dalla complessità dello stack protocollare, che ha portato gli sviluppatori a seguire fedelmente le specifiche.

In particolare è stata rilevata un'incorretta gestione dei livelli di sicurezza richiesti dal profilo PAN, utilizzato per la costruzione di Personal Area Network così da permettere al protocollo Bluetooth di offrire alcuni servizi di rete come il tethering della connessione Internet.

#define PAN_SECURITY (BTM_SEC_IN_AUTHENTICATE | BTM_SEC_OUT_AUTHENTICATE | BTM_SEC_IN_ENCRYPT | BTM_SEC_OUT_ENCRYPT)

Il livello di sicurezza richiesto è soddisfatto anche solo con BTM_SEC_IN_AUTHENTICATE attivo, senza effettuare autorizzazioni successive.

Gli attacchi sono basati sull'assunzione che l'autenticazione Bluetooth, effettuata tramite il protocollo SMP (Security Manager Protocol) siano facilmente bypassabili. L'attaccante può quindi accedere a profili e servizi per i quali il livello di sicurezza richiede esplicitamente l'autenticazione con uno sforzo piuttosto minimo (specialmente su Android, sfruttando la funzionalità "It Just Works").

Passando i parametri di autenticazione, l'attaccante è in grado di attivare una connessione BNEP ed avviare una connessione PAN dichiarando i ruoli di entrambi i peer. Egli assumerà il ruolo PANU, il ricevente NAP; tuttavia, nel momento in cui il dispositivo ricevente si accorgerà di non poter offrire la funzionalità di tethering, la connessione verrà interrotta. Poiché, tuttavia, i ruoli sono decisi da chi inizia la connessione, possono essere effettuati vari tentativi come illustrato nella seguente matrice:




Invertendo i ruoli, l'attaccante può assumere il ruolo NAP e il ricevente PANU, così da mandare a buon fine la connessione; la vittima sarà quindi in rete con l'attaccante, il quale potrà inviare configurazioni di rete malevole tramite il protocollo DHCP.
Tale attacco è di facile attuazione ed ha un potenziale molto elevato e, soprattutto, non richiede interazione con la vittima. Esso è assimilabile al WiFi Pineapple, perpetrabile soltanto nel caso in cui la vittima sia connessa ad una rete WiFi aperta.

Di seguito il video dell'attacco Pineapple su Windows:



CVE-2017-14315
Questa vulnerabilità riguarda il mondo Apple, coprendo le versioni di iOS precedenti alla 10 e di Apple TV OS precedenti alla 7.2.2. Il protocollo interessato è il "Low Energy Audio Protocol" (LEAP), realizzato da Apple per interconnettere gli auricolari e l'apparato Siri Remote tramite la funzionalità Low Energy introdotta con la versione 4 delle specifiche protocollari Bluetooth.
Nonostante il protocollo sia destinato al solo uso da parte di dispositivi audio di tipo low energy, è di fatto utilizzabile anche con dispositivi classici. Per funzionare, LEAP utilizza 2 specifici Channel ID: 0x2A per le operazioni di controllo della comunicazione e 0x2B per il flusso audio. Le operazioni di validazione controllano soltanto questi due parametri, inoltre i meccanismi di sicurezza di L2CAP non sono supportati, e il traffico dati non è autenticato. I pacchetti audio vengono gestiti da una callback (audio_handler_callback) nella quale è invocata la funzione memcpy senza controllare la dimensione del buffer, provocando un possibile buffer overflow.




Secondo gli esperti di Armis, tale vulnerabilità deriva dall'assunzione che i pacchetti siano sempre grandi 0x68 bytes, come da specifica protocollare; situazione che si verifica sicuramente per le connessioni BLE ma non per le connessioni classiche.
La vulnerabilità non risulta però presente per le versioni attuali dei sistemi operativi di Cupertino, pertanto rimane valida solo per i dispositivi non ancora aggiornati almeno ad iOS 10.

In conclusione
BlueBorne arriva come ennesimo set di vulnerabilità Bluetooth; prima del rilascio delle specifiche protocollari della versione 2.1, infatti, molte erano le problematiche di sicurezza di tale standard dovute a difetti di progettazione. Nessuna di queste, tuttavia, aveva mai riguardato la possibilità di eseguire codice arbitrario.

Armis ha segnalato le vulnerabilità ai principali produttori e alla comunità Linux. Microsoft, avvisata ad aprile, ha rilasciato i propri aggiornamenti lo scorso luglio; i sistemi operativi aggiornati dopo tale data, hanno pertanto già percepito la patch. Apple è stata avvisata solamente ad agosto, le vulnerabilità non sono presenti nelle versioni attuali di iOS ed Apple TV. Samsung è stata contattata diverse volte, ma non ha mai risposto alla chiamata; diverso invece il feedback da parte di Google e della comunità Linux: la patch per Android è arrivata da Mountain View nel security bulletin di settembre, per quanto riguarda il kernel Linux, invece, la segnalazione della vulnerabilità è stata ricevuta dal team di sicurezza il 5 settembre e i manutentori delle varie distribuzioni stanno rilasciando gli aggiornamenti dal 12 settembre (si veda ad esempio il bollettino di Red Hat).

Su Android, gli utenti possono eseguire questo scanner per verificare la presenza della vulnerabilità sul proprio dispositivo.

╚ buona pratica, pertanto, tenere i software costantemente aggiornati ma, come noto, ciò non sempre può corrispondere alla realtà dei fatti: per ragioni di obsolescenza programmata, difficoltà di erogazione degli aggiornamenti su determinate categorie di dispositivi, device che hanno raggiunto la end-of-life, inadempienza degli utenti, rimarranno numerosi i dispositivi "in-the-wild" che non riceveranno mai una patch. Per tali dispositivi occorre rinunciare alle funzionalità Bluetooth, almeno quando non strettamente necessarie.

Patrizio Tufarolo
Notizie collegate
  • AttualitàMicrosoft e le patch di settembreRedmond distribuisce la solita gragnola di aggiornamenti di sicurezza per Windows, Edge, IE e compagnia, update che a settembre riguardano alcune vulnerabilitÓ 0-day molto pericolose. E una falla su Bluetooth giÓ corretta a luglio
46 Commenti alla Notizia BlueBorne, milioni di dispositivi Bluetooth sono vulnerabili
Ordina
  • Ce ne fossero di più di articoli così su PI passerei tutto il giorno a leggerlo!!
    non+autenticato
  • - Scritto da: Luca
    > Ce ne fossero di più di articoli così su PI
    > passerei tutto il giorno a
    > leggerlo!!

    concordo ottimo articolo complimenti quasi magico ( e se lo dico io...) ma aspetto sempre la recensione della nuova versione di Debian (io insisto)
    non+autenticato
  • Quasi tutte le vulnerabilità hanno un denominatore comune il buffer, sono gestioni di basso livello con una ottimizzazione al singolo bit che al giorno d'oggi è eccessiva. L'hardware moderno è tanto veloce che l'utente spesso nenache percepisce il tempo speso a lavorare in background.
    Secondo me sarebbe ora di rinunciare ad un po' di prestazioni abbandonando C e C++ per linguaggi più moderni e di alto livello. C e C++ si dovrebbero ridurre a linguaggi per specialisti tipo l'assembler.

    Una soluzione alternativa sarebbe quella di confinare il parsing dei messaggi in librerie condivise, usate da tutti, verificate e testate da tutti. Ma la tentazione per i programmatori di scendere a basso livello gestendo il singolo bit rimarrebbe.
    non+autenticato
  • Oppure sarebbe meglio che cominciassero a scrivere codice in maniera ordinata e corretta. Gli exploit sui buffer sono causati da codice scritto male, che sia C, assembler o BASIC...
    non+autenticato
  • - Scritto da: 57c93858971

    > Secondo me sarebbe ora di rinunciare ad un po' di
    > prestazioni abbandonando C e C++ per linguaggi
    > più moderni e di alto livello. C e C++ si
    > dovrebbero ridurre a linguaggi per specialisti
    > tipo
    > l'assembler.

    tanto per cominciare si chiama linguaggio assembly... l'assembler è il nome del compilatore che trasforma il sorgente in assembly nel file oggetto con dentro l'opcode... Si, tu è meglio che ti astieni dal programmare e anche dal fare il maestrino Anonimo
    non+autenticato
  • >
    > tanto per cominciare si chiama linguaggio
    > assembly... l'assembler è il nome del compilatore
    > che trasforma il sorgente in assembly nel file
    > oggetto con dentro l'opcode... Si, tu è meglio
    > che ti astieni dal programmare e anche dal fare
    > il maestrino

    LOL. Quando lavoravo in ambienti IBM vent'anni fa tutti lo chiamavano assembler e di tanto in tanto spuntava fuori il saputello a criticare perché non usavano il termine assembly. Però così era e così è:
    https://www.ibm.com/support/knowledgecenter/SSLTBW...

    L'unica cosa che è cambiata da allora è che ormai sei troppo vecchio per lavorare. L'argomento del post per te è OT pensa ad organizzare la partitella impiegati comunali contro pensionati. Ciao ciao.
    non+autenticato
  • - Scritto da: ReEnzo
    > tanto per cominciare si chiama linguaggio
    > assembly... l'assembler è il nome del compilatore
    > che trasforma il sorgente in assembly

    il mio prof di sistemi delle superiori e dell'università lo ha sempre chiamato linguaggio assembler. Quindi caro saputello, non è come dici tu.
    non+autenticato
  • - Scritto da: luca
    > - Scritto da: ReEnzo
    > > tanto per cominciare si chiama linguaggio
    > > assembly... l'assembler è il nome del
    > compilatore
    > > che trasforma il sorgente in assembly
    >
    > il mio prof di sistemi delle superiori e
    > dell'università lo ha sempre chiamato linguaggio
    > assembler. Quindi caro saputello, non è come dici
    > tu.

    La qualità degli insegnanti in Italia è sempre stata molto bassa. Anzi squallida a tutti i livelli.
    Cmq anch'io sento spesso confondere i due nomi, ma quello giusto è assembly e non c'è storia su questo. Però si capisce benissimo il discorso anche con l'altro termine. Ricorda molto la storia sulla differenza tra hacker/cracker/lamer/ecc che per i giornalisti sono tutti hacker e basta. E' una guerra persa dove bisogna rassegnarsi. L'importante è che si trasmetta il concetto del proprio messaggio le parole non contano più. Un emoji e via...
    non+autenticato
  • - Scritto da: ben10
    > - Scritto da: luca
    > > - Scritto da: ReEnzo
    > > > tanto per cominciare si chiama
    > linguaggio
    > > > assembly... l'assembler è il nome del
    > > compilatore
    > > > che trasforma il sorgente in assembly
    > >
    > > il mio prof di sistemi delle superiori e
    > > dell'università lo ha sempre chiamato
    > linguaggio
    > > assembler. Quindi caro saputello, non è come
    > dici
    > > tu.
    >
    > La qualità degli insegnanti in Italia è sempre
    > stata molto bassa. Anzi squallida a tutti i
    > livelli.
    > Cmq anch'io sento spesso confondere i due nomi,
    > ma quello giusto è assembly e non c'è storia su
    > questo. Però si capisce benissimo il discorso
    > anche con l'altro termine. Ricorda molto la
    > storia sulla differenza tra
    > hacker/cracker/lamer/ecc che per i giornalisti
    > sono tutti hacker e basta. E' una guerra persa
    > dove bisogna rassegnarsi. L'importante è che si
    > trasmetta il concetto del proprio messaggio le
    > parole non contano più. Un emoji e
    > via...

    Ah quanto sono moderni i frociono macachi, loro parlano in emoji!!

    Ha ha ha. Diteglielo al tre ... puntini quello scemo, al Bertuccia e allo scomparso Aphex che sono sempre stati stilosi su questa storia.


    Se scrivo tre ... puntini (SEMPRE QUELLO SCEMO) é pedofilo, e UGUALE a tre ... puntini è pedofilo!

    Ma il toglodita pedofilo e pedante, se ne esce con: impara l'italiano tu, e ti mette in bella mostra la tua é sbagliata e si pompa il petto.

    Certo il petto! E l'unica cosa che può ancora pompare! Ha ha ha.
    non+autenticato
  • - Scritto da: luca
    > - Scritto da: ReEnzo
    > > tanto per cominciare si chiama linguaggio
    > > assembly... l'assembler è il nome del
    > compilatore
    > > che trasforma il sorgente in assembly
    >
    > il mio prof di sistemi delle superiori e
    > dell'università lo ha sempre chiamato linguaggio
    > assembler. Quindi caro saputello, non è come dici
    > tu.

    caro stupidotto, non e' che se <personaggio importante a piacere> che 2+2=5 allora e' vero. una cosa e' vera o sbagliata di per se', non in base a chi la dice o in quanti la dicano.
    non+autenticato
  • - Scritto da: 57c93858971
    > Secondo me sarebbe ora di rinunciare ad un po' di
    > prestazioni abbandonando C e C++ per linguaggi
    > più moderni e di alto livello.

    Non necessariamente di alto livello. Mozilla ha creato RUST come linguaggio per questi impieghi, implicitamente memory safe.
  • Stavo per scriverlo: occorrerebbe portare tutto in Rust e... ricompilareOcchiolino
    non+autenticato
  • Patrzio, ti fai un culo così per sciver un articolo veramnte apprezzabile, ma PI ti draà si e no 20 mila lire.... ne vale la pena?
    non+autenticato
  • Si, ne vale la pena. Personalmente non scrivo qua per necessità economicheSorride
    La redazione di un articolo richiede un'attività di analisi critica, studio, raccolta fonti (giuste, sbagliate), traduzione, rielaborazione e sintesi non indifferente che a volte implica l'adozione di approcci introspettivi che difficilmente uno adotterebbe su tematiche così specifiche. L'impegno che ho preso con PI è un'attività di studio ulteriore che altrimenti, vuoi per pigrizia, vuoi per altri impegni, farei in misura minore.
    Inoltre ritengo che le tematiche di cybersecurity, parallelamente alle sfide tecnologiche, debbano essere affrontate mediante divulgazione e sensibilizzazione. Il pubblico di PI è perlopiù di carattere tecnico, lo leggono programmatori e sistemisti, che trovandosi di fronte a un articolo più o meno completo possono fare riflessioni e migliorare i propri approcci sul lavoro. Il beneficio di ciò è evidente. Poi lungi da me avere la pretesa di voler essere una fonte di verità, a volte la frase scritta male o proprio sbagliata mi scappa, però poi magari qualche commentatore mi cazzia e tutti quelli che leggeranno sotto saranno maggiormente consapevoli dell'errore che ho fattoOcchiolino
  • - Scritto da: Patrizio Tufarolo
    > Si, ne vale la pena. Personalmente non scrivo qua
    > per necessità economicheSorride

    e PI se ne approfitta.

    > La redazione di un articolo richiede un'attività
    > di analisi critica, studio, raccolta fonti
    > (giuste, sbagliate), traduzione, rielaborazione e
    > sintesi non indifferente che a volte implica
    > l'adozione di approcci introspettivi che
    > difficilmente uno adotterebbe su tematiche così
    > specifiche.

    Lo so: oh, se lo so. per questo chiedevo perhe' ti sbatti cosi tant.

    > L'impegno che ho preso con PI è
    > un'attività di studio ulteriore che altrimenti,
    > vuoi per pigrizia, vuoi per altri impegni, farei
    > in misura minore.
    > Inoltre ritengo che le tematiche di
    > cybersecurity, parallelamente alle sfide
    > tecnologiche, debbano essere affrontate mediante
    > divulgazione e sensibilizzazione. Il pubblico di
    > PI è perlopiù di carattere tecnico, lo leggono
    > programmatori e sistemisti, che trovandosi di
    > fronte a un articolo più o meno completo possono
    > fare riflessioni e migliorare i propri approcci
    > sul lavoro. Il beneficio di ciò è evidente. Poi
    > lungi da me avere la pretesa di voler essere una
    > fonte di verità, a volte la frase scritta male o
    > proprio sbagliata mi scappa, però poi magari
    > qualche commentatore mi cazzia e tutti quelli che
    > leggeranno sotto saranno maggiormente consapevoli
    > dell'errore che ho fattoOcchiolino

    E con questo, mi ha chiuso la bocca. cheapeau.

    come filosofia sei al livello dei tardi anni ottanta del 20 secolo, quando la Rete era frequentata da gentiluomini tecnici (me la ricordo ene e con nostalgia), sei un po' fuori posto ora in una Rete dove imperversano bimbominchia cazzari.

    Sicuro di non essere una AI emulante un tecnico vero sfuggita dai server di Google? Sorride

    Continua cosi'.
    non+autenticato
  • - Scritto da: ...
    > - Scritto da: Patrizio Tufarolo

    > Continua cosi'.

    sono d'accordo
    non+autenticato
  • - Scritto da: ...
    > Patrzio, ti fai un culo così per sciver un
    > articolo veramnte apprezzabile, ma PI ti draà si
    > e no 20 mila lire.... ne vale la
    > pena?

    Sì, perchè fa CV. Oggi guadagna poco, domani di più
    non+autenticato
  • - Scritto da: luca
    > - Scritto da: ...
    > > Patrzio, ti fai un culo così per sciver un
    > > articolo veramnte apprezzabile, ma PI ti draà si
    > > e no 20 mila lire.... ne vale la
    > > pena?
    >
    > Sì, perchè fa CV. Oggi guadagna poco, domani di
    > più

    mettere nel CV che si e' scritto per PI puo' essere un rischio: se trovi il cazzone che si fa abbindolare e parte con "oooh, scrive su un portale informatico: lei e' assunto!" allora va bene, ma c'e' il pericolo che: "cosa? lei scrive su PI? se ne vada immediatamente o sciolgo i cani".
    ma considerando che la maggior parte della gente sono dei cazzoni ignoranti, si, alla fine gli conviene metrlo su CV. Rischio calcolato Sorride
    non+autenticato
  • non leggevo un articolo così ben dettagliato e da tempi immemori.
    non+autenticato
  • !Il commento contiene una parola troppo lunga.
    uahahhahahahhahahahhahahahhahahahhahahah!
    non+autenticato
  • - Scritto da: ridolini
    > !Il commento contiene una parola troppo lunga.
    > uahahhahahahhahahahhahahahhahahahhahahah!

    Il commianto e morto ridendo della parola troppo lunga!
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 9 discussioni)