[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #28446] No checks are made for unteminated strings in RPC messa

From: olafBuddenhagen
Subject: Re: [bug #28446] No checks are made for unteminated strings in RPC messages
Date: Sat, 2 Jan 2010 08:12:17 +0100
User-agent: Mutt/1.5.19 (2009-01-05)


On Fri, Jan 01, 2010 at 10:36:35PM +0100, Carl Fredrik Hammar wrote:
> On Thu, Dec 31, 2009 at 04:12:21AM +0100, olafBuddenhagen@gmx.net wrote:
> > On Wed, Dec 30, 2009 at 07:42:21PM +0000, Carl Fredrik Hammar wrote:

> > > Strings in RPCs, such as the filename argument to a dir_lookup, are
> > > not checked if they are terminated by '\0'.  This could lead to the
> > > server segfaulting if it tries to read the string.
> > > 
> > > Making MIG check that strings are terminated seems like the proper
> > > fix.
> > 
> > AIUI, the first step would be implementing actual string support in MiG
> > at all...
> MIG seems to already have some awareness of strings, atleast the client
> part uses a variant of strncpy() to copy the string into the message.

Could you please elaborate what code you are referring to exactly?

> It is hard to be certain that a translator isn't vounerable unless it
> has an explicit check, which I expect no translator currently have.
> For instance, I extfs returns ENAMETOOLONG because it I tested with a
> single component path, but it might be possible to get it to read past
> the end using many components, e.g. `././././....', though I suspect
> this will return ELOOP.
> Fixing MIG seems much easier and safer.

Yes -- but also more invasive... You'll have to find someone confident
enough to ack/commit the change :-)

If the change doesn't get commited for whatever reason, it would still
be nice to have (non-disputable) patches for the actual bugs...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]