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.

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).

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
     — SubResource Integrity 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 (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” 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