Come Risolvere L'Errore "Content Not Available Yet" (Opensea)

Uno degli errori più frequenti e fastidiosi di Opensea è sicuramente "Content Not Available Yet", in cui praticamente non ci viene mostrato il nostro NFT. Nella maggior parte dei casi si tratta di un bug, in altri casi si verifica quando quella collezione non è ancora pienamente supportata dal punto di vista visivo. Chiaramente il nostro NFT in realtà un'immagine ce l'ha sempre ma non viene visualizzata. Se si tratta di un bug e non di problemi di compatibilità, risolvere quest'errore è incredibilmente facile. Sostanzialmente si tratta della cache di Opensea che risulta essere non aggiornata per quel NFT.

Schiaccia sul tuo NFT che non viene visualizzato e dopo aver fatto questo basta schiacciare su "more" (appena sotto il tasto SELL) e poi su "refresh metadata".

Fatto questo aspettate circa 20/30 secondi e il vostro NFT dovrebbe comparire.

Come Funziona Egld: Scalabilità e Il Problema Centralizzazione

Pochi giorni fa, a causa di un bug di Egld su Maiar, qualcuno è riuscito a far scendere il prezzo di Egld da 75$ a circa 5$. Sono stati generati più di 1 milione e 600mila Egld, poi dumpati sul dex grazie ad uno smart contract. Il prezzo è dumpato del 92% in circa 40 minuti. Il guadagno è derivato da operazioni di arbitraggio. In seguito i dev hanno bloccato il dex, mettendolo offline.

Uno dei più grossi problemi di Egld infatti è la centralizzazione e questa l'abbiamo visto anche in passato sempre sul Maiar Exchange. Gran parte dell'infrastruttura è "interna" sia per quanto riguarda le dapps che per il wallet Maiar. Già al lancio di Maiar c'erano stati enormi interrogativi, principalmente a dicembre 2021. Dopo una manutenzione programmata, ci sono stati problemi tecnici che hanno costretto lo staff di sviluppatori a mettere offline la piattaforma (conseguenza di ciò? Prezzi in picchiata del token del dex e di Egld). Il CEO Beniamin Mincu a dicembre 2021 aveva rassicurato tutti sul disservizio, dicendo che i fondi erano al sicuro:

"Abbiamo solamente trovato un complicato bug nel sistema di calcolo delle ricompense per i pool di liquidità, che creava una discordanza tra la liquidità attuale depositata nei pool e quella calcolata dal sistema, di conseguenza si è anche verificata una discordanza anche dei rispettivi APR.

Il fatto più importante da sottolineare è che nel grande schema delle cose, l’unico modo per assicurarsi che siate sul pezzo, e possiate continuare a spingere per migliorare le cose, è porre la massima enfasi e rispetto per la sicurezza. In particolare questo è vero quando la complessità di un prodotto è fuori scala, come nel caso del dex di Maiar"

Egld, rebrandizzato con questo nome dopo il cambio di supply (in precedenza era conosciuto come Elrond), è una delle chains più scalabili grazie al suo Secure Proof Of Stake e allo sharding (frammentazione della chains in "shards" che velocizzano validazioni di blocchi e transazioni). 

Il Secure Proof Of Stake vede validatori random (in base al numero dei token in staking e al punteggio reputazionale che aumenta all'aumentare delle validazioni corrette nel tempo, senza comportamenti malevoli) validare i blocchi sullo shard dove si trovano. I validatori ogni 24 ore vengono mischiati sui vari shards mediante "shuffle", per motivi di sicurezza.

La chain utilizza l' "Adaptive State Sharding" con un numero variabile di shards (gli shards aumentano all'aumentare dell'utilizzo del network) e la metachain (chain centrale di coordinamento). Gli shards variabili ottimizzano il network, la transazione una volta validata sullo shard viene inviata sulla metachain. La latenza del protocollo di comunicazione tra gli shards è zero quindi gli smart contract sono istantanei. Gli smart contract sono Arwen VM (tanti linguaggi di programmazione) e possono diventare compatibili con Ethereum tramite qualche operazione. Il token Egld ha una supply iniziale di 20 milioni e può raggiungere l'hard cap massima di 31.5 milioni (in realtà il numero sarà minore perchè con l'utilizzo del network le fee di transazione vengono sottratte dall'emissione di supply e distribuite agli stakers).

Il Bug Dell'Anno 10.000 Sui Software (Y10K)

E' vero, sicuramente noi, non saremo ancora in vita per documentarlo inoltre le tendenze tecnologiche suggeriscono che entro l'anno 10.000, è altamente improbabile che una qualsiasi delle tecnologie o software di elaborazione dati siano ancora in uso, tuttavia rimane un problema che oggi presenta delle criticità ed ha risvolti interessanti dal punto di vista informatico.
Vi siete mai chiesti, a livello di software e sistemi, cosa succederà nell'anno 10.000?
In primis va sottolineato che è molto plausibile che i calendari attualmente in uso siano sostituiti da qualcos'altro.
Tuttavia, va detto che gli anni a cinque cifre sono già oggi un problema per molti programmi di analisi lungimirante (ad esempio software che esaminano la gestione a lungo termine delle scorie nucleari).
Il problema dell'Anno 10.000 (noto anche come problema Y10K) riguarda bug di formattazione e archiviazione del tempo che emergerebbero allo scoccare dell'anno 10.000 (in quanto a cinque cifre).
Questo problema può essere visualizzato in Microsoft Excel dalla versione di Office 2013 in poi, che memorizza le date come il numero di giorni dal 31 dicembre 1899 (il giorno 1 è il 1900-01-01).
Allo stesso modo, Microsoft Access memorizza le date come il numero di giorni dal 30 dicembre 1899 (il giorno 1 è il 1899-12-31).
In entrambe le applicazioni, un valore di 2958465 verrebbe formattato correttamente come "31 dicembre 9999", ma aggiungendo 1 per passare alla data prevista del "1 gennaio 10000" si causerebbe un errore di formattazione; in Excel, ad esempio, verrebbe visualizzato nella cella come una serie di #characters.
Inoltre, Excel non può convertire automaticamente stringhe con formato data "12/12/2007" in date, se l'anno supera il 9999.
La Long Now Foundation si è imbattuta in questa limitazione di Excel durante la progettazione dell'orologio da 10.000 anni (la società sta tentando di promuovere l'abitudine nello scrivere anni con 5 cifre: tipo 02018. Ci sarebbe però un discreto problema con l'anno 100.000...).
Il programma open source OpenOffice Calc è in grado di visualizzare correttamente le date oltre l'anno 9999 con anni a cinque cifre, ma almeno dalla versione 2.4 cade vittima del problema dell'Anno 32.768: il "31 dicembre 32.767" è la data più alta disponibile.
Il 32767 è il numero positivo più alto che può essere rappresentato usando un intero con segno a 16 bit, aggiungendo uno a questo valore si provoca l' overflow e Calc interpreta l'anno come un numero negativo grande ovvero il "1 gennaio - 32.768" .
Anche Python supporta date da 1 cifra a 4.


DIFFERENZE CON IL MILLENNIUM BUG
A differenza del problema dell'anno 2000, in cui le cifre significative sono state omesse, la risoluzione del problema dell'anno 10.000 non richiede l'aggiornamento dei vecchi record, poiché sono presenti tutte e quattro le cifre significative. Richiederebbe solo che la memorizzazione dei record in decimali sia in grado di memorizzare cinque o più cifre.
Esiste, tuttavia, un potenziale problema con i set di record che fanno uso dell'ordinamento lessicale. Ad esempio, le rappresentazioni di date nell'intervallo 10.000-19.999 apparirebbero interlacciate con le date nell'intervallo 1000-1999 anziché successive all'anno 9999.

Quali Problemi Accaddero Durante Il Millennium Bug? (Y2K)

Nel 1999 non si fece altro che parlare del tanto temuto Millennium Bug che sarebbe accorso allo scoccare della mezzanotte, con l'entrata quindi del nuovo millennio.
TG, film, serie TV, giornali, riviste e qualsiasi mezzo di comunicazione dedicava sempre uno spazio più o meno ampio a questo evento.
L’allarmismo era davvero ai massimi livelli.
Principalmente questo errore risiedeva nel fatto che, per rappresentare le date, diversi software utilizzavano solo due cifre decimali per memorizzare l'anno; tali cifre potevano assumere i valori compresi da "00" a "99", dando per sottinteso, come base di partenza, l'anno 1900.
Quindi al raggiungimento dell'anno 2000, i sistemi avrebbero segnato l'1 gennaio 1900.
Il problema di fondo dell’utilizzo di un numero ridotto di cifre (2 al posto di 4), rappresentava la necessità di utilizzare il numero minore di byte di memoria possibile (del resto la capacità di memoria dei sistemi operativi era molto ridotta, se rapportata a quello di oggi. E non solo perchè poi i software si sono evoluti).
In realtà alcuni problemi comparvero già 12 anni prima ovvero nel 1988, quando un lotto di carne in scatola era stato rifiutato da un supermercato perché sembrava essere scaduto da più di 80 anni.
Quattro anni dopo (nel 1992), Mary Bandar di Winona, nel Minnesota, fu invitata a frequentare una scuola materna perché, secondo il computer, aveva 4 anni.
In realtà ne aveva 104 anni quindi declinò l'invito.
Dal 1951, quando Joe Lyons introdusse i primi computer aziendali, le date come detto erano state abbreviate per risparmiare spazio ed accelerare l'elaborazione: il secolo venne omesso, quindi il gennaio 1900 era 01/00 e il dicembre 1999 era il 12/99, così come è ancora oggi sul fronte di ogni carta di credito.
In realtà quella carne in scatola aveva una data di scadenza del gennaio 2000 e Mary Bandar nacque nel luglio 1888; queste date, 01/00 e 07/88, assomigliavano al gennaio 1900 e al luglio 1988, rendendo la carne scaduta da 88 anni (del resto il fatto successe nel 1988) e la 104enne Maria ringiovanita al punta da esser invitata per frequentare l'asilo nel 1992.


QUALI PROBLEMI PROVOCO' IL MILLENNIUM BUG?
Il costo totale dell'aggiustamento software e sistemi operativi svolti in previsione dell'Y2K è stato stimato di oltre 300 miliardi di dollari (oggi circa 426 miliardi di dollari oggi, presa in considerazione l'inflazione).
IDC ha calcolato che gli Stati Uniti spesero circa 134 miliardi di dollari (190 miliardi di dollari oggi).

Non successero eventi catastrofici/apocalittici come descritti all'avvicinarsi dell'evento, anche se qualche problema accorse, vediamone i principali.

-ci furono problemi nello United States Naval Observatory che gestisce il master clock (ora ufficiale del paese), diede la data sul suo sito Web come 1 gen 1900

-problemi in un centinaio di slot machine nel Delaware, USA

-sempre negli Stati Uniti, il sistema di elaborazione dei messaggi della Guardia costiera venne interrotto

-alla base offshore delle forze aeree a sud di Omaha, nel Nebraska, non fu possibile accedere alle registrazioni delle parti di manutenzione degli aeromobili

-ci furono interruzioni di corrente alle Hawaii

-all'aeroporto nazionale di Reagan, le linee di attesa del check-in si sono allungate dopo che i programmi di smistamento bagagli sono stati colpiti

-in Giappone alcuni sistemi di raccolta di informazioni di volo ebbero diversi problemi

-a Ishikawa, in Giappone, le apparecchiature per il monitoraggio delle radiazioni smisero di funzionare a mezzanotte; tuttavia, i funzionari dichiararono che non c'era nessun rischio per gli abitanti

-la centrale nucleare di Onagawa ebbe qualche problema di raffreddamento, non a caso suonò l'allarme 2 minuti dopo mezzanotte

-ad Osaka, Giappone, una compagnia di telecomunicazioni, ha riscontrato errori nella parte di gestione delle date della rete aziendale. Il problema venne risolto alle 02:43

-NTT DoCoMo , il più grande operatore di telefonia mobile del Giappone, riferì che il 1° gennaio 2000 alcuni modelli di telefoni cellulari stavano cancellando nuovi messaggi ricevuti, anziché i vecchi messaggi, a mano a mano che la memoria si riempiva

-sempre in Giappone, circa il 5% degli erogatori di contanti dell'ufficio postale non funzionò e si ebbero problemi anche negli uffici meteorologici

-a Sheffield, Regno Unito, ci furono valutazioni errate del rischio per la sindrome di Down inviate a 154 donne gravide e sono stati effettuati due aborti come risultato diretto del bug Y2K (errore di calcolo dell'età della madre). Quattro bambini affetti da sindrome di Down sono nati da madri a cui era stato detto che si trovavano nel gruppo a basso rischio (cioè praticamente zero le possibilità che succeda una cosa del genere)

-nel Regno Unito ci furono anche problemi con le transazioni di denaro

-sempre nel Regno Unito, le macchine per le biglietterie automatiche ("Quickfare") stamparono i biglietti con la data "00 JNR 00" per 3 mesi fino a metà marzo 2000. Questi erano incompatibili con gli ATG presso la stazione ferroviaria di Reading

-il sistema missilistico antiaereo del Regno Unito Rapier presentava un errore Y2K che gli avrebbe impedito di sparare

-molti sistemi di carte di credito e bancomat andarono in crash. Alcuni clienti hanno ricevuto fatture con 100 anni di interesse

-la stazione di pompaggio dell'olio a Yumurtalik fallì, tagliando le forniture a Istanbul

-i computer del governo andarono in crash in Cina ed ad Hong Kong

-un cliente di un negozio di noleggio video dello stato di New York si trovò sul conto $ 91.250

-anche in Australia si ebbero problemi con il sistema di convalida dei biglietti dell'autobus

-tribunali in Sud Corea e Spagna che riportavano documenti datati 1900

-in Italia i principali problemi li ebbe la Telecom con alcune bollette che riportavano la data 1900

-in Francia, il servizio nazionale di previsioni meteorologiche, Météo-France, indicò che la data sulla loro pagina Web mostrava una mappa con le previsioni del tempo di sabato "01/01/1900"

-in Bulgaria, i documenti di polizia sono stati emessi con le date di scadenza del 29 febbraio 2005 e del 29 febbraio 2010 (che non sono anni bisestili)

-alcuni software non hanno riconosciuto correttamente il 2000 come anno bisestile e hanno quindi lavorato su un anno di 365 giorni. L'ultimo giorno del 2000 (giorno 366) questi sistemi hanno mostrato vari errori trovandosi sfasati (31 dicembre 2000 e 1 gennaio 2001). In particolare alcuni treni norvegesi si ritrovarono ritardati fino a quando i loro orologi non furono rimessi indietro di un mese

Il Carattere Indiano Che Fa Crashare Gli iPhone

Da qualche settimana, come tutti saprete, un carattere indiano riusciva a crashare l'iPhone.
Il bug in questione si manifestava con il carattere della lingua telugu, parlata dal 5% della popolazione in India.
Se veniva ricevuto o incollato in un campo di testo (anche app del calibro di WhatsApp, Twitter, Instagram, etc), poteva causare il crash delle applicazioni o dell'intero sistema operativo.
Nel momento in cui il carattere in questione veniva visualizzato all'interno di un'app di iOS, questa andava in crash continuando a chiudersi ad ogni riavvio (come un loop infinito).
Nel caso in cui il sistema operativo mobile di Apple avesse provato a mostrarlo attraverso una notifica, sarebbe stato l'intero software di sistema che gestisce la Home a bloccarsi.
Infatti il rischio in questo caso è che iPhone o iPad entrino in un tunnel di continui riavvii e blocchi, dovuto al fatto che il carattere non sparisce mai dalle notifiche non lette.
Dunque, come era lecito attendersi, Apple è intervenuta rapidamente sul problema.
L'azienda di Cupertino infatti, 10 giorni fa, ha rilasciato iOS 11.2.6 e macOS 10.13.3, che "fixano" il problema, poi è stata la volta anche di watchOS 4.2.3 e di tvOS 11.2.6.

Scoprire L'Identità Di Una Persona Grazie All'Immagine Profilo (WhatsApp Bug)

Federico Ziberna e Claudio Cavalera, ricercatori indipendenti, hanno descritto la possibilità di effettuare un genere completamente nuovo di attacco quindi di violazione della privacy, basato sulle immagini utilizzate dagli utenti come avatar su WhatsApp e Viber.
Tutto ciò grazie ad un bug/exploit delle famose app di messagging che permetterebbe di salvare migliaia di foto e poi di confrontarle con immagini reali o con altre presenti sui social network.
In poche parole si potrebbe associare una persona al numero di telefono, grazie all'avatar.
I due autori hanno utilizzato come chiave di ricerca la foto-profilo di un utente, assieme ad altri dati estrapolabili dalla stessa immagine, grazie ad esempio ad algoritmi di riconoscimento facciale (per individuare età o sesso) per confrontare la foto con immagini reperibili in rete (grazie anche alla ricerca per immagini di Google) o su altri account.
E' stato utilizzato un sistema che consente di scaricare liberamente illimitati avatar (milioni di foto) collegati ad account di utenti, per "illustrare agli utilizzatori del web possibili scenari di eventuali violazioni della loro privacy o riservatezza rispetto a delle informazioni che anche involontariamente possono condividere" via social e su Internet.
Sono stati testati 200 milioni di numeri e sono stati trovati 10 milioni di contatti (numeri telefonici registrati sulle due App).
Il tool riesce a raccogliere e memorizzare in maniera automatica un numero illimitato di avatar da WhatsApp e Viber utilizzate da utenti registrati alle due App di messaggistica.
Una volta raccolti, tali avatar "sono stati catalogati ed elaborati con algoritmi di riconoscimento facciale, confronto, analisi e ricerca sul web".
Visto che le App succitate fanno riferimento alla rubrica di un utente e verificano automaticamente se i numeri presenti sono presenti anche sulle loro reti, questi sistemi ci permettono trovare tutti i nostri contatti che già li usano, all'interno della lista dei contatti del software di IM.
Tramite ciò sarebbe possibile collegare il numero di telefono di uno sconosciuto ad una persona reale, proprio grazie all'avatar.

Gli autori: "Immaginate questo scenario, possediamo uno schedario di milioni di foto, la gran parte delle quali presentano il volto di una persona. Avete presente i vecchi film in cui la polizia cerca un criminale confrontando la sua foto con quelle contenute in uno schedario? Ecco: solo che 'NowIseeYou' ha il vantaggio che su ogni foto dello schedario c'è associato il numero di telefono"

NowISeeYou installato su un singolo device emulato può verificare, 100mila numeri al giorno.
L'App è stata fatta girare per circa 3 mesi, alla fine del periodo essa avrà verificato circa 10 milioni di numeri.
Usando l'exploit su 100 dispositivi, il totale di numeri verificati va moltiplicato per 100, permettendo di verificare 100 miliardi di numeri.
Di questi solo una piccola parte erano numeri reali o comunque verificati, lanciando una seconda scansione con soli questi numeri reali, è possibile poi salvare tutti gli avatars (compresi eventuali cambi dell'immagine profilo) e metterli tutti assieme in un database.
Fra i diversi tipi di hack che permetterebbero poi il confronto con quanto salvato in precedenza, c'è quello che Ziberna chiama il "Voodoo Doll Exploit": chi vuole ottenere informazioni fa una foto qualunque ad uno sconosciuto (ad esempio in un bar, all'università o al mare) e il tool di attacco confronta la foto con tutti gli avatar in possesso, permettendo quindi, eventualmente, di risalire anche al suo numero di telefono nel caso si trovasse corrispondenza.


Per maggiori info: Nowiseeyou

Dan Farmer e Gli Analizzatori Di Reti: S.A.T.A.N., S.A.I.N.T. e S.A.R.A.

Dan Farmer è uno sviluppatore americano che a metà anni 90 ebbe i suoi momenti di gloria grazie alla realizzazione di un software chiamato S.A.T.A.N. (Security Administrator Tool For Analyzing Networks).
Oltre a Farmer, anche Wietse Venema (programmatore olandese) ebbe la sua importanza nello sviluppo di questo tool rivoluzionario.
Sostanzialmente si trattava di uno scanner usato dagli Amministratori di sistema per l'analisi della sicurezza delle reti.
Il software era in grado di esaminare a fondo sistemi, o anche intere reti, per scovare bug ed altri punti critici di sicurezza.
Il 5 aprile 1995 S.A.T.A.N. fece la sua entrata trionfale su Internet, il suo intento come detto era quello di interrogare milioni di daemon in tutto il mondo nel tentativo di scoprire segreti e debolezze che rendevano i sistemi dell'epoca vulnerabili.
Gli attacchi informatici erano in voga oggi quanto allora.
Basti dire che nel 1994 erano state 2.241 le intrusioni illegali nei network su Internet, quasi il doppio dell'anno precedente: questo il dato riportato dal Computer Emergency Response Team (CERT), l'agenzia para-statale statunitense che segue l'andamento degli "attacchi" su Internet.
Sempre nello stesso anno, oltre la metà delle 1270 grandi aziende interpellate subì perdite finanziarie dovute ad intrusioni nei propri sistemi computerizzati, con 17 compagnie che dichiarano perdite superiori al milione di dollari.
Oltre 500 milioni di dollari era l'ammontare delle perdite dovute a "furti elettronici" dei numeri di carte di credito, mentre gli acquisti effettuati illegalmente via carta di credito raggiungevano un valore di 300.000 dollari.
Tornando a S.A.T.A.N. il tool analizzava vulnerabilità ISS, TFTP, RSH, dei server, l'accesso REXD e i filesystem NFS.
La grande rivoluzione fu il fatto che oltre all'individuazione delle succitate vulnerabilità, i programma forniva anche descrizioni dei problemi riscontrati e soluzioni per risolverli.
Malgrado ciò, Farmer e Venema finirono sotto gli occhi del ciclone: probabilmente il loro intento era nobile ma oltre che agli admin di sistema, un tool del genere era una manna dal cielo per gli Hacker che in poco tempo potevano scoprire eventuali vulnerabilità dei sistemi e allo stesso tempo attaccarli.
In seguito svilupparono un altro scanner per ricercare vulnerabilità: Titan (parteciparono al progetto anche Brad Powell e Matt Archibald, gli stessi creatori della conferenza L.I.S.A. ovvero Large Installation System Administration Conference, dove dal 1986 si riuniscono tutti gli amministratori di grandi reti).


S.A.I.N.T., S.A.R.A., NESSUS
Malgrado le critiche per l'uso improprio di S.A.T.A.N., qualche anno dopo, il codice dello stesso venne aggiornato: vedrà la luce S.A.I.N.T. (Security Administrator'S Integrated Network Tool).
Si trattava di un aggiornamento importante, visto che vennero aggiunte funzioni tra le quali vulnerabilità CGI, Buffer Overflow dei servizi di rete, soluzioni per attacchi DDoS e POP Server.
Venne anche semplificata l'interfaccia utente e quindi l'usabilità del tool.
Nel 1999 da S.A.I.N.T. nasce S.A.R.A. (Security Auditor's Research Assistant) aggiungendo il supporto degli standard CVE.
Nessus invece costruito secondo il modello Client/Server venne scritto da Renaud Deraison, questo analizzatore di rete sfruttava il linguaggio di programmazione N.A.S.L. (Nessus Attack Scripting Language).


THE CORONER'S TOOLKIT
Farmer e Venema invece, balzarono di nuovo agli onori della cronaca nel 2005 quando progettarono The Coroner's Toolkit: un software di analisi Forense che permetteva di recuperare dati da computer distrutti.

Il Bug Degli iPhone: 1 Gennaio 1970

Gli Smartphone e i Computer, per essere sincronizzati con date ed orari esatti, comunicano con server NTP.
Il riferimento sono le 00:00:00 dell'1 gennaio 1970 (Tempo Unix).
Se uno smartphone viene "impostato" dai programmatori in riferimento a questa data si ritrova a lavorare con un tempo praticamente "zero": ovvero tutte le operazioni matematiche fallirebbero rendendo di fatto il dispositivo inutilizzabile.
La causa del bug è quindi legata alla gestione del timestamp, che per alcune impostazioni dei fusi orari causerebbe una condizione di underflow in grado di mandare in crash il kernel del sistema operativo.
Un clamoroso errore di questo tipo è stato commesso dall'Apple (sino alla versione 9.3 che ha risolto il problema).
I bug riscontrati nei sistemi operativi mobile generalmente causano il blocco di un’applicazione e rallentamenti nelle performance.
Questo citato invece che affligge i dispositivi mini iPad 2, iPad Air, 5S, iPad Touch 2015, 6S e 6S Plus è ben più grave: come detto impostando la data 01/01/1970 nel sistema operativo iOS il dispositivo al successivo riavvio smette di funzionare, senza più dare segni di vita.
Pare che lo stesso bug si sia verificato anche per altre date (in un range compreso tra il primo gennaio e maggio del 1970).


ATTACCHI
Settare la data manualmente oppure in modo fraudolento potrebbe essere quindi molto pericoloso.
Stessa situazione potrebbe verificarsi tramite attacchi da remoto oppure con app opportunamente costruite.
O ancora creando, tramite Hotspot Wi-fi, falsi server NTP settati con quell'ora e data.
Gli iPhone connessi a una rete Wi-Fi del genere si troverebbero catapultati alla data infausta diventando quindi inutilizzabili al primo riavvio.
Sono stati diffusi anche messaggi palesemente falsi come questo:

Che permetterebbe di attivare funzioni retrò del Macintosh (che per inciso nasce più di 10 anni dopo e non nel 1970).

In realtà l'unica cosa che otterrete è il blocco del dispositivo sulla schermata di accensione.

Neanche la modalità di ripristino darebbe una mano.

Fatto il danno, l'unica alternativa è portare lo Smartphone in un centro Apple o aggiornare ad una versione più recente della 9.2

Cos'è Il Tempo UNIX? Date Particolari e Millennium Bug

Il tempo zero dell'Informatica non inizia con la data di nascita di Gesù Cristo o di chi per lui ma dalla mezzanotte di giovedi 1 gennaio 1970.
Non esisteva a quei tempi una data zero e quindi i programmatori la dovevano fissare per ogni file, ogni volta, nel file-system finchè non scelsero una data che potesse andare bene e che non soffrisse di overflow con sistemi a 32 bit, il 1970 sembrò una buona scelta (anche se inizialmente era stato scelto l'1 gennaio 1971).
Detto anche tempo UNIX, esso è come detto utilizzato per i timestamp dei programmi informatici.
In poche parole, esso segna il tempo trascorso in secondi da quella data.
Questo sistema di misurazione temporale è molto usato da sistemi operativi UNIX e può essere facilmente convertito, grazie a un piccolo software, nel tempo universale.
Ma perchè venne scelto il 1970? I sistemi UNIX vennero progettati nel 1969, il primo pubblicato nel 1971 quindi si suppose che nessun sistema informatico avrebbe potuto rappresentare un tempo di sistema prima di questa data.


DATE DA RICORDARE E MILLENNIUM BUG
Questo strano orologio, proprio come il calendario comunemente usato, regala date molto particolari dal punto di vista numerico.
Per esempio, il 9 settembre 2001 è stata la volta dello Unix Billenium, il momento in cui l'orologio si è fermato a 1.000.000.000 secondi.
Il 18 marzo 2005, invece, la cifra ha segnato l’1.111.111.111.
Il 13 febbraio 2009 per un istante si è fermato sulla cifra di 1234567890 secondi.
Per l'occasione sono state organizzate celebrazioni in tutto il mondo e l'evento è stato celebrato anche da Google, con un doodle dedicato.
Mentre il 26 gennaio 2011 è stato il 15.000° giorno dello Unix Time e i festeggiamenti hanno avuto luogo a Bloomington in Indiana (USA).
Il 18 maggio 2033 invece sarà il giorno del secondo Billennium: i 2.000.000.000 di secondi.
Sono molti i sistemi operativi che presentano problemi con date particolari.
A cavallo tra il 1999 e il 2000 si parlò molto del “Millennium Bug”, un problema che si verificò sui computer al cambio di data dalla mezzanotte del 31 dicembre 1999 all’1 gennaio 2000.
Temendo conseguenze catastrofiche, furono da più parti predisposte misure per correggere sistemi operativi, applicazioni, firmware e altri sistemi che lavorano con le date.


LA FINE DEL MONDO
Non sarebbe un vero calendario, tuttavia, se non ci fosse anche una fine del mondo.
Questa è segnata per le 03:14:08 UTC del 19 gennaio 2038, data prevista per il Bug Dell'Anno 2038 (bugY2038).
In questo giorno, infatti, per i sistemi operativi a 32 bit che adoperano questa rappresentazione del tempo scoccherà l'istante in cui i contatori toccheranno il loro valore massimo, l'istante rappresentabile più distante possibile dal 1 gennaio 1970: 2147483647 secondi.
Dall'istante successivo, i contatori registreranno il valore negativo -2147483648, che corrisponderà (sempre a partire dal 1 gennaio 1970) alle 20:45:52 di venerdì 13 dicembre 1901.
In poche parole il numero di secondi trascorsi dall'epoca raggiungerà il valore di 2 alla 31esima potenza, che è al di fuori dei valori rappresentabili da tale tipo di dato.
Tali calcolatori e sistemi operativi potranno quindi riscontrare malfunzionamenti, non essendo più in grado di memorizzare correttamente il valore che indica la data corrente.
Questa festività, anzi Apocalisse, è anche nota come "The Friday 13th Bug".

Scoperto Il Bug No IOS Zone: Come Difendersi

Molti utenti scelgono l'iPhone e gli iPad iOS 8 per la loro presunta sicurezza rispetto ad altri dispositivi.
Tuttavia questo è un falso mito o comunque è stato scoperto un grave bug (No iOS Zone) che affligge questi dispositivi.
Questo bug consente ad un malintenzionato di effettuare un attacco DoS sui dispositivi collegati ad una rete Wi-Fi aperta (“infetta”).
In poche parole si tratterebbe di "router fittizio" (reti/hotspot più precisamente) creati ad hoc che manderebbero in crash i dispositivi.
Funzionerebbe, sotto certi versi, come uno Jammer (inibendo l'uso dello smartphone).


COME AVVIENE L'ATTACCO?
Infatti spesso girando per le strade della città, è possibile scovare reti Wi-Fi a cui appoggiarsi per collegarsi ad internet con l’intento di risparmiare traffico dati oppure semplicemente perché ci troviamo in una zona poco coperta dal nostro operatore mobile.
Secondo quanto dichiarato da Skycure, nota società per la sicurezza mobile, in iOS 8 è stata trovata una falla che potrebbe mandare i tilt l’intero sistema.
Per non cadere nella trappola, viene consigliato di mantenersi alla larga da reti Wi-Fi aperte o, comunque, di dubbia provenienza, denominate per l’occasione “No iOS Zone“.
Se malauguratamente doveste incappare nella trappola, noterete continui riavvii e crash di sistema dovuti alla manipolazione dei certificati di sicurezza SSL, aprendo così le porta per un attacco DoS.
Nella peggiore delle ipotesi, i dispositivi sotto attacco mirato potrebbero addirittura subire danni permanenti, senza alcuna possibilità di ripristino e con la conseguente perdita dei dati, tra cui anche personali.


COME DIFENDERSI
Come proteggersi da un attacco DoS dalle reti “No iOS Zone“?
Come detto, al momento, l’unica soluzione possibile è quella di evitare gli hotspot di cui non si conosce la provenienza.
Il bug verrà sicuramente risolto tramite aggiornamento iOS.
In alternativa è possibile installare Skycure, un app che farebbe da antivirus e permetterebbe d'intercettare le reti malevole.

Corretto Il Bug Di Youtube Scoperto Da Hismatullin

Inviando una richiesta opportunamente modificata al server web di YouTube, un esperto d'informatica russo, tale Kamil Hismatullin, si è accorto di avere in mano gli strumenti giusti per cancellare potenzialmente, uno ad uno, tutti i video ospitati sul servizio di Google.
Trattasi della richiesta POST accompagnata dal parametro “action_delete_live_event” unito agli identificatori “event_id” e “session_token”, tramite ciò era possibile cancellare qualsiasi tipo di contenuto da YouTube senza esserne l’autore.
I tecnici di Google si sono affrettati a correggere questa vulnerabilità di sicurezza che avrebbe potuto portare alla cancellazione di tutti i video hostati sulla piattaforma.
L'esperto russo ha spiegato i dettagli tecnici della vulnerabilità, molto simile a quella rilevata qualche tempo fa in Facebook (Facebook corregge il bug che cancella le foto).
Hismatullin, tuttavia, ha preferito non farlo sebbene la tentazione di prendere di mira il canale di Justin Bieber, musicista che il ricercatore non apprezza per nulla, sia stata davvero grande.
Sulla base della segnalazione responsabilmente inviata ai tecnici di Google, la società californiana ha corrisposto al ricercatore un premio in denaro pari a 5.000 dollari, il massimo previsto in questi casi.
Un bug colossale, comunque, la cui scoperta avrebbe forse meritato una ricompensa maggiore.

Dopo Il Millennium Bug, Arriverà Il Bug Dell'Anno 2038

Passato indenne il Millennium Bug del 2000, c'apprestiamo (o meglio, mancano ancora un po' di anni) a vivere quello del 19 Gennaio 2038.
Però manca ancora un bel po' di tempo eh?
Ad ogni modo a causarlo sarebbero i processori a 32 bit quindi nessun problema per coloro che usano sistemi a 64 bit(per la verità tra una ventina d'anni i computer saranno drasticamente diversi da quelli di ora ed è assolutamente improbabile che si rimanga con questi processori).


BUG 2038
Il problema comunque scatterebbe a una data e un’ora specifica: 19 gennaio 2038 alle 03:14:07 (fuso orario di Greenwich).
Da quel momento in poi, i computer che utilizzeranno ancora sistemi a 32 bit non saranno in grado di stabilire la differenza tra il 2038 ed il 1970 (anno di partenza da cui sono settati gli attuali computer).
I sistemi Unix, infatti, non possono calcolare le date successive al 2038.
Questo perché tengono traccia del tempo utilizzando un intero di 4 byte che rappresenta il numero dei secondi dal primo gennaio 1970.
In pratica, un intero di 4 byte ha un valore massimo di 2.146.483.547: proprio questo tempo (conosciuto come “tempo massimo”) corrisponde al 19 gennaio 2048, ore 3.14.07.
I sistemi Unix, infatti, non erano stati toccati dal Millennium Bug(del 2000), ma ora ne vanno incontro ad un altro.
Il problema è che molte macchine che hanno come sistema operativo Unix/Linux sono quelle che controllano le principali arterie del mondo tecnologico, dall’aeronautica a internet.
Quello che accadrà sarà un semplice “reset” del tempo a 0, quindi al primo minuto del 1970.
Perché proprio 2.147.483.647? I computer misurano il tempo in secondi.
Quindi, 2.147.483.647 sono i secondi compresi nell’intervallo tra il primo gennaio 1970 (Tempo Unix) ed il 19 gennaio 2038 alle 03:14:07.
Il problema è generalizzato perché i processori, anche se di differenti dimensioni e capacità, funzionano tutti allo stesso modo, sia su device fissi sia su mobile.
Alcuni processori potrebbero continuare a funzionare bene con una data sbagliata mentre altri smetterebbero drasticamente di lavorare.


DA COSA è GENERATO IL BUG?
La maggioranza dei sistemi informatici mondiali (anche la stessa “struttura” sulla quale si appoggia internet) è basata su UNIX, il famoso sistema operativo open source dal quale sono derivati Linux e anche i prodotti della Apple.
Il sistema operativo UNIX memorizza le date in un formato definito dallo standard POSIX.
In pratica la data è memorizzata in un numero che rappresenta il numero di secondi a partire dalla mezzanotte del 1° Gennaio 1970, tale data viene anche chiamata “epoca” (The Epoch), per cui ogni secondo che passa, questo numero incrementa di una unità.
Gli orari sono in formato UTC, che corrisponde all’orario GMT (quello di Greenwich insomma).
La data viene memorizza in un numero a 32 bit e i sistemi colpiti saranno quelli che usano la variabile "signed".
Fortunatamente, non tutti i sistemi UNIX utilizzano il tipo signed e usano quindi il tipo unsigned che porta a non avere problemi su queste macchine (o meglio a spostarlo alle 06:28:15 di Domenica 7 Febbraio 2106) .
Un numero a 32 bit di tipo signed prevede che il numero positivo più grande memorizzabile sia 2147483647 che in base al sistema POSIX corrisponde  alle ore 03:14:07 di martedì 19 Gennaio 2038.
Un secondo dopo, come già spiegato, il numero verrà incrementato ancora di 1 e di conseguenza verrà posto ad 1 il bit più significativo di  tale numero(numero negativo).
Per cui facendo due calcoli col complemento a due il numero vale -2147483648 che nella fattispecie viene interpretato dal sistema POSIX come le ore 20:45:52 del giorno Venerdì 13 Dicembre 1901.
Questo fatto causerà enormi problemi in tutti gli ambiti in quanto dopo le 03:14:07 di martedì 19 Gennaio 2038 i sistemi UNIX crederanno di “essere tornati indietro nel tempo” al 1901 con conseguenze catastrofiche dal momento che oramai tutto è gestito da computer e tutto si appoggia alla rete internet.


SOLUZIONI
Detto del passaggio a sistemi a 64 bit, vanno fatte alcune considerazioni.
Cambiare il valore di time.h (che controlla appunto il tempo e come detto è un numero intero a 32 bit) per usare un sistema a 64-bit renderebbe il sistema incompatibile con software, sistemi di memorizzazione e tutti gli strumenti che usano una rappresentazione binaria del tempo.
Cambiare time.h in un intero unsigned, permetterebbe di rimandare il problema al 7 febbraio 2106, causando comunque problemi a molti programmi.
Molti sistemi operativi per sistemi a 64-bit usano già dei numeri interi a 64-bit per il time.h.
Il passaggio a questo tipo di architetture è in corso, e ci si aspetta che sia completo prima del 2038.
Tuttavia, ancora oggi esistono centinaia di milioni di sistemi a 32 bit sul mercato, di cui molti in sistemi integrati.
L'uso di time.h a 32 bit è anche stato inserito in vari formati di file, cosa che comporta la persistenza del problema anche oltre la vita delle macchine stesse.
L'uso di un valore di tipo signed a 64-bit sposterebbe l'emergere del problema in avanti nel tempo di circa 290 miliardi di anni.
Sono state avanzate anche varie proposte alternative, alcune delle quali in uso, per sfruttare questo spostamento eccessivo della data massima calcolabile: tra queste, includere nel calcolo delle ore i millisecondi o i microsecondi, abbreviando la vita utile delle macchine a 300.000 anni.

Cos'è Il Millennium Bug e Come Venne Risolto Il Problema

Il Millennium Bug, conosciuto anche come Y2K bug, è il nome che venne attribuito ad un bug informatico che si sarebbe manifestato al cambio di data dalla mezzanotte del 31 dicembre 1999 al 1º gennaio 2000 nei sistemi di elaborazione dati, sia PC privati che grandi elaboratori e controllori di processo. Si trattava sostanzialmente di un errore di programmazione che, al passaggio di millennio, ha impedito in alcuni programmi di riconoscere il cambiamento di data, provocando il blocco dei sistemi informatici. L'espressione Millennium venne aggiunta con l'avvicinarsi dell'anno 2000.
I computer più vecchi, infatti, indicavano la data del sistema con due sole cifre: per esempio l'anno 1998 era segnato come '98', il 1999 con il '99' e così via. Infatti se facciamo un passo indietro e torniamo a quando furono introdotti i primi calcolatori, possiamo notare che per risparmiare preziose risorse di sistema, allora limitate a pochi byte, si decise di indicare le date con i soli due numeri finali, omettendo l'indicazione del millennio e del secolo. Il "cambiamento di millennio" poteva quindi portare a problemi inaspettati, quando le banche dati informatiche avrebbero datato i nuovi documenti del 2000 con la cifra '00', creando confusione con la data '1900' (con conseguenti errori di ordinamento dei database. Pensate inoltre ai sistemi industriali e ad altri macchinari gestiti dai computer).
Questo metodo delle due cifre era stato in effetti molto utilizzato nella "preistoria" informatica, quando la memoria era scarsa e costosa. Già nella metà degli anni 80, la comunità internazionale iniziò ad interessarsi al problema. Temendo conseguenze catastrofiche per l'economia o la salute, quali ad esempio il blocco delle centrali elettriche e nucleari, testate atomiche lanciate a caso, istituti bancari e reti di telecomunicazione in tilt, vi furono ingenti investimenti volti alla rimozione delle cause del bug.
Al cadere della data critica non fu registrato nessun evento catastrofico dagli osservatori preposti (problemi si ma non eccessivamente significativi). Per la verità i computer dell'epoca (Windows 98 ad esempio) erano ovviamente già predisposti per il cambio di data, essendo ormai imminente il nuovo millennio. Il problema, nel suo complesso (vecchi sistemi operativi, antecedenti al 1998), fu risolto spendendo una decina di milioni di dollari.


USENET E SPENCER BOLLES SUL MILLENNIUM BUG
Il primo articolo pubblicato su Usenet che menziona questo problema è apparso nel newsgroup net.bugs a firma di Spencer Bolles il 19 gennaio 1985.
"Un mio amico mi ha posto una domanda interessante: dato che i computer sono nati nel ‘900 saranno preparati a capire le date dal 2000 in poi? A me sembra un qualcosa privo di senso.
Io ho pensato che il mio amico scherzasse, ma n realtà sembrava vivamente preoccupato".


LE PRECAUZIONI DELL'EPOCA
All'avvicinarsi del fatidico capodanno che avrebbe portato tutti nel nuovo millennio, le più importanti aziende italiane, americane e tutti i paesi industrializzati aggiornarono i loro PC ed i software per evitare problemi con il cambio di data. I vecchi BIOS vennero ovviamente aggiornati tramite internet dai siti dei produttori stessi. Dal punto di vista software, Windows 95 e soprattutto 98 furono abbastanza pronti, anche se vennero messe a disposizione diverse patch per entrambi per garantire la massima compatibilità e sicurezza. Il problema più grande invece riguardava ovviamente Win 3.11 che aveva bisogno di molti aggiornamenti per non avere problemi. Per Linux invece non ci furono eccessivi problemi. Per quanto riguarda gli applicativi "Office", Microsoft Office, StarOffice, Lotus e simili, per le versioni antecedenti al 97 venne messa appunto una patch. Tutti i programmi, quali grafica 2D/3D, giochi, audio, browser, montaggio video e altri non ebbero nessun problema in quanto non gestiscono date. Vennero inoltre messi in vendita moltissimi programmi che promettevano di controllare il sistema e di "risolvere" i problemi legati all'anno 2000. Qualche problema ci fu ma la catastrofe di cui si parlava, fortunatamente, non si verificò (anche grazie all'utilizzo di PC recenti e alla correzione dei bug di quelli più vecchi).
Per saperne di più: Quali Problemi Accaddero Durante Il Millennium Bug? (Y2K)

Ti consiglio anche quest'articoli: Arriva Il Bug Dell'Anno 2038 e Tempo Unix

Zero Day Attack Su Flash Player (Exploit e Bug)

Alcune versioni Flash Player per Windows, Mac e Linux avrebbero evidenziato vulnerabilità Zero-Day (identificata da Kaspersky dal codice CVE-2014-0515) che interessano la componente Pixel Bender per la processazione di immagini e video.
Attraverso questa vulnerabilità i criminali informatici possono assumere il controllo da remoto dei dispositivi infettati con “montate” le versioni 13.0.0.182 e precedenti per Windows, 13.0.0.201 e precedenti per Mac e 11.2.202.350 e precedenti per Linux.
Al momento della sua scoperta, l’exploit zero-day era già stato usato per colpire diverse vittime in Siria attraverso una tecnica di attacco chiamata “watering hole”.
Un “water hole attack” è un tipo di attacco mirato in cui un hacker inserisce un malware in un sito web che crede che la sua vittima potrebbe visitare.
In questo modo, quando e se la vittima visita il sito web infetto, verrà infettata dal malware automaticamente.
Adobe ha già preparato una patch per il bug.


PROBLEMI ANCHE PER MICROSOFT
Anche Microsoft ha avuto alcuni problemi con un zero-day che ha interessato il suo browser, Internet Explorer.
Si tratta di un problema serio tale da spingere Microsoft a pensare alla release di una patch “out of band”, ovvero quelle patch che vengono rilasciate al di fuori dei momenti stabiliti, come per esempio il Patch Tuesday mensile.
Se un bug riceve una patch “out of band”, è abbastanza evidente che si tratta di un bug serio.

Facebook Paga Chi Riesce A Trovare Dei Bug (Bounty Bug)

Nuova partnership tra Facebook e Microsoft che sfidano gli hacker invitandoli, dietro compenso, a trovare bug nella rete.
Il social network e il gruppo informatico hanno creato un apposito fondo con cui cercano di attrarre pirati informatici, ma questa volta per cause positive.
Da sempre grandi società Internet pagano esperti di sicurezza informatica al fine di scovare vulnerabilità nei loro software.
L’intento è quello di risolvere i problemi prima che qualcuno ne tragga beneficio.
Progetti chiamati “Bounty Bug” hanno attratto attenzione nei mesi scorsi dopo che un ricercatore ha dimostrato l’imperfezione nelle barriere di sicurezza di Facebook, pubblicando senza permesso un post sul profilo dell’amministratore delegato del social network, Mark Zuckerberg.
A oggi, il gruppo ha versato 1,5 milioni di dollari ai ricercatori di bachi e in alcuni casi li ha assunti.
Il fondo voluto da Facebook e Microsoft pagherà almeno 5.000 dollari per un buco nella rete Internet che “si manifesta in un’ampia gamma di prodotti o che ha un impatto su un ampio numero di utenti” e ha “conseguenze estremamente negative per il pubblico generale”.
Di cosa si tratta? Un esempio è dato dai problemi trovati in Secure Sockets Layer, un protocollo di crittazione usato da molte società di e-commerce e siti di banche.

Guadagnare Trovando I Bug Di Windows (Bounty Program)

Qualche tempo fa Microsoft ha presentato Bounty Program, il software che permette di segnalare i bug presenti in Windows 8.1 e IE11 e di essere ricompensati per tale scoperta.
Sembra che anche Microsoft si sia arresa alle esigenze di mercato e abbia deciso di pagare chi riesce a trovare bug sulle due piattaforme in divenire di Microsoft: Windows 8.1 e IE11.
Questo sistema, già utilizzato ampiamente da Google e da Mozilla, con ottimi risultati, prevede il pagamento di una data somma di denaro in base al bug scoperto in modo da sviluppare un sistema sempre più sicuro per gli utenti.


PAGAMENTI PER BUG
Questo progetto, iniziato il 26 Giugno scorso 2013, prevede pagamenti fino a 100 mila dollari per bug critici in Windows 8.1 e fino ad 11 mila dollari per quelli presente in IE11.
Ad ogni modo il programma, a differenza di quanto avviane con Google e Mozilla, non durerà per sempre: sarà attivo per un periodo di tempo limitato, sino al termine della fase beta di Windows 8.1
Una scelta questa, da parte di Microsoft, al quanto discutibile dato gli ottimi risultati finora raggiunti:
"Alcune segnalazioni stanno arrivando da ricercatori noti, mentre altre stanno arrivando da ricercatori che storicamente hanno segnalato tramite il mercato bianco dei broker di vulnerabilità dopo la scadenza del periodo di beta. Questo significa che la nostra strategia per attrarre ricercatori a segnalare direttamente al gruppo prima della release del software sta già funzionando, ad appena una settimana dal lancio del nuovo programma".
Purtroppo ancora non è disponibile alcun dato riguardo l’effettiva validità del programma, ma un’iniziativa del genere non può che essere ben accettata dagli sviluppatori e dagli utenti.
Ci auguriamo soltanto che Microsoft, vista l’enorme adesione al programma, decida di renderlo permanente.

Cosa Sono Gli Zero-Day (Vulnerabilità)

Gli Zero-Day sono tra i peggiori pericoli del web, in quanto sono noti solo a una ristretta cerchia di persone e possono causare moltissimi danni prima di essere scoperti.
In informatica si definisce 0-day qualsiasi vulnerabilità non nota e, per estensione, indica un tipo di attacco informatico che inizia nel "giorno zero", cioè nel momento in cui viene scoperta una falla di sicurezza in un sistema informatico.
Questo tipo di attacco può mietere molte vittime proprio perché è lanciato quando ancora non è stata distribuita alcuna patch e quindi i sistemi non sono ancora protetti.
Normalmente si parla di Zero-Day(o zero-day)riferendosi ad essi come un'attività espressamente dolosa compiuta dai criminali che si adoperano per trovarle, proprio con l'intenzione di guadagnarsi un accesso abusivo ad un sistema informatico che non presenta,evidentemente, altri bug da sfruttare per l'accesso.
Ci sono hacker/cracker che si riuniscono in piccole organizzazioni(blog,mailing list,etc)in modo da scambiarsi informazioni e 0-day.
Tipologie di 0-day possono essere SQL Injection, Exlopit, Remote File Inclusion e XSS , ovvero tutti attacchi molto pericolosi per l'integrità di un sito web o per il corretto funzionamento di un nodo di internet.

Cos'è La Vulnerabilità PHF (CGI)

Il PHF era uno script CGI di esempio che implementava una rubrica telefonica basata su maschere.
Lo script veniva incluso di default in alcuni web server (soprattutto NCSA httpd 1.5 ed Apache 1.0.3) durante gli anni 90 e soffriva di una vulnerabilità che consentiva l'esecuzione di codice remoto sul sistema ospite.
Lo script utilizzava la funzione escape_shell_cmd() per verificare i dati in ingresso ma purtroppo la procedura di validazione dell’input non riusciva a rilevare il carattere di ritorno a capo (“++”, o “0x0a” in esadecimale).
Di conseguenza questo carattere particolare poteva essere utilizzato per forzare la fine dell’esecuzione dello script e fare in modo che il programma esegua, localmente sul server, tutto quello che segue il carattere incriminato.
In questo modo diventava possibile fare qualsiasi, cosa come ad esempio ottenere il file delle password.
Fu uno dei bug più semplici da sfruttare nella storia delle web application.