[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: Carl Fredrik Hammar
Subject: Re: [bug #28446] No checks are made for unteminated strings in RPC messages
Date: Sat, 2 Jan 2010 12:11:38 +0100
User-agent: Mutt/1.5.20 (2009-06-14)


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.


reply via email to

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