[18812] in Athena Bugs
A way to get asymmetric zephyr subs
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Feb 23 00:59:02 2001
Date: Fri, 23 Feb 2001 00:58:47 -0500
Message-Id: <200102230558.AAA07060@egyptian-gods.MIT.EDU>
From: Greg Hudson <ghudson@MIT.EDU>
To: bugs@MIT.EDU
Okay, this is a placeholder for a bug I may or may not do anything
about, just to make sure it's written up. I do not think it is how
users get asymmetric subs in the majority of cases, but it is still a
poor failure mode and a confusing variable in the whole asymmetric
subs equation.
When you send a packet to zephyrd, it checks the krb4 authenticator
against the source IP address of of the packet (dispatch.c rev 1.60
line 208). Depending on the type of message and the success or
failure of the operation, it may then forward the packet to the other
zephyrs. When the other zephyrds receive the message, they check the
krb4 authenticator against the z_sender_addr (aka zuid.zuid_addr)
field of the notice (dispatch.c rev 1.60 line 198).
If z_sender_addr does not match the incoming source IP address
(usually, this means the user is using zephyr 2.0.4 and has an
hostname which doesn't resolve to the outgoing interface address), the
results of the authentication checks might not match, and you might
get asymmetric subs as a result.
Possible fixes to this bug include:
* When forwarding packets between servers, send the incoming
source address, or alternatively the authentication value,
to the other servers along with the packet. This is pretty
much a non-starter given zephyrd's design, but I thought I
would mention it.
* Always check the packet against z_sender_addr, even on the
server the packet was sent to directly. This is probably a
bad idea, since it would make it possible to fake out the
krb4 IP address checking by lying in your z_sender_address
field for control-type notices (see below).
* On the server which receives the notice directly, we could
mark a notice unauthentic if z_sender_addr != incoming
source addr. This does not guarantee consistency of the
authentication check in all cases, but it does prevent
asymmetric subs since an unauthentic sub request won't get
forwarded (because it will fail).
* On the server which receives the notice directly, we could
reject packets entirely if z_sender_addr != incoming source
addr. (zephyrd currently reject notices being sent to other
users in this case, unless z_sender_addr is 0. Other kinds
of notices such as subscription notices don't currently have
any such restriction.)
* We could stop checking the krb4 authenticator against the IP
address altogether (like AFS and some other services), by
providing a source address of 0 to krb_rd_req.
Incidentally, you might think that you can currently fake out the krb4
IP address checking (on servers other than the one you're sending to
directly) by lying in the z_sender_addr field. I believe this is
impossible because:
* I believe no unauthentic operation is forwarded except for a
notice being sent to other users.
* A notice being sent to other users won't be forwarded if
z_sender_addr != incoming source addr, unless z_sender_addr
is 0. (And 0 is unlikely to be the IP addr in the krb4
ticket you're trying to fake.)
But it's certainly not a very robust situation.
