- Wednesday, January 28, 2015

openafs@conference.openafs.org

Wednesday, January 28, 2015< ^ >

Room Configuration

Room Occupants

GMT+0
[03:34:42] ballbery leaves the room
[03:35:02] ballbery joins the room
[03:37:25] ballbery leaves the room
[03:37:37] ballbery joins the room
[05:33:00] jhutz@jis.mit.edu/owl leaves the room
[06:08:54] jhutz@jis.mit.edu/owl joins the room
[12:02:11] stephan.wiesand joins the room
[12:18:09] <stephan.wiesand> Are OenAFS servers or clients vulnerable to GHOST?
[12:33:45] stephan.wiesand leaves the room
[13:25:24] <jhutz@jis.mit.edu/owl> Well, they're not glibc.
[13:26:29] <jhutz@jis.mit.edu/owl> Someone suggested to me that afsdb lookups might be a vector, but
I'm not convinced.  Otherwise, offhand, I'm not aware of places where
we do lookups of hostnames that come from untrusted sources.
[13:35:24] ballbery leaves the room
[13:36:00] ballbery joins the room
[14:01:32] wiesand joins the room
[14:08:08] <jhutz@jis.mit.edu/owl> I took a quick look.  In general, we only call gethostbyname on hostnames
from reasonably trusted sources like config files or command-line
arguments.  There are two exceptions.
[14:09:41] <jhutz@jis.mit.edu/owl> One exception is AFSDB lookups, where we call gethostbyname on the server
name in an AFSDB record.  However, first is has to be expanded, which we
do into a 256-byte buffer.  That means we can't be calling gethostbyname
with a hostname longer than 256 bytes, and you need something over 1K
to trigger the bug.
[14:10:38] <wiesand> Thanks a lot.
[14:10:44] <jhutz@jis.mit.edu/owl> The second is the rmtsys mechanism.  An unprivileged user could convince
an AFS utility running as root to look up a hostname contained in an
environment variable or in one of the user's dotfiles.  AFAIK, this is
the only real attack vector.
[14:10:52] <jhutz@jis.mit.edu/owl> But really, fix your glibc
[14:11:31] <wiesand> Working on it... the question is whether openafs processes need to be restarted afterwards.
[14:57:06] meffie joins the room
[14:59:15] shadow@gmail.com/barnowlC91EEAD3 joins the room
[14:59:28] shadow joins the room
[15:01:23] <shadow> of course, you only have an rmtsys mech if afsd is started with -rmtsys, which by default it is not
[15:06:05] <shadow> and yeah, jaltman reminds me client half. but still, if you want to crash fs or pagsh there are probably better ways
[15:23:56] shadow leaves the room
[15:47:50] <jhutz@jis.mit.edu/owl> > you only have an rmtsys mech if afsd is started with -rmtsys
No, that's irrelevant.  The client libraries don't check with afsd
to find out whether they need to make RPCs to talk to afsd.
[15:48:07] <jhutz@jis.mit.edu/owl> "crash" is not the interesting thing here
[16:09:53] wiesand leaves the room
[16:10:24] <Jeffrey Altman> jhutz: I'm not sure that there is a concern for the in-tree processes.   I'm more concerned about out of tree processes that are linked against libsys and call setpag() or pioctl()
[16:17:59] wiesand joins the room
[16:24:57] wiesand leaves the room
[16:48:34] shadow joins the room
[18:06:22] meffie leaves the room
[18:34:08] meffie joins the room
[18:44:43] <jhutz@jis.mit.edu/owl> PAM modules could be an issue.
[18:46:32] <Jeffrey Altman> agreed
[20:41:43] jhutz@jis.mit.edu/owl leaves the room
[20:41:53] jhutz@jis.mit.edu/owl joins the room
[21:29:09] jhutz@jis.mit.edu/owl leaves the room
[21:30:59] jhutz@jis.mit.edu/owl joins the room
[21:31:11] jhutz@jis.mit.edu/owl leaves the room
[21:44:43] jhutz@jis.mit.edu/owl joins the room
[22:16:30] meffie leaves the room
[22:43:19] Jeffrey Altman leaves the room
[22:43:20] Jeffrey Altman joins the room