Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google. Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374
https://rain-1.github.io/in-browser-localhostdiscovery E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report! E Mozilla tace. Io sono allibito. Ricordate "this is the Web functioning as desinged"! Giacomo
"I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?) Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork. m.c. In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto:
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374
https://rain-1.github.io/in-browser-localhostdiscovery
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
cosa dovrebbe consentire javascript ? puo' collegarsi a computer diversi da quello dell'utente ? certamente, per comunicare con il server da cui proviene. può scaricare oggetti, diciamo immagini, da un computer con un determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla webmail) una alternativa potrebbe essere che consenta di comunicare solo con il computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario). queste due cose che consente, possono essere usate da qualcuno per acquisire informazioni ? ogni cosa fatta su un computer da remoto consente di acquisire informazioni, dalla latenza di un collegamento al fatto che il computer a cui si collega risponda o meno. (che e' l'esempio sotto) e se uno non vuole consentirlo ? su firefox basta usare plugin come noscript e/o umatrix tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio) ciao, s. On 13/09/2018 10:29, Marco Ciurcina wrote:
"I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?)
Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork.
m.c.
In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto:
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374
https://rain-1.github.io/in-browser-localhostdiscovery
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano@quintarelli.it> ha scritto:
cosa dovrebbe consentire javascript ?
Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere reso molto più sicuro attraverso piccole modifiche. In sintesi <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozil...> :
Anyway, to answer your question, the solution is simple, if it’s not easy. *The execution of Web software should be opt-in, not opt-out * (if you can opt-out, given how usable are the UI to disable JavaScript <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>).
Now, given the *severity of the issue*, as a first step I would release an *emergency fix that disable JavaScript* (and Meta Refresh) without looking at the user settings.
Then I would deploy a mid term fix so that:
- Page Refresh though META tag and JavaScript are disabled by default - Both can be enabled on a per website basis, but — No script or CSS is requested with Cookies or other HTTP headers — Each script and CSS is requested through a dedicated TCP connection <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> — SubResource Integrity <https://www.w3.org/TR/SRI/> is made mandatory (at least for JavaScript) — For each URI, record the SRI of last downloaded contents and warn the user if a page propose a different SRI for that same URI — Warn the user about scripts served with suspect HTTP headers - On browser exit, remove from the cache all resources downloaded by pages that have Meta Refresh and/or JavaScript enabled. - *View Page Source *should never fetch new versions of the page from the server <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> (whatever the HTTP Headers provided with the page are)
Obviously all this leaves the door open for pages that:
- are visited only once - are visited for the first time
thus I would also mark as “Not Secure” <https://www.blog.google/products/chrome/milestone-chrome-security-marking-ht...> web pages visited for the first time that require JavaScript.
(scusa il cut&paste, ma sono un po' di corsa) Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano@quintarelli.it> ha scritto:
puo' collegarsi a computer diversi da quello dell'utente ? certamente, per comunicare con il server da cui proviene.
può scaricare oggetti, diciamo immagini, da un computer con un determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla webmail)
una alternativa potrebbe essere che consenta di comunicare solo con il computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario).
queste due cose che consente, possono essere usate da qualcuno per acquisire informazioni ?
No. Attraverso l'uso appropriato degli header HTTP (cache control etc), qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le tracce di un attacco. Se il server (o la CDN) può identificare l'obbiettivo (non solo privati cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. Attraverso quel JavaScript può sfruttare diverse risorse della vittima (cut&paste dal report) - their IP - their bandwith - their computing power - their RAM - their disk (through browser cache) - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown) e questo permette tutte una enorme varietà di attacchi la cui realizzazione è veramente banale. In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un banalissimo DNS rebinding per penetrare la rete privata della vittima. Ma sono solo due degli attacchi possibili: davvero qualunque sviluppatore web con un minimo di competenza e fantasia ne può pensare a bizzeffe. E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, anche all'insaputa del creatore del sito stesso: basta controllare l'hosting (il Cloud! chi controlla il Cloud?) E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un paio di persone che analizzano i log quotidianamente). ogni cosa fatta su un computer da remoto consente di acquisire
informazioni, dalla latenza di un collegamento al fatto che il computer a cui si collega risponda o meno. (che e' l'esempio sotto)
Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL etc? Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa energia, non credi? e se uno non vuole consentirlo ?
su firefox basta usare plugin come noscript e/o umatrix
No, contro questi attacchi questi plugin non possono nulla. Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché il server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo permesso di esecuzione sulla tua macchina.
tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio)
Io ad oggi consiglio di usare due browser: - un Firefox con JavaScript disabilitato da usare su tutti i siti che funzionano - un Chrome per tutti quelli che proprio non funzionano senza JS (e non si può evitare di usare). Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due browser) è intrinsecamente fallace. La OPT-IN SECURITY non funziona: basta un dipendente distratto per entrare nella rete di una banca con questi attacchi. Abilitare l'esecuzione di JavaScript sito per sito, invece, è perfettamente usabile. Come lo è per le notifiche push di HTTP/2! E come lo era per Flash o per le Applet Java. Ai miei occhi, tutto questo indignarsi per una soluzione semplice e ovvia come rendere JavaScript opt-in (e più sicuro) è prova di straordinaria disonestà intellettuale da parte di sviluppatori, come quelli di Mozilla, che si declamano campioni della privacy! Giacomo
ciao, s.
On 13/09/2018 10:29, Marco Ciurcina wrote:
"I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?)
Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork.
m.c.
In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto:
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from
addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374
https://rain-1.github.io/in-browser-localhostdiscovery
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Aggiungo: come hacker mi può anche stare bene che alla comunità di Chromium e Mozilla non interessi prevenire questi attacchi. Ognuno deve essere libero di investire il proprio tempo per perseguire la PROPRIA curiosità. Ma quello che non posso accettare è il tentativo (che a questo punto a me sembrerebbe evidente) di NON INFORMARE gli utenti. Giacomo Il giorno 13 settembre 2018 11:59, Giacomo Tesio <giacomo@tesio.it> ha scritto:
Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano@quintarelli.it> ha scritto:
cosa dovrebbe consentire javascript ?
Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere reso molto più sicuro attraverso piccole modifiche. In sintesi <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozil...> :
Anyway, to answer your question, the solution is simple, if it’s not easy. *The execution of Web software should be opt-in, not opt-out * (if you can opt-out, given how usable are the UI to disable JavaScript <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>).
Now, given the *severity of the issue*, as a first step I would release an *emergency fix that disable JavaScript* (and Meta Refresh) without looking at the user settings.
Then I would deploy a mid term fix so that:
- Page Refresh though META tag and JavaScript are disabled by default - Both can be enabled on a per website basis, but — No script or CSS is requested with Cookies or other HTTP headers — Each script and CSS is requested through a dedicated TCP connection <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> — SubResource Integrity <https://www.w3.org/TR/SRI/> is made mandatory (at least for JavaScript) — For each URI, record the SRI of last downloaded contents and warn the user if a page propose a different SRI for that same URI — Warn the user about scripts served with suspect HTTP headers - On browser exit, remove from the cache all resources downloaded by pages that have Meta Refresh and/or JavaScript enabled. - *View Page Source *should never fetch new versions of the page from the server <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> (whatever the HTTP Headers provided with the page are)
Obviously all this leaves the door open for pages that:
- are visited only once - are visited for the first time
thus I would also mark as “Not Secure” <https://www.blog.google/products/chrome/milestone-chrome-security-marking-ht...> web pages visited for the first time that require JavaScript.
(scusa il cut&paste, ma sono un po' di corsa)
Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano@quintarelli.it> ha scritto:
puo' collegarsi a computer diversi da quello dell'utente ? certamente, per comunicare con il server da cui proviene.
può scaricare oggetti, diciamo immagini, da un computer con un determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla webmail)
una alternativa potrebbe essere che consenta di comunicare solo con il computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario).
queste due cose che consente, possono essere usate da qualcuno per acquisire informazioni ?
No.
Attraverso l'uso appropriato degli header HTTP (cache control etc), qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le tracce di un attacco. Se il server (o la CDN) può identificare l'obbiettivo (non solo privati cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. Attraverso quel JavaScript può sfruttare diverse risorse della vittima (cut&paste dal report)
- their IP - their bandwith - their computing power - their RAM - their disk (through browser cache) - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown)
e questo permette tutte una enorme varietà di attacchi la cui realizzazione è veramente banale.
In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un banalissimo DNS rebinding per penetrare la rete privata della vittima.
Ma sono solo due degli attacchi possibili: davvero qualunque sviluppatore web con un minimo di competenza e fantasia ne può pensare a bizzeffe. E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, anche all'insaputa del creatore del sito stesso: basta controllare l'hosting (il Cloud! chi controlla il Cloud?)
E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un paio di persone che analizzano i log quotidianamente).
ogni cosa fatta su un computer da remoto consente di acquisire
informazioni, dalla latenza di un collegamento al fatto che il computer a cui si collega risponda o meno. (che e' l'esempio sotto)
Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL etc? Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa energia, non credi?
e se uno non vuole consentirlo ?
su firefox basta usare plugin come noscript e/o umatrix
No, contro questi attacchi questi plugin non possono nulla.
Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché il server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo permesso di esecuzione sulla tua macchina.
tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio)
Io ad oggi consiglio di usare due browser: - un Firefox con JavaScript disabilitato da usare su tutti i siti che funzionano - un Chrome per tutti quelli che proprio non funzionano senza JS (e non si può evitare di usare).
Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due browser) è intrinsecamente fallace.
La OPT-IN SECURITY non funziona: basta un dipendente distratto per entrare nella rete di una banca con questi attacchi.
Abilitare l'esecuzione di JavaScript sito per sito, invece, è perfettamente usabile. Come lo è per le notifiche push di HTTP/2! E come lo era per Flash o per le Applet Java.
Ai miei occhi, tutto questo indignarsi per una soluzione semplice e ovvia come rendere JavaScript opt-in (e più sicuro) è prova di straordinaria disonestà intellettuale da parte di sviluppatori, come quelli di Mozilla, che si declamano campioni della privacy!
Giacomo
ciao, s.
On 13/09/2018 10:29, Marco Ciurcina wrote:
"I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?)
Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork.
m.c.
In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto:
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from
addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374
https://rain-1.github.io/in-browser-localhostdiscovery
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Scusa Stefano, mi rendo conto ora che forse non avevo capito il tuo dubbio. Una volta entrato nella tua rete privata (o VPN) attraverso JS, posso trasferire informazioni sulla sua topologia all'esterno ed eseguire attacchi su eventuali servizi presenti in essa. Sempre senza lasciare traccie. Posso anche attacchare terze parti. Senza lasciare tracce del mio attacco, ma lasciando tracce che riconducono alla tua macchina. Pensa quanto può essere utile questo in ambito di spionaggio industriale. Spero di essere stato più chiaro... Giacomo Il giorno 13 settembre 2018 12:08, Giacomo Tesio <giacomo@tesio.it> ha scritto:
Aggiungo: come hacker mi può anche stare bene che alla comunità di Chromium e Mozilla non interessi prevenire questi attacchi. Ognuno deve essere libero di investire il proprio tempo per perseguire la PROPRIA curiosità.
Ma quello che non posso accettare è il tentativo (che a questo punto a me sembrerebbe evidente) di NON INFORMARE gli utenti.
Giacomo
Il giorno 13 settembre 2018 11:59, Giacomo Tesio <giacomo@tesio.it> ha scritto:
Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano@quintarelli.it> ha scritto:
cosa dovrebbe consentire javascript ?
Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere reso molto più sicuro attraverso piccole modifiche. In sintesi <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozil...> :
Anyway, to answer your question, the solution is simple, if it’s not easy. *The execution of Web software should be opt-in, not opt-out * (if you can opt-out, given how usable are the UI to disable JavaScript <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>).
Now, given the *severity of the issue*, as a first step I would release an *emergency fix that disable JavaScript* (and Meta Refresh) without looking at the user settings.
Then I would deploy a mid term fix so that:
- Page Refresh though META tag and JavaScript are disabled by default - Both can be enabled on a per website basis, but — No script or CSS is requested with Cookies or other HTTP headers — Each script and CSS is requested through a dedicated TCP connection <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> — SubResource Integrity <https://www.w3.org/TR/SRI/> is made mandatory (at least for JavaScript) — For each URI, record the SRI of last downloaded contents and warn the user if a page propose a different SRI for that same URI — Warn the user about scripts served with suspect HTTP headers - On browser exit, remove from the cache all resources downloaded by pages that have Meta Refresh and/or JavaScript enabled. - *View Page Source *should never fetch new versions of the page from the server <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> (whatever the HTTP Headers provided with the page are)
Obviously all this leaves the door open for pages that:
- are visited only once - are visited for the first time
thus I would also mark as “Not Secure” <https://www.blog.google/products/chrome/milestone-chrome-security-marking-ht...> web pages visited for the first time that require JavaScript.
(scusa il cut&paste, ma sono un po' di corsa)
Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano@quintarelli.it> ha scritto:
puo' collegarsi a computer diversi da quello dell'utente ? certamente, per comunicare con il server da cui proviene.
può scaricare oggetti, diciamo immagini, da un computer con un determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla webmail)
una alternativa potrebbe essere che consenta di comunicare solo con il computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario).
queste due cose che consente, possono essere usate da qualcuno per acquisire informazioni ?
No.
Attraverso l'uso appropriato degli header HTTP (cache control etc), qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le tracce di un attacco. Se il server (o la CDN) può identificare l'obbiettivo (non solo privati cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. Attraverso quel JavaScript può sfruttare diverse risorse della vittima (cut&paste dal report)
- their IP - their bandwith - their computing power - their RAM - their disk (through browser cache) - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown)
e questo permette tutte una enorme varietà di attacchi la cui realizzazione è veramente banale.
In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un banalissimo DNS rebinding per penetrare la rete privata della vittima.
Ma sono solo due degli attacchi possibili: davvero qualunque sviluppatore web con un minimo di competenza e fantasia ne può pensare a bizzeffe. E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, anche all'insaputa del creatore del sito stesso: basta controllare l'hosting (il Cloud! chi controlla il Cloud?)
E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un paio di persone che analizzano i log quotidianamente).
ogni cosa fatta su un computer da remoto consente di acquisire
informazioni, dalla latenza di un collegamento al fatto che il computer a cui si collega risponda o meno. (che e' l'esempio sotto)
Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL etc? Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa energia, non credi?
e se uno non vuole consentirlo ?
su firefox basta usare plugin come noscript e/o umatrix
No, contro questi attacchi questi plugin non possono nulla.
Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché il server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo permesso di esecuzione sulla tua macchina.
tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio)
Io ad oggi consiglio di usare due browser: - un Firefox con JavaScript disabilitato da usare su tutti i siti che funzionano - un Chrome per tutti quelli che proprio non funzionano senza JS (e non si può evitare di usare).
Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due browser) è intrinsecamente fallace.
La OPT-IN SECURITY non funziona: basta un dipendente distratto per entrare nella rete di una banca con questi attacchi.
Abilitare l'esecuzione di JavaScript sito per sito, invece, è perfettamente usabile. Come lo è per le notifiche push di HTTP/2! E come lo era per Flash o per le Applet Java.
Ai miei occhi, tutto questo indignarsi per una soluzione semplice e ovvia come rendere JavaScript opt-in (e più sicuro) è prova di straordinaria disonestà intellettuale da parte di sviluppatori, come quelli di Mozilla, che si declamano campioni della privacy!
Giacomo
ciao, s.
On 13/09/2018 10:29, Marco Ciurcina wrote:
"I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?)
Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork.
m.c.
In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto:
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from
addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374
https://rain-1.github.io/in-browser-localhostdiscovery
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Ciao Giacomo, Le cose sono a mio avviso anche piu’ preoccupanti. I ragazzi di BeEF project (https://github.com/beefproject/beef/wiki/Introducing-BeEF) hanno dimostrato che con un po’ di JS si possono fare cose ben piu’ turpi di network/port scan. In primis raccogliere informazioni personali, ma si arriva anche a rubare credenziali e ottenere reverse shell su SO/browser obsoleti con relativa facitlita’. Stefano — Stefano Traverso, PhD Chief Technical Officer @ Ermes Cyber Security <https://www.ermessecurity.com/> Mail: s.traverso@ermessecurity.com Skype: tigredcarta
On 13 Sep 2018, at 12:13, Giacomo Tesio <giacomo@tesio.it> wrote:
Scusa Stefano, mi rendo conto ora che forse non avevo capito il tuo dubbio.
Una volta entrato nella tua rete privata (o VPN) attraverso JS, posso trasferire informazioni sulla sua topologia all'esterno ed eseguire attacchi su eventuali servizi presenti in essa.
Sempre senza lasciare traccie.
Posso anche attacchare terze parti. Senza lasciare tracce del mio attacco, ma lasciando tracce che riconducono alla tua macchina.
Pensa quanto può essere utile questo in ambito di spionaggio industriale.
Spero di essere stato più chiaro...
Giacomo
Il giorno 13 settembre 2018 12:08, Giacomo Tesio <giacomo@tesio.it <mailto:giacomo@tesio.it>> ha scritto: Aggiungo: come hacker mi può anche stare bene che alla comunità di Chromium e Mozilla non interessi prevenire questi attacchi. Ognuno deve essere libero di investire il proprio tempo per perseguire la PROPRIA curiosità.
Ma quello che non posso accettare è il tentativo (che a questo punto a me sembrerebbe evidente) di NON INFORMARE gli utenti.
Giacomo
Il giorno 13 settembre 2018 11:59, Giacomo Tesio <giacomo@tesio.it <mailto:giacomo@tesio.it>> ha scritto: Il giorno 13 settembre 2018 10:56, Stefano Quintarelli <stefano@quintarelli.it <mailto:stefano@quintarelli.it>> ha scritto: cosa dovrebbe consentire javascript ?
Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere reso molto più sicuro attraverso piccole modifiche. In sintesi <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozil...>: Anyway, to answer your question, the solution is simple, if it’s not easy. The execution of Web software should be opt-in, not opt-out (if you can opt-out, given how usable are the UI to disable JavaScript <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>).
Now, given the severity of the issue, as a first step I would release an emergency fix that disable JavaScript (and Meta Refresh) without looking at the user settings.
Then I would deploy a mid term fix so that:
Page Refresh though META tag and JavaScript are disabled by default Both can be enabled on a per website basis, but — No script or CSS is requested with Cookies or other HTTP headers — Each script and CSS is requested through a dedicated TCP connection <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> — SubResource Integrity <https://www.w3.org/TR/SRI/> is made mandatory (at least for JavaScript) — For each URI, record the SRI of last downloaded contents and warn the user if a page propose a different SRI for that same URI — Warn the user about scripts served with suspect HTTP headers On browser exit, remove from the cache all resources downloaded by pages that have Meta Refresh and/or JavaScript enabled. View Page Source should never fetch new versions of the page from the server <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> (whatever the HTTP Headers provided with the page are) Obviously all this leaves the door open for pages that:
are visited only once are visited for the first time thus I would also mark as “Not Secure” <https://www.blog.google/products/chrome/milestone-chrome-security-marking-ht...> web pages visited for the first time that require JavaScript.
(scusa il cut&paste, ma sono un po' di corsa)
Il giorno 13 settembre 2018 10:56, Stefano Quintarelli <stefano@quintarelli.it <mailto:stefano@quintarelli.it>> ha scritto: puo' collegarsi a computer diversi da quello dell'utente ? certamente, per comunicare con il server da cui proviene.
può scaricare oggetti, diciamo immagini, da un computer con un determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla webmail)
una alternativa potrebbe essere che consenta di comunicare solo con il computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario).
queste due cose che consente, possono essere usate da qualcuno per acquisire informazioni ?
No.
Attraverso l'uso appropriato degli header HTTP (cache control etc), qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le tracce di un attacco. Se il server (o la CDN) può identificare l'obbiettivo (non solo privati cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. Attraverso quel JavaScript può sfruttare diverse risorse della vittima (cut&paste dal report) - their IP - their bandwith - their computing power - their RAM - their disk (through browser cache) - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown) e questo permette tutte una enorme varietà di attacchi la cui realizzazione è veramente banale.
In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un banalissimo DNS rebinding per penetrare la rete privata della vittima.
Ma sono solo due degli attacchi possibili: davvero qualunque sviluppatore web con un minimo di competenza e fantasia ne può pensare a bizzeffe. E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, anche all'insaputa del creatore del sito stesso: basta controllare l'hosting (il Cloud! chi controlla il Cloud?)
E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un paio di persone che analizzano i log quotidianamente).
ogni cosa fatta su un computer da remoto consente di acquisire informazioni, dalla latenza di un collegamento al fatto che il computer a cui si collega risponda o meno. (che e' l'esempio sotto)
Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL etc? Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa energia, non credi?
e se uno non vuole consentirlo ? su firefox basta usare plugin come noscript e/o umatrix
No, contro questi attacchi questi plugin non possono nulla.
Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché il server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo permesso di esecuzione sulla tua macchina.
tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio)
Io ad oggi consiglio di usare due browser: - un Firefox con JavaScript disabilitato da usare su tutti i siti che funzionano - un Chrome per tutti quelli che proprio non funzionano senza JS (e non si può evitare di usare).
Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due browser) è intrinsecamente fallace.
La OPT-IN SECURITY non funziona: basta un dipendente distratto per entrare nella rete di una banca con questi attacchi.
Abilitare l'esecuzione di JavaScript sito per sito, invece, è perfettamente usabile. Come lo è per le notifiche push di HTTP/2! E come lo era per Flash o per le Applet Java.
Ai miei occhi, tutto questo indignarsi per una soluzione semplice e ovvia come rendere JavaScript opt-in (e più sicuro) è prova di straordinaria disonestà intellettuale da parte di sviluppatori, come quelli di Mozilla, che si declamano campioni della privacy!
Giacomo
ciao, s.
On 13/09/2018 10:29, Marco Ciurcina wrote: "I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?)
Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork.
m.c.
In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto: Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374 <https://github.com/spesmilo/electrum/issues/3374>
https://rain-1.github.io/in-browser-localhostdiscovery <https://rain-1.github.io/in-browser-localhostdiscovery>
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa <https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa>
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa <https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa>
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Fantastico. :-) Onestamente mi ero perso il BeEF project. Grazie davvero per il link. Spero che a Mozilla, Google, Microsoft e Apple non fosse sfuggito, però! Sarebbe persino peggio della mala fede! Forse per questo non hanno risposto quando ho chiesto (ripetutamente) se i loro utenti fossero vulnerabili a questi attacchi o meno. Comunque il problema che ho posto io dipende in larga parte dal protocollo HTTP: - dagli header HTTP che permettono di identificare l'obbiettivo (ma può bastare l'IP, o il keep alive... per questo dicevo che ogni JS, ogni CSS e ogni risorsa esterna dovrebbe essere veicolata da una nuova connessione TCP e non contenere headers!) - dalle direttive di cache control che permettono di rimuovere le prove Tutto questo, unito ad un linguaggio di programmazione Turing complete, con accesso alle risorse suddette ed eseguito ciecamente dall'utente rende la superficie di attacco larghissima e il rischio minimo. E pensa poi con WebAssembly! Io mi sono già trovato a debuggare binari senza disporre del sorgente o dei simboli di debug. Chi dice che non cambierà niente perché anche oggi si offusca il JS, no sa di cosa parla. Giacomo Il giorno 13 settembre 2018 14:03, Stefano Traverso < s.traverso@ermessecurity.com> ha scritto:
Ciao Giacomo, Le cose sono a mio avviso anche piu’ preoccupanti. I ragazzi di BeEF project (https://github.com/beefproject/beef/wiki/ Introducing-BeEF) hanno dimostrato che con un po’ di JS si possono fare cose ben piu’ turpi di network/port scan. In primis raccogliere informazioni personali, ma si arriva anche a rubare credenziali e ottenere reverse shell su SO/browser obsoleti con relativa facitlita’.
Stefano
— Stefano Traverso, PhD Chief Technical Officer @ Ermes Cyber Security <https://www.ermessecurity.com> Mail: s.traverso@ermessecurity.com Skype: tigredcarta
On 13 Sep 2018, at 12:13, Giacomo Tesio <giacomo@tesio.it> wrote:
Scusa Stefano, mi rendo conto ora che forse non avevo capito il tuo dubbio.
Una volta entrato nella tua rete privata (o VPN) attraverso JS, posso trasferire informazioni sulla sua topologia all'esterno ed eseguire attacchi su eventuali servizi presenti in essa.
Sempre senza lasciare traccie.
Posso anche attacchare terze parti. Senza lasciare tracce del mio attacco, ma lasciando tracce che riconducono alla tua macchina.
Pensa quanto può essere utile questo in ambito di spionaggio industriale.
Spero di essere stato più chiaro...
Giacomo
Il giorno 13 settembre 2018 12:08, Giacomo Tesio <giacomo@tesio.it> ha scritto:
Aggiungo: come hacker mi può anche stare bene che alla comunità di Chromium e Mozilla non interessi prevenire questi attacchi. Ognuno deve essere libero di investire il proprio tempo per perseguire la PROPRIA curiosità.
Ma quello che non posso accettare è il tentativo (che a questo punto a me sembrerebbe evidente) di NON INFORMARE gli utenti.
Giacomo
Il giorno 13 settembre 2018 11:59, Giacomo Tesio <giacomo@tesio.it> ha scritto:
Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano@quintarelli.it> ha scritto:
cosa dovrebbe consentire javascript ?
Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere reso molto più sicuro attraverso piccole modifiche. In sintesi <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozil...> :
Anyway, to answer your question, the solution is simple, if it’s not easy. *The execution of Web software should be opt-in, not opt-out * (if you can opt-out, given how usable are the UI to disable JavaScript <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>).
Now, given the *severity of the issue*, as a first step I would release an *emergency fix that disable JavaScript* (and Meta Refresh) without looking at the user settings.
Then I would deploy a mid term fix so that:
- Page Refresh though META tag and JavaScript are disabled by default - Both can be enabled on a per website basis, but — No script or CSS is requested with Cookies or other HTTP headers — Each script and CSS is requested through a dedicated TCP connection <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> — SubResource Integrity <https://www.w3.org/TR/SRI/> is made mandatory (at least for JavaScript) — For each URI, record the SRI of last downloaded contents and warn the user if a page propose a different SRI for that same URI — Warn the user about scripts served with suspect HTTP headers - On browser exit, remove from the cache all resources downloaded by pages that have Meta Refresh and/or JavaScript enabled. - *View Page Source *should never fetch new versions of the page from the server <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> (whatever the HTTP Headers provided with the page are)
Obviously all this leaves the door open for pages that:
- are visited only once - are visited for the first time
thus I would also mark as “Not Secure” <https://www.blog.google/products/chrome/milestone-chrome-security-marking-ht...> web pages visited for the first time that require JavaScript.
(scusa il cut&paste, ma sono un po' di corsa)
Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano@quintarelli.it> ha scritto:
puo' collegarsi a computer diversi da quello dell'utente ? certamente, per comunicare con il server da cui proviene.
può scaricare oggetti, diciamo immagini, da un computer con un determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla webmail)
una alternativa potrebbe essere che consenta di comunicare solo con il computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario).
queste due cose che consente, possono essere usate da qualcuno per acquisire informazioni ?
No.
Attraverso l'uso appropriato degli header HTTP (cache control etc), qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le tracce di un attacco. Se il server (o la CDN) può identificare l'obbiettivo (non solo privati cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. Attraverso quel JavaScript può sfruttare diverse risorse della vittima (cut&paste dal report)
- their IP - their bandwith - their computing power - their RAM - their disk (through browser cache) - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown)
e questo permette tutte una enorme varietà di attacchi la cui realizzazione è veramente banale.
In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un banalissimo DNS rebinding per penetrare la rete privata della vittima.
Ma sono solo due degli attacchi possibili: davvero qualunque sviluppatore web con un minimo di competenza e fantasia ne può pensare a bizzeffe. E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, anche all'insaputa del creatore del sito stesso: basta controllare l'hosting (il Cloud! chi controlla il Cloud?)
E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un paio di persone che analizzano i log quotidianamente).
ogni cosa fatta su un computer da remoto consente di acquisire
informazioni, dalla latenza di un collegamento al fatto che il computer a cui si collega risponda o meno. (che e' l'esempio sotto)
Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL etc? Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa energia, non credi?
e se uno non vuole consentirlo ?
su firefox basta usare plugin come noscript e/o umatrix
No, contro questi attacchi questi plugin non possono nulla.
Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché il server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo permesso di esecuzione sulla tua macchina.
tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio)
Io ad oggi consiglio di usare due browser: - un Firefox con JavaScript disabilitato da usare su tutti i siti che funzionano - un Chrome per tutti quelli che proprio non funzionano senza JS (e non si può evitare di usare).
Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due browser) è intrinsecamente fallace.
La OPT-IN SECURITY non funziona: basta un dipendente distratto per entrare nella rete di una banca con questi attacchi.
Abilitare l'esecuzione di JavaScript sito per sito, invece, è perfettamente usabile. Come lo è per le notifiche push di HTTP/2! E come lo era per Flash o per le Applet Java.
Ai miei occhi, tutto questo indignarsi per una soluzione semplice e ovvia come rendere JavaScript opt-in (e più sicuro) è prova di straordinaria disonestà intellettuale da parte di sviluppatori, come quelli di Mozilla, che si declamano campioni della privacy!
Giacomo
ciao, s.
On 13/09/2018 10:29, Marco Ciurcina wrote:
"I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?)
Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork.
m.c.
In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto:
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from > addresses 192.168.1.x. If you watch in the browser console it’ll show > either net::ERR_CONNECTION_REFUSED for a host that’s up or > net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is > a CORS > error which the javascript on the webpage is not allowed to > differentiate > by catching. But one error takes 3 ms to happen and the other takes 3 > seconds! > [...] > A related thing a webpage in your browser might do is connect to > localhost > and control any unauthenticated local services. Taviso used this to > great > effect here https://github.com/spesmilo/electrum/issues/3374 >
https://rain-1.github.io/in-browser-localhostdiscovery
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Ciao a tutti e buon anno! Riapro questo vecchio thread per segnalarvi una notizia divertente ma serissima. La home page del sito rkn.GOV.RU sta utilizzando l'attacco che descrissi nell'articolo https://dev.to/shamar/the-meltdown-of-the-web-4p1m contro tutti i visitatori (per cui vi sconsiglio di andare a vedere in questo momento se il vostro browser esegue JavaScript. Il governo russo sta utilizzando JavaScript per entrare nella rete dei visitatori ed identificare gli IP (e potenzialmente le persone, incrociando l'IP con i log di altri servizi) che utilizzano alcuni tool di sicurezza durante la navigazione web. Qui potete vedere lo script ben formattato: https://pastebin.com/embed_iframe/2VH55Lu0 alla riga 2615 trovate la lista dei tool di cui si verifica la presenza. In pratica, stanno creando un database degli IP (e in Russia delle persone) che è meglio NON attaccare via JavaScript perché potrebbero rilevare l'attacco nonostante la rimozione delle prove attraverso gli header HTTP di controllo della cache. Ho naturalmente segnalato la cosa a Mozilla, ma probabilmente sono ancora tutti in ferie: https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c16 (PS: attenti a cosa cliccate! ;-) Ovviamente, l'elenco delle persone da NON attaccare serve se VUOI USARE quegli attacchi. Al contempo queste persone stanno prendendo precauzioni di sicurezza piuttosto avanzate: cosa avranno da nascondere? :-) Tecnicamente questa appare come una applicazione piuttosto grossolana dei miei attacchi: Google, Cloudflare o Amazon potrebbero essere molto più raffinati e non farsi beccare. Il governo russo però non intercetta la stessa quantità di traffico e dunque deve andare a pescare con la rete dove altri userebbero il bisturi. L'aspetto più divertente? Se questa notizia diventasse mainstream, il governo russo potrebbe dichiarare che si tratta di un semplice errore di programmazione: l'incompetenza è così diffusa nel nostro settore che molti ci crederebbero, accettando l'incompetenza come giustificazione plausibile di un attacco di massa! Il Web è ancora un'arma del DARPA, ma ogni tanto la prestano agli alleati più fidati! :-D https://medium.com/@giacomo_59737/the-web-is-still-a-darpa-weapon-31e3c3b032... A presto! Giacomo
Osservazione a margine: la lista Nexa sta diventando sempre più tecnica! Nel merito: On 13/09/2018 10:56, Stefano Quintarelli wrote:
cosa dovrebbe consentire javascript ? Sorprende (o meglio, ahimè, non sorprende più, fa solo rabbia) che si commettano sempre gli stessi errori: gli script nei file microsoft word, nei PDF, perfino Postscript nelle stampanti: <https://www.securityweek.com/printer-vulnerabilities-expose-organizations-at...>. Javascript nei browser non dovrebbe poter mandare richieste HTTP con contenuto arbitrario a destinazioni arbitrarie. Punto. Ci libereremmo di un bel po' di botnet.
puo' collegarsi a computer diversi da quello dell'utente ? certamente, per comunicare con il server da cui proviene.
può scaricare oggetti, diciamo immagini, da un computer con un determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla webmail)
una alternativa potrebbe essere che consenta di comunicare solo con il computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario).
Con l'attuale architettura non funzionerebbe quasi nulla: gli script raramente risiedono nel sito che li richiede e quindi quasi mai parlano col sito dal quale vengono. Se fossero autorizzati gli script solo del sito dal quale proviene la pagina principale escluderesti apis.google.com e miriadi di altri, sui quali risiedono quasi tutti gli script (e i font) usati in giro (favorendo ovviamente il tracking). Se però, come richiede molto ragionevolmente Giacomo, dovessimo espressamente autorizzare gli script che usano "liberamente" la rete, rischieremmo lo stesso effetto dei privacy cookies: dovresti farlo così spesso che alla fine autorizzeremmo senza guardare, aprendo la strada a attacchi più gravi di script che accedono a telecamera, microfono, dati, ecc... Oppure cambia l'architettura: il browser costruisce una macchina virtuale per ogni pagina e parla con un indirizzo alla volta, o al limite solo con quelli autorizzati in un campo dell'header HTTP ad hoc, o con quelli indicati da un meccanismo analogo a SPF per la mail. Ma se mi chiedi di scommettere, direi che la soluzione proposta sarà un sistema centralizzato di certificazione e firma degli script, stile app. Così "per la tua sicurezza" ti verrà chiesto di autorizzare solo gli script "non certificati sicuri" (come avviene per i certificati SSL) che non vengono da uno dei soliti repository. Sempre perché si commettono sempre gli stessi errori.
queste due cose che consente, possono essere usate da qualcuno per acquisire informazioni ? ogni cosa fatta su un computer da remoto consente di acquisire informazioni, dalla latenza di un collegamento al fatto che il computer a cui si collega risponda o meno. (che e' l'esempio sotto) Potresti anche inconsapevolmente contribuire a un repository "distribuito" di materiale che qualcun'altro non vuole tenere in casa: <https://github.com/seantmalone/HiveMind> Oppure un dispettoso potrebbe lasciarti del materiale di cui faresti fatica a giustificare il possesso in caso di sequestro.
e se uno non vuole consentirlo ? su firefox basta usare plugin come noscript e/o umatrix tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio)
Mi associo caldamente alla raccomandazione. Umatrix è formidabile. Alberto
On 13/09/2018 10:29, Marco Ciurcina wrote:
"I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?)
Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork.
m.c.
In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto:
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374
https://rain-1.github.io/in-browser-localhostdiscovery
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Il giorno 13 settembre 2018 17:12, Alberto Cammozzo <ac+nexa@zeromx.net> ha scritto:
Osservazione a margine: la lista Nexa sta diventando sempre più tecnica!
Io direi piuttosto che questa lista crea un dialogo costruttivo fra persone con competenze tecniche diverse: diritto, informatica, economia, sociologia... Da dialoghi come questi, secondo me, dovrebbero emergere le sintesi Politiche anche in Parlamento. L'idea della Politica come professione, come competenza a se stante, secondo me è profondamente contraria ai valori democratici espressi dalla Costituzione della Repubblica Italiana agli articoli 1, 56, 58 e 67. Altrimenti, con un paio di concorsi pubblici potremmo risparmiarci campagne elettorali ed elezioni!
Nel merito:
On 13/09/2018 10:56, Stefano Quintarelli wrote:
cosa dovrebbe consentire javascript ? Sorprende (o meglio, ahimè, non sorprende più, fa solo rabbia) che si commettano sempre gli stessi errori: gli script nei file microsoft word, nei PDF, perfino Postscript nelle stampanti: <https://www.securityweek.com/printer-vulnerabilities-expose-organizations-at...>.
Hai ragione, non impariamo mai. Per questo secondo me dobbiamo partire dalle elementari. Per creare una generazione di hacker capaci di non ripetere (e di difendersi/difenderci da) i nostri errori.
Javascript nei browser non dovrebbe poter mandare richieste HTTP con contenuto arbitrario a destinazioni arbitrarie. Punto. Ci libereremmo di un bel po' di botnet.
Se può aggiungere HTML al DOM della pagina, può far partire richieste HTTP.
Se però, come richiede molto ragionevolmente Giacomo, dovessimo espressamente autorizzare gli script che usano "liberamente" la rete, rischieremmo lo stesso effetto dei privacy cookies: dovresti farlo così spesso che alla fine autorizzeremmo senza guardare, aprendo la strada a attacchi più gravi di script che accedono a telecamera, microfono, dati, ecc...
Per la verità la mia proposta è un po' più articolata, ma non propone una tale precisione nei permessi. Poter semplicemente abilitare JS per sito web (e dunque averlo disabilitato di default) ridurrebbe del 95% l'ammontare di JavaScript in transito sul web. La stragrande maggioranza delle pagine web che usa JS non ne ha veramente bisogno.
Oppure cambia l'architettura: il browser costruisce una macchina virtuale per ogni pagina e parla con un indirizzo alla volta, o al limite solo con quelli autorizzati in un campo dell'header HTTP ad hoc, o con quelli indicati da un meccanismo analogo a SPF per la mail.
Preferirei avere il controllo su cosa eseguire sui miei device. In generale.
Ma se mi chiedi di scommettere, direi che la soluzione proposta sarà un sistema centralizzato di certificazione e firma degli script, stile app. Così "per la tua sicurezza" ti verrà chiesto di autorizzare solo gli script "non certificati sicuri" (come avviene per i certificati SSL) che non vengono da uno dei soliti repository. Sempre perché si commettono sempre gli stessi errori.
Beh.. ma ci sarà qualcuno al mondo capace di dire "No" a questa gente!
Potresti anche inconsapevolmente contribuire a un repository "distribuito" di materiale che qualcun'altro non vuole tenere in casa: <https://github.com/seantmalone/HiveMind>
Quinto attacco che mi è venuto in mente. :-)
Oppure un dispettoso potrebbe lasciarti del materiale di cui faresti fatica a giustificare il possesso in caso di sequestro.
Primo attacco che mi è venuto in mente. Il secondo è stato: metto materiale illegale (lista dei pagamenti del pizzo, pedopornografia, progetti rubati alla concorrenza) nella cache del browser, così se mi sequestrano il PC, la sola esistenza di questi attacchi mi fornisce una giustificazione plausibile.
e se uno non vuole consentirlo ? su firefox basta usare plugin come noscript e/o umatrix tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio)
Mi associo caldamente alla raccomandazione. Umatrix è formidabile.
Non discuto la qualità di questi tool. Qui trovate istruzioni precise su come rendere Firefox un browser decente dal punto di vista di sicurezza: http://sciops.net/information/browser_setup/firefox Ma anche quelle istruzioni, non possono niente contro questi attacchi. La sicurezza non deve essere OPT-IN. Giacomo
2018-09-13 10:29 GMT+02:00 Marco Ciurcina <ciurcina@studiolegale.it>:
"I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?)
Ah, se ti interessa la censura in ambito informatico (e avete un attimo) questa è fantastica: https://dev.to/shamar/i-have-been-banned-from-lobsters-ask-me-anything-5041 (breve resoconto cronologico qui: https://dev.to/shamar/comment/5dp2#chronological ) Una volta si usava dire "you cannot argue with a root shell"... oggi invece si può. Anche di fronte a DUE exploit, puoi continuare a negare. E chiamare i tuoi fan boy a giustificarti.
Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork.
Con tutto il rispetto Marco, devo contraddirti: Firefox è evidentemente Open Source, non Software Libero. Il software libero è un'espressione della cultura hacker, un atto creativo di curiosità. Come tale l'onestà intellettuale è un prerequisito fondamentale del software libero. Firefox è Open Source, una cosa molto diversa: https://twitter.com/giacomotesio/status/1035553204552040448 Ed infatti, forkare Firefox richiede enormi risore. Io sono un programmatore ("solo" un programmatore, come dice Bruce Perens :-D): il codice è ben fatto e modificarlo è relativamente semplice, ma per l'infrastruttura necessaria a mantenere un fork utile per mettere in sicurezza la gente, su device e sistemi operativi diversi, è estremamente complessa. Se non risolvono il problema prima, da metà ottobre (prima non riesco) farò qualche prova su Windows per Desktop. Ho già pensato un nome: "Guy Fawkes", il fork di Firefox destinato a morire... :-D Giacomo
m.c.
In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto:
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374
https://rain-1.github.io/in-browser-localhostdiscovery
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
In data giovedì 13 settembre 2018 10:58:08 CEST, hai scritto:
Con tutto il rispetto Marco, devo contraddirti: Firefox è evidentemente Open Source, non Software Libero. Dal menù "Aiuto", voce "Informazioni su Firefox", link "Informazioni sulla licenza" della versione di Firefox che ho sul mio PC leggo: "All of the *source code* to this product is available under licenses which are both free[1] and open source[2]." Secondo me intendono "free software and open source": infatti la parola "free" è linkata a http://www.gnu.org/philosophy/free-sw.html.
Non ho motivo di dubitare che le licenze secondo le quali è disponibile Forefox rispettano la definizione di software libero. Quindi penso di non sbagliare se scrivo che Firefox è software libero.
Il software libero è un'espressione della cultura hacker, un atto creativo di curiosità. Come tale l'onestà intellettuale è un prerequisito fondamentale del software libero.
Firefox è Open Source, una cosa molto diversa: https://twitter.com/giacomotesio/status/1035553204552040448
mm.. Se capisco il tuo punto, intendi dire che gli sviluppatori di Firefox e Chrome sono "Opensursari" e non hanno un chiaro standing etico. Mi pare condivisibile. Ma il software è software e non ha intenzioni etiche. Come scrivevo questa mattina, Firefox ci dice: "I'm not bad. I'm just drawn that way.". :-) Il software libero è il software disponibile secondo una licenza che soddisfa i requisiti della definizione di software libero. L'espressione open source definisce le licenze che soddisfano l'open source definition. Nella sostanza, i due insiemi (licenze di software libero e licenze open source) sono quasi coincidenti. Personalmente, preferisco usare l'espressione software libero per riferirmi al software che è software libero / open source perché l'espressione software libero richiama implicitamente i valori di libertà e comunità (che trovo importanti). L'espressione open source, invece, è nata proprio per omettere questo richiamo ai valori (che i fondatori della Open Source Initiative ritenevano d'intralcio nella diffusione in ambito "industriale"). m.c. -------- [1] http://www.gnu.org/philosophy/free-sw.html [2] http://www.opensource.org/docs/definition.php
La tua è una opinione diffusa fra i giuristi. Il 13 settembre 2018 17:54, Marco Ciurcina <ciurcina@studiolegale.it> ha scritto:
Ma il software è software e non ha intenzioni etiche.
Al contrario! La Tecnologia è il proseguimento della Politica con altri mezzi! Il Software Libero orienta l'attività politica costituita dalla programmazione verso un sistema etico e politico che deriva da un valore cardine: la Curiosità. La libertà del software è un valore fondamentale, ma comunque strumentale alla curiosità, al bisogno dell'hacker di scoprire, di provare, di esplorare. Un altro valore fondamentale, ma derivato dalla Curiosità è l'onestà intellettuale: l'importante è comprendere la realtà, imparare... non avere ragione. L'Open Source, sin dalla sua definizione si oppone a questi valori che cerca di marginalizzare (con grande succcesso).
Il software libero è il software disponibile secondo una licenza che soddisfa i requisiti della definizione di software libero.
L'espressione open source definisce le licenze che soddisfano l'open source definition.
Nella sostanza, i due insiemi (licenze di software libero e licenze open source) sono quasi coincidenti.
Questa è una opinione molto diffusa fra i giuristi. Ho discusso con Carlo Piana estensivamente in passato su questo punto. Se proiettati sul piano legale, avete ragione: sono indistinguibili. Ma non possiamo limitarci a questa dimensione. Come puoi vedere da questa storia, la distanza è enorme. Sul piano culturale, politico, sociale... e non pensare che tutte queste differenze non si esprimano sul codice! Ora, l'Open Source non è cattivo, ma è solo uno strumento di marketing. Uno strumento utilissimo! Ottimo software. Ma è "neutro", come dicevi tu. Solo che il Software Libero invece non è neutro! E mentre il Software Libero viene deriso per i propri valori, l'Open Source se ne appropria come strumento di marketing mentre li svuota di significato. Giacomo
Il 13 settembre 2018 18:14, Giacomo Tesio <giacomo@tesio.it> ha scritto:
Ora, l'Open Source non è cattivo, ma è solo uno strumento di marketing. Uno strumento utilissimo! Ottimo software. Ma è "neutro", come dicevi tu.
ERRATA CORRIGE: l'open source NON E' DAVVERO "NEUTRO"! Dice di esserlo. Finge di esserlo. Come Firefox dice di essere software libero. Ma nessuna azione politica è veramente neutra. E programmare è una azione politica. Giacomo
In data giovedì 13 settembre 2018 18:14:07 CEST, Giacomo Tesio ha scritto:
La tua è una opinione diffusa fra i giuristi. Allora deve essere la verità oggettiva :-)
Il 13 settembre 2018 17:54, Marco Ciurcina <ciurcina@studiolegale.it>
ha scritto:
Ma il software è software e non ha intenzioni etiche.
Al contrario!
La Tecnologia è il proseguimento della Politica con altri mezzi!
Sono d'accordo. Ma questo non contraddice il fatto che il software non ha intenzioni etiche. Il software esprime le intenzioni etiche di chi lo sviluppa o usa. Ma il software non ha intenzioni etiche. Forse usiamo la parola intenzione in modo diverso? Per me l'intenzione viene espressa da un ente capace di atti di volontà. Un oggetto (come il software) non ha intenzione. Può essere, invece, l'oggetto dell'intenzione di un agente (che sceglie di svilupparlo in un certo modo, di usarlo o non usarlo).
Il Software Libero orienta l'attività politica costituita dalla programmazione verso un sistema etico e politico che deriva da un valore cardine: la Curiosità.
Concordo. Ma non solo. Secondo altri, la scelta di licenziare del software come software libero risponde alla scelta etica di rispettare gli utenti: la loro libertà e la loro possibilità di cooperare.
Come puoi vedere da questa storia, la distanza è enorme. Sul piano culturale, politico, sociale... e non pensare che tutte queste differenze non si esprimano sul codice! Sono d'accordo. L'intenzione di chi scrive il software realizza le sue scelte. Ma il software in se non ha intenzioni!
Ora, l'Open Source non è cattivo, ma è solo uno strumento di marketing. Uno strumento utilissimo! Ottimo software. Ma è "neutro", come dicevi tu.
Qualsiasi software è sviluppato facendo delle scelte. Gli sviluppatori di Firefox fanno delle scelte. Di solito diffido di chi propone la sua posizione come "neutra". m.c.
Il 13 settembre 2018 20:24, Marco Ciurcina <ciurcina@studiolegale.it> ha scritto:
Ma il software è software e non ha intenzioni etiche.
Al contrario!
La Tecnologia è il proseguimento della Politica con altri mezzi! Sono d'accordo. Ma questo non contraddice il fatto che il software non ha intenzioni etiche. Il software esprime le intenzioni etiche di chi lo sviluppa o usa. Ma il software non ha intenzioni etiche.
Ok. Siamo quasi d'accordo: il software è un artefatto (definirlo "oggetto" lo inserisce nel mondo materiale, cui non appartiene) Ed almeno per i prossimi 1000 o 2000 anni anni resterà tale, artefatto privo di volontà autonoma e quindi non imputabile di responsabilità alcuna. Con buona pace dei futuristi. E di chi produce le auto autonome. Il software è un artefatto umano, non una creatura intelligente. Per me questo è un fatto oggettivo che non necessita di dimostrazione.
Forse usiamo la parola intenzione in modo diverso?
No, credo sia la parola "software" che usiamo in modo diverso.
Per me l'intenzione viene espressa da un ente capace di atti di volontà. Un oggetto (come il software) non ha intenzione. Può essere, invece, l'oggetto dell'intenzione di un agente (che sceglie di svilupparlo in un certo modo, di usarlo o non usarlo).
La Legge è un artefatto umano del tutto simile al software. La Legge ha intenzione? No. E pur tuttavia, se non comprendiamo l'intenzione del legislatore, non comprendiamo la legge stessa. Come programmatore, sono io a decidere, con assoluta precisione, cosa puoi o cosa non puoi fare con il software che creo, indipendentemente dalla licenza. Per cui quando decidi di usare un software ti leghi alla comunità (o alla persona) che lo sviluppa. Ignorare la cultura o gli interessi di quella comunità è miope. Potrebbero decidere di introdurre una back door. O cambiare completamente il formato. O abbandonarlo. Ridurre la legge al testo, o ridurre l'opera d'arte al materiale di cui è costituita, priva completamente l'artefatto del suo scopo e della sua utilità. E la stessa cosa vale per il software: anche se è espresso in una forma binaria adatta ad un supporto materiale, RIMANE una espressione delle persone che lo hanno scritto. Questo legame che può sembrare invisibile per chi vede solo il CD o l'icona sul desktop, è in realtà evidente per chi il software lo scrive. Ed è un legame fortissimo. Ed è un legame pratico!
Il Software Libero orienta l'attività politica costituita dalla programmazione verso un sistema etico e politico che deriva da un valore cardine: la Curiosità. Concordo. Ma non solo. Secondo altri, la scelta di licenziare del software come software libero risponde alla scelta etica di rispettare gli utenti: la loro libertà e la loro possibilità di cooperare.
E' sempre questione di Curiosità. Gli hacker sono gente strana. Attraverso la Condivisione, prendiamo due piccioni con una fava: - servire l'Umanità attraverso la nostra curiosità - servire la nostra curiosità attraverso l'Umanità E' una scelta etica. La Condivisione è sicuramente il terzo pilastro dell'etica hacker, insieme a libertà ed onestà intellettuale. Ma rimane strumentale alla Curiosità. E' questo il vero scopo della libertà 1, di studiare e modificare il software: diffondere la curiosità, trasformare l'utente in hacker, fargli scoprire nuove cose in modo che ce le possa insegnare. Microsoft non sbagliava a definire "virale" la GPL! Il nostro scopo è contagiarvi. Contagiarvi tutti. Il prima possibile! Possibilmente fin da bambini... Contagiarvi con la nostra Curiosità.
Come puoi vedere da questa storia, la distanza è enorme. Sul piano culturale, politico, sociale... e non pensare che tutte queste differenze non si esprimano sul codice! Sono d'accordo. L'intenzione di chi scrive il software realizza le sue scelte. Ma il software in se non ha intenzioni!
Il file che il tuo computer esegue non ha intenzioni. Ma il software, come espressione umana, veicola costantemente le intenzioni di chi lo ha creato.
Ora, l'Open Source non è cattivo, ma è solo uno strumento di marketing. Uno strumento utilissimo! Ottimo software. Ma è "neutro", come dicevi tu. Qualsiasi software è sviluppato facendo delle scelte. Gli sviluppatori di Firefox fanno delle scelte. Di solito diffido di chi propone la sua posizione come "neutra".
Anche io. Per questo diffido di chi non riconosce l'aspetto politico della tecnologia. E per questo diffido dell'Open Source, che sin dalla nascita ha ridotto la questione esclusivamente alla conformità della licenza a determinati parametri. Mentre lo SCOPO della GPL era diffondere l'ETICA hacker. Giacomo PS: scusate il pippotto. Qualcuno potrebbe accusare tutto questo di essere "mera filosofia". Ed io mi dichiaro colpevole: la Curiosità non è altro che Amore del Sapere. ;-)
participants (5)
-
Alberto Cammozzo -
Giacomo Tesio -
Marco Ciurcina -
Stefano Quintarelli -
Stefano Traverso