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

[Carl Fredrik Hammar]

Hi,

On Sat, Jan 02, 2010 at 08:12:17AM +0100, olafBuddenhagen@gmx.net wrote:
> 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?

I was talking about the code generated for clients that copies a string
argument into messages to be sent to the client.  Sorry, I wrote this
in a bit of a hurry only using observations I had already made.

MIG does have a c_string type after all, which is used to define the
string_t type used in the Hurd.  Which explains how it can generate code
specific to strings.

> > 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...

I haven't looked yet, but I can't imagine it being less invasive than
adding checks in *every* single program that receives strings in messages.
I didn't consider it before but this would also affect clients that gets
strings in the reply.

Regards,
  Fredrik