OpenBSD Journal

Patch 015: setitimer

Contributed by jose on from the patch--p0 dept.

Indigo writes:
"I'm sure everybody checks errata once a day or more, anyway there's a new patch from http://www.openbsd.org/errata.html . Quoting: 
# 015: SECURITY FIX: October 2, 2002
Incorrect argument checking in the setitimer(2) system call
may allow an attacker to write to kernel memory.
A source code ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.1/common/015_kerntime.patch exists which remedies the problem."
Looking at the patch, it looks like another bounds checking problem. Simple fix, directions in the patch.

(Comments are closed)

Comments

  1. By Aaron Campbell () aaron@monkey.org on http://www.monkey.org/~aaron

    This one is tricky. The old code:

    #define ITIMER_PROF 2

    int
    sys_setitimer(p, v, retval)
    struct proc *p;
    register void *v;
    register_t *retval;
    {
    register struct sys_setitimer_args /* {
    syscallarg(u_int) which;
    syscallarg(struct itimerval *) itv;
    syscallarg(struct itimerval *) oitv;
    } */ *uap = v;
    ...
    if (SCARG(uap, which) > ITIMER_PROF)
    return (EINVAL);
    ...
    p->p_stats->p_timer[SCARG(uap, which)] = aitv;
    ...

    The ITIMER_PROF bounds check looks fine, doesn't it? Since `which' is passed in as u_int, the syscall should return EINVAL if `which' is greater than 2.

    But the "syscallarg(u_int) which" declaration shown above is non-functional; it's commented out. The real argument structure is defined in syscallargs.h:

    struct sys_setitimer_args {
    syscallarg(int) which;
    syscallarg(const struct itimerval *) itv;
    syscallarg(struct itimerval *) oitv;
    };

    Here it is defined as int! Comment rot. So an attacker passes in which as a negative number and is able to overwrite kernel memory. Nifty.

  2. By Anonymous Coward () on

    Local compromise? Remote?

  3. By Anonymous Coward () on

    Sadly, I don't look at errata every day. But I do look at OpenBSD Journal daily, so thanks Indigo for notifying us of the patch.

  4. By Dom De Vitto () dom@devitto.com on mailto:dom@devitto.com

    I thought just about everything was compiled -Wall, which IIRC would warn on type mismatch..?

    Dom

  6. By RC () on

    I was reading the recently released document on Multics security... It was an interesting read.

    Their two big security benefits over modern systems were 1) a programming language that would not allow input without bounds, so there could not be unchecked input and 2) a processor with a positive incrimenting stack.

    While 2 would have to be done by processor designers, perhaps #1 could be added to GCC? Modify it so that it does not allow input without an explicit boundary. Or perhaps have GCC outmatically determine the length of a string, and modify the output to prevent over-sized input.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]