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

[Carl Fredrik Hammar]

Hi,

On Sun, Jan 03, 2010 at 11:42:52AM +0100, olafBuddenhagen@gmx.net wrote:
> On Sat, Jan 02, 2010 at 12:11:38PM +0100, Carl Fredrik Hammar wrote:
> > 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:
> 
> > MIG does have a c_string type after all, which is used to define the
> > string_t type used in the Hurd.
> 
> I see. I just remembered that I was quite stumped to see string_t
> defined with a constant size; but I didn't remember that it actually is
> c_string of a constant size, not just a char array...

Same here.  :-)

> But if Mach actually knows C strings, are you sure the kernel doesn't
> actually perform the check for 0-termination itself in the IPC code?...

Yes, I attached gdb to a translator receiving an unterminated string
and the string was indeed unterminated on arrival.

Also, I don't think Mach's IPC knows about C strings, only MIG.

> (Otherwise, the implementations of kernel functions like device_open()
> would have to make sure strings are always terminated, too.)

It seems device_open() doesn't check for it, but fixing MIG would cover
this too.

> > > > 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 :-)
> 
> > 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 said more invasive. I didn't say more work. That's quite a different
> thing :-)

I still don't see how changing MIG is invasive...

Regards,
  Fredrik