Re: two probable security holes

Sam Varshavchik (mrsam@courier-mta.com)
Tue, 25 Sep 2001 01:02:35 GMT


David S. Miller writes:

> From: Ken Ashcraft <kash@stanford.edu>
> Date: Tue, 18 Sep 2001 14:29:57 -0700 (PDT)
>
> Watch ifr.ifr_name.
>
> Hi Ken, I believe there is some bug in your new checker algorithms for
> this case.
>
> struct ifreq ifr;
> int err;
> Start--->
> if (copy_from_user(&ifr, (void *)arg, sizeof(ifr)))
> return -EFAULT;
> ifr.ifr_name[IFNAMSIZ-1] = '\0';
>
> ifreq copied safely to kernel space, ifr.ifr_name[] is inside the
> struct and NOT a user pointer.
>
> err = tun_set_iff(file, &ifr);
>
> Pass address of kernel ifreq.
>
> if (*ifr->ifr_name)
> name = ifr->ifr_name;
>
> if ((err = dev_alloc_name(&tun->dev, name)) < 0)
> goto failed;
>
> Perfectly fine still, name always points to kernel memory.
>
> int dev_alloc_name(struct net_device *dev, const char *name)
> {
> ...
>
> for (i = 0; i < 100; i++) {
> Error--->
> sprintf(buf,name,i);
>
> Still fine, as stated "name" is pointing to kernel memory.

Ummm... Is it possible for name to be, oh, something like

"foo%s%s%s%s%s"?

In that case, what would that sprintf do?

> Perhaps your code is being confused by "ifreq->if_name" being
> an array.

-- 
Sam 

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/