Hi, On Sat, Jan 02, 2010 at 08:12:17AM +0100, olafbuddenha...@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, olafbuddenha...@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
