Re: CVE Request: Any User Can Panic Kernel Through Sysctl on OpenBSD

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Any user can panic the kernel by using the sysctl call. If a
> user can manage to map a page at address zero, they may be able
> to gain kernel code execution and escalate privileges (OpenBSD fortunately prevents this by default).
>
> Description:
> When processing sysctl calls, OpenBSD dispatches through a number
> of intermediate helper functions. For example, if the first integer
> in the path is 10, sys_sysctl() will call through vfs_sysctl() for
> further processing. vfs_sysctl() performs a table lookup based on
> the second byte, and if the byte is 19, it selects the tmpfs_vfsops
> table and dispatches further processing through the vfs_sysctl method:
>
>     if (name[0] != VFS_GENERIC) {
>         for (vfsp = vfsconf; vfsp; vfsp = vfsp->vfc_next)
>             if (vfsp->vfc_typenum == name[0])
>                 break;
>
>         if (vfsp == NULL)
>             return (EOPNOTSUPP);
>
>         return ((*vfsp->vfc_vfsops->vfs_sysctl)(&name[1], namelen - 1,
>             oldp, oldlenp, newp, newlen, p));
>     }
>
> Unfortunately, the definition for tmpfs_vfsops leaves this method NULL:

> struct vfsops tmpfs_vfsops = {
>
>     NULL,               /* vfs_sysctl */

> Trying to read or write a sysctl path starting with (10,19) results
> in a NULL pointer access and a panic of
> "attempt to execute user address 0x0 in supervisor mode".
> Since any user can perform a sysctl read, this issue can be abused
> by any logged in user to panic the system.
>
> Fortunately, OpenBSD intentionally prevents users from attempting to map a page
> at the NULL address. If an attacker is able to get such a mapping,
> they may be able to cause the kernel to jump to code mapped at this
> address (if other security protections such as SMAP/SMEP aren't in place).
> This would allow an attacker to gain kernel code execution and
> escalate their privileges.
>
> Reproduction:
> Run the PoC sysctl_tmpfs_panic.c program. It will pccess
> the (10,19,0) sysctl path and trigger a panic of
> "attempt to execute user address 0x0 in supervisor mode".
> NCC Group was able to reproduce this issue on OpenBSD 5.9 release
> running amd64.
>
> Recommendation:
> Include a NULL-pointer check in vfs_sysctl() before dispatching to
> the vfs_sysctl method. Alternately, include a vfs_sysctl method
> in the tmpfs_vfsops table.
>
> Fixed: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/vfs_subr.c.diff?r1=1.248&r2=1.249
>        http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/tmpfs/tmpfs_vfsops.c.diff?r1=1.9&r2=1.10

>     int name[] = { 10, 19, 0 }; // vfs.tmpfs.0
>     char buf[16];
>     size_t sz = sizeof buf;
>     int x;
>
>     x = sysctl(name, 3, buf, &sz, 0, 0);

Use CVE-2016-6350.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
  http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJXl7ebAAoJEHb/MwWLVhi2RRUQAKkrnjJ8NqE2b7z29QMk+jdI
nM1jbtV5seUvzxvVkk83jHCE4icLl3rDH23QAc9zRuMsVH6uXnIx7Cx37xlk9a54
YwNjnVZk8zIior3yQOY5/JzXkr/AaK2Pb5SQVRyHiJRD9ApA97DvWxJGGWFhCxLc
M/S2BeiB15L05dC0wKEJFKx4OV4ScpB2uy/T+gORpqRkWHhI1h/xCYeG2wNTSGaI
DBQTvtR1MYwqz7jax1jFPyaUAW4Jg21qCP9L20Ds+G9Yw3DzVP+k3c06l2PMcuM+
zr9ajStH3NDSMkqYkfhYXFGDzUo5z8BFnRdJmAkFTcYQGJz2PkwNeRGw4put5/lB
sVzYCnP8SXM2LVjOYzwxI6LyNvtnK5HhqE7PD5hf81rNDQHqDb01g0l2EE1psyNs
/cSMhJzQL9ioZTbjTDtvpWpopZVeIt9BUWQGXFb7QviQpNcFPXsvT2A4wwimm3HE
dXlfMzARDBlkU/2qRfXJAfqtTM5MI5KlPLIREEwOjUMbwgnynENeHdLjob2EJLE7
7ofXZE+azTK03wx4e/3aJwWfy5Ff+lXXb50AJOutS74oRii8gSHywMIZLV+0k6nN
Klkk1UYBdgkBc6HW42yK/veQ/tEc1Vwm3edpD+WWlo1y3kju6vig5fB7jhpD+vQc
dfRSQioVwzON5g8m+tx+
=DboK
-----END PGP SIGNATURE-----