William Robertson | 1 Sep 03:12 2005
Picon

plt security patch

Hey all,

As part of a paper some people from my research group are working on,  
we have developed a patch against OpenBSD that you might be  
interested in.  It is intended to prevent malicious writes to the PLT  
and GOT (i.e., PLT hijacking) by verifying that the source of the  
write is from the runtime loader, and otherwise terminates the  
process.  The basic idea is to mark the PLT and the runtime loader as  
they are loaded into memory, and during execution to intercept writes  
to the PLT in the page fault handler, since the PLT has been marked  
read-only.  Then, the instruction pointer is checked to have  
originated from within the runtime loader.

It's a work in progress, because it only prevents basic PLT hijacks,  
not more sophisticated attacks where the attacker would prepare the  
environment and then jump into the code in the runtime loader that  
would perform the overwrite on the attacker's behalf.  The next  
version of the patch will attempt to prevent this as well, and should  
be done in the near future.

In any case, the current patch against OpenBSD 3.7-STABLE on i386 as  
well as some more information on it is located at:

http://www.cs.ucsb.edu/~wkr/projects/pltsec/

I'd appreciate any feedback you guys might have.

--
William Robertson
Reliable Software Group, UC Santa Barbara
(Continue reading)

Toni Mueller | 1 Sep 10:34 2005
Picon

Re: tftp:bsd.rd RLX

Hello Rob,

On Fri, 10.06.2005 at 13:53:30 -0400, Rob Foster <rob.foster <at> gmail.com> wrote:
> pxeboot works, but when i try to load "boot tftp:bsd.rd" (which is in
> the tftp server's root) it stops.

> Intel(R) Boot Agent Version 4.0.17
> Copyright (C) 1997-2001, Intel Corporation
> 
> Intel Base-Code, PXE-2.0 (build 083)
> Copyright (C) 1997-2001, Intel Corporation

I assume that you have Intel NICs...

I don't know exactly what you are looking at, but I did have very
similar problems with some Intel NICs (then trying to boot Linux) where
it was suggested that the NICs are defective.

When booting from disk instead of the network, it said something like
"detected receiver lockup bug, enabling workaround" which I assume
applies only to some chipsets, but which made my boot attempts stop at
some 240 KB plus/minus a few if memory serves, at which point
apparently the card just locked up.

So, I suggest swapping cards and see if it helps. You also say that
some of your computers do boot using the same setup?

Best,
--Toni++

(Continue reading)

Eichert, Diana | 1 Sep 16:10 2005
Picon

Re: tftp:bsd.rd RLX

I just noticed your reply because of the RLX in the Subject line.
The RLX systems are blade servers, so there is no way to add or
remove hardware.  I didn't read the original post, nor can I
find it in the archives.

I'm running OpenBSD on several RLX blade servers and the initial
install was done via a PXE boot.

diana

-----Original Message-----
From: owner-tech <at> openbsd.org on behalf of Toni Mueller
Sent: Thu 9/1/2005 2:34 AM
To: tech <at> openbsd.org
Subject: Re: tftp:bsd.rd RLX

Hello Rob,

On Fri, 10.06.2005 at 13:53:30 -0400, Rob Foster <rob.foster <at> gmail.com>
wrote:
> pxeboot works, but when i try to load "boot tftp:bsd.rd" (which is in
> the tftp server's root) it stops.

> Intel(R) Boot Agent Version 4.0.17
> Copyright (C) 1997-2001, Intel Corporation
>
> Intel Base-Code, PXE-2.0 (build 083)
> Copyright (C) 1997-2001, Intel Corporation

I assume that you have Intel NICs...
(Continue reading)

Rod.. Whitworth | 4 Sep 13:51 2005

Thanks very much for the restraint

In case there is somebody thinking of being a kindly soul or just a
humourist and has so far resisted the temptation to hell those who are
here looking for some boot thing for the land of the Swiftian
characters, commonly known as yahoos, I'd like to encourage further
restraint to the point of totally failing to respond to their
entreaties.

Having now written the longest sentence so far this year, I'd better
explain for the benefit of puzzled newcomers.

In the past somebody unknown spread the vile lie that the place to find
 help for doing unutterable things to fellow yahoos was this list.

Every time someone here responds it adds to the archives so that mother
google can mislead them further

It sounds very tempting to play with them but it just increases the
noise-to-signal ratio in the longer term. Seeing that recent forays
here have been met by silence, I'd like to congratulate the residents
on their remarkable restraint and to encourage its longevity.

Thankyou fellow lurkers/writers-of-serious-answers/other-denizens of
the tech <at>  list.

I hope none of the words above are used as goosearch keys or I'll be
damned forever.

From the land "down under": Australia.
Do we look <umop apisdn> from up over?

(Continue reading)

Daniel Hartmeier | 4 Sep 16:24 2005

Re: Thanks very much for the restraint

On Sun, Sep 04, 2005 at 09:51:27PM +1000, Rod.. Whitworth wrote:

> Every time someone here responds it adds to the archives so that mother
> google can mislead them further

In this particular case, I don't believe ignoring the posts will make
them go away. The reason is simply that the first page of hits on

  http://groups.google.com/groups?q=yah%6fo+bo%6fter

all link to tech <at> . And those posts are several years old. They will not
go away just because new posts are ignored.

Instead, I suggest replacing that first page of hits with more
appropriate ones. Pick a newsgroup or mailing list indexed by google (one
with a ranking comparable to tech <at> , not some tiny little one), one where
those posts would be more on-topic. For instance

  http://groups.google.com/group/24hoursupport.helpdesk/about

This one is large, well-ranked on google, and shows up first in
alphabetical sorting, and arguably their charter even makes this
somewhat on-topic there.

Now, post a couple of articles through NNTP to that group, using those
key words. Either ask for help, reply to someone asking for help, or
post thank-you replies that you got helped. Make sure to always use the
key words, quote them, and get them quoted. Threads with replies get
ranked higher by google, properly reply to others and yourself.

(Continue reading)

Brad | 5 Sep 02:56 2005

bge(4) NIC diff

Please try out the following diff with any bge(4) NICs.
Let me know of any regressions. Please provide a dmesg to
me if you do try out the diff.

- Removes spl durring attach
- Use pci_mapreg_map()
- Ensure bge_attach() always cleans up properly upon failure

Index: if_bge.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.81
diff -u -p -r1.81 if_bge.c
--- if_bge.c	30 Aug 2005 03:18:30 -0000	1.81
+++ if_bge.c	30 Aug 2005 03:20:26 -0000
 <at>  <at>  -1722,45 +1720,43  <at>  <at>  bge_attach(parent, self, aux)
 	struct pci_attach_args	*pa = aux;
 	pci_chipset_tag_t	pc = pa->pa_pc;
 	const struct bge_revision *br;
+	pcireg_t		pm_ctl, memtype;
 	pci_intr_handle_t	ih;
 	const char		*intrstr = NULL;
-	bus_addr_t		iobase;
-	bus_size_t		iosize;
+	bus_size_t		size;
 	bus_dma_segment_t	seg;
-	int			s, rseg;
+	int			rseg;
 	u_int32_t		hwcfg = 0;
 	u_int32_t		mac_addr = 0;
(Continue reading)

Arthur Barrett | 5 Sep 05:26 2005

OpenCVS status?

Hi all,

I recently came across mention of the OpenCVS project which seems to be
related to OpenBSD in some way:
http://www.opencvs.org/

The project goals seem very similar to the CVSNT goals (which despite
its name runs fine on Linux/Unix and as far as I know BSD).  CVSNT is
free and is licensed under the GNU GPL.
http://www.cvsnt.org/wiki/
or
http://march-hare.com/cvspro/

CVSNT has already had five years of stable releases (since it branched
from CVS).

The only persons name I can find associated with the OpenCVS project is
Joris Vink.  Does anyone know how to get in touch with the people from
this project?

My primary interest is in determining if the CVSNT/OpenCVS project
effort can perhaps be consolidated.

Thanks,

Arthur Barrett

Arthur Barrett | 5 Sep 05:56 2005

Re: OpenCVS status?

Tobias / Chris,

You both more-or-less asked the same question:

> Is CVSNT willing to change its license to the BSD license?

Well the problem as Chris pointed out is that your current OpenCVS code
is also GPL.

With release 3.1 of CVSNT (which is over a year away) it may be possible
to re-license, and I'd be happy to discuss this with the right people on
both sides of the table.

However I imagine that short term the OpenCVS project will be just as
GPL as CVSNT, and so my first ports of call are effort and function.  

As for effort and function, this fits with the descirption of the
project goal on opencvs.org/goals.html:
* Stay as compatible as possible with GNU cvs without compromising the
security of the system. 
* Be as secure as possible. Code carefully, do strict validity checks
especially in the network input path, and use bounded buffer operations.
Use privilege separation to mitigate the effects of possible security
bugs. 
* Provide a much better access control on repository files.

Without getting into a lot of detail - CVSNT achieved this about a year
ago (or earlier), and we are now onto "phase 2" of adding useful
features.

(Continue reading)

Theo de Raadt | 5 Sep 06:16 2005
Picon

Re: OpenCVS status?

> You both more-or-less asked the same question:
> 
> > Is CVSNT willing to change its license to the BSD license?
> 
> Well the problem as Chris pointed out is that your current OpenCVS code
> is also GPL.

It is highly highly unfortunate that you are so misinformed.  I don't
see how there is way anyone could cooperate with people who don't do
research.  Like, come on.

/*      $OpenBSD: add.c,v 1.27 2005/07/30 00:01:50 joris Exp $  */
/*
 * Copyright (c) 2004 Jean-Francois Brousseau <jfb <at> openbsd.org>
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. The name of the author may not be used to endorse or promote products
 *    derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
 * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
 * THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLUDING, BUT NOT LIMITED TO,
(Continue reading)

Arthur Barrett | 5 Sep 06:19 2005

Re: OpenCVS status?

> amd64:147> pwd
> /usr/src/usr.bin/cvs
> amd64:148> grep -i GPL *

Ahh.. Ok.  A quick glance looked sufficiently like the CVS structure and
I saw what I thought were some imports from the GNU CVS that I leapt to
an incorrect conclusion on the license.

> That's nice -- saying that you are doing the same as what OpenCVS is
doing.  

From what I can see OpenCVS project began about a year ago, CVSNT about
7 years ago, but I could be wrong on that score too.  Regardless I am
assuming that neither team has known of each other and my primary
interest is as I stated earlier - to find out the status and if there
would be benefit to both projects combining effort.  

I'm not sure if the people who have e-mailed me are actually involved in
the OpenCVS effort or not, however the off-list reaction seems to be
that the primary interest of the OpenCVS project is in re-licensing.  In
this case perhaps there wont be a lot of synergy between the projects.

If someone from the project does feel that there may be some synergy,
please contact me either on the list or off.

Thanks everyone for their responses.

Regards,

Arthur
(Continue reading)


Gmane