Newsgroup: it.fan.marco-ditri
Titolo: [BLOG] on IDN and bad reporting (2005-02-09)

(#76) on IDN and bad reporting
James Seng explained in his blog[0] why the IDN{0} "exploit" is nothing
new or interesting. The issues related to homographs have been known
for years and are not a peculiarity of IDNs, so this is nothing more
than PR for a "security" group and was not worth even a slashdot story.
The mutt upstream maintainer commited an option to disable IDN support,
but I have no plan to rush adding the code to the Debian package.
Spoofing email headers does not require using IDNs...
Andre Luis Lopes totally missed the point[1] about timeouts in name
resolution: there is nothing wrong with 2.6 kernels, except that until
recently all kernels used to automatically install an IPv6 default
route even if no router was detected. The real problem is that BIND{1}
versions precedent to 9.3 did not correctly implement timeouts for
queries to name servers with both A and AAAA records and kept trying to
query unreachable addresses if IPv6 connectivity is configured but not
working.
The correct workarounds are upgrading BIND to 9.3, upgrading the kernel
or installing a default unreachable route with a low metric (like ip -6
route add unreachable default dev lo metric 1400). And BTW, alias
module off is not a valid syntax for modprobe.conf.
Wouter Verhelst instead showed a complete misunderstanding of how
spamming works nowadays[2]: sending junk traffic to spam sources would
not harm spammers, because almost all relevant spam sources are either
compromised computers or the mail hubs of large ISPs. And the few
spammers spamming from their own IP addresses can be easily filtered.
[0]
http://james.seng.cc/archives/2005/02/08/idn_and_homographs_spoofing.ht
ml
[1] 
http://www.advogato.org/person/andrelop/diary.html?start=12
[2] 
http://www.livejournal.com/users/wouterverhelst/57950.html
{0} internationalized domain names
{1} Berkeley Internet Name Domain
Posted at 15:00:17. [
http://blog.bofh.it/id_76
]
-----------------------------------------------------------------------------

 Spoofing email headers does not require using IDNs...
Su questo, sono completamente d'accordo. Una patch in mutt, non e` molto
utile, per il motivo che tu stesso descrivi. Altro paio di maniche per
quanto riguarda il browser.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
God does not play dice with the Universe.    -- Albert Einstein.

 Se interessa, posto il metodo che ho seguito io, che funziona.
eh... magari.

auspicabile.
Non ho detto che non lo sia, ma che si tratta di roba risaputa.
-- 
ciao, | Those people who think they know everything
Marco | are a great annoyance to those of us who do. (Isaac Asimov)

 Non ho detto che non lo sia, ma che si tratta di roba risaputa.
Ok, capito. Mah, in realta`, qualunque grosso tema di security degli
ultimi 5 anni, ha questo problema, tanto per citarne uno: i format
string vulnerability, se non sbaglio, sono indicati nel K&R, almeno 12
anni prima... 
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
A good system can't have a weak command language.

 eh... magari.
Appurato che la modifica della variabile, via browser, non produce
risultati definitivi (al riavvio la var risulta False, ma lo spoof
funziona ancora), ho proceduto in questo modo.
Ho preferito un approccio per user, ma e` possibile farlo syswide.
per user, modifico nei file di preferenze di mozilla/firefox
dell'utente, il file compreg.dat:
tipicamente, esso e` in:
$HOME/.mozilla/firefox/xxxxxxxxxxx.Default User/
syswide, ovviamente in qualcosa tra
/usr/lib/mozilla/comonents
/usr/lib/mozilla-firefox/components
Ricerca, in tale file la sezione [CONTRACTIDS]
cerca nella sezione, la linea:
@
mozilla.org/network/idn-service;1,{62b778a6-bce3-456b-8c31-2865fbb68c91}
(o simile) e poni a "zero", il servizio, cosi`:
@
mozilla.org/network/idn-service;0,{62b778a6-bce3-456b-8c31-2865fbb68c91}
A questo punto, e` definitivo, in attesa di un eventuale aggiornamento
da parte del team mozilla.
NB: non uso galeon, ma pare che nel suo caso, devi per forza agire
syswide. un "locate compreg.dat" dovrebbe aiutare.
Sotto windows, ovviamente, basta applicare gli stessi principi
(adeguando i percorsi).
Url, di testing e info: 
http://www.shmoo.com/idn/
HTH.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Why is "abbreviation" such a long word?

 HTH.
grazie!

da parte del team mozilla.
L'aggiornamento con il fix c'è già stato.
Il fix vero è indicare (per esempio con un colore diverso) i caratteri
strani, ma prima bisogna trovare un algoritmo che identifichi cosa è
strano in ogni contesto...


 strano in ogni contesto...
Yep. Cosa ne pensi della comunicazione di "quelli di opera", che stando
all'annuncio di 
shomoo.com
, avrebbero risposto:
"Opera:  They believe they have correctly implemented IDN, and will not
be making any changes."
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
If you don't succeed redefine success