Fwd: XXFwd: [unisog] Attacks on AFS]

[Love]

Keith Johnston <keith at cs.auckland.ac.nz> writes:

> Has anyone else been receiving this attention? We were already
> blocking the port in question so it has not caused us problems but we
> have been having other hardware hassles.

Since it originated here from KTH, yes.

It is a memory corruption bug in the IBM/afs client trigged by a
afs-crawler. The afs-crawler was written to determine how large afs really
is and what clients people are using. The result would have been presented
on the afs workshop at usenix on a couple of days. (This work was not
sponsored or supported by usenix, it was a paper to the afs afs workshop).

No arla version have this problem, same is true for OpenAFS > 1.2.0.

Blocking the port is bad, since it mean the the clients can't break
callback and the server can't initialize connection to the callback
managers. So if you have too many clients outside your block you can run of
of threads in the fileserver and cause a denial of service on yourself !
If not running some late version of openafs.

I don't want to have discussion about the ethical issues of writing and/or
using a afs-crawler on this list. The authors of the probe have stopped
doing it and are really sorry for the problems they have caused.

Your options if you don't like to have a broken client are: upgrade to a
non broken client (arla, or openafs > 1.2.0), wait for IBM/afs to respond
to our mail (guess they are sleeping now) and have then make a new release.

Please excuse any fuzzyness in my post, I'm not that interested in showing
people how to DOS me before every vendors had ha chance to fix their
client.

You can find out what version you are running with

  rxdebug -version -port {7001,4711} host

: lha at nutcracker ; rxdebug -version -port 4711 -server localhost
Trying 127.0.0.1 (port 4711):
AFS version: arla-0.36pre



Love