headers
Piotr Meyer | 5 Apr 2010 22:14
Picon
Gravatar

NetBSD 5.x security

I made some research and I found following issues on NetBSD 5.x / i386
in features described in security(8):

1. ASLR

   a) Bug described in: 
      http://mail-index.netbsd.org/netbsd-bugs/2009/08/12/msg012786.html
      still exists and made ASLR unusable (random crashes, frequently
      in applications linked with '-ltph').

   b) System built witch MKPIE doesn't work at all, init still panics,
      as described in:
      http://mail-index.netbsd.org/port-i386/2009/05/01/msg001339.html

   - I tested botch cases. Yes, this doesn't work.

2. SSP (Stack Smashing Protection) is disabled by default:
   http://mail-index.netbsd.org/current-users/2009/11/12/msg011206.html

   (Interesting: looks like FreeBSD 8 has stack protection enabled by 
    default: http://www.freebsd.org/releases/8.0R/relnotes.html)

3. CVE-2009-2793 problem, described in:
   http://seclists.org/fulldisclosure/2009/Sep/221 was fixed in Jan 2010
   but still isn't backported to stable branch, so any local user can
   cause panic on "stable" NetBSD 5.x installation (I test it). Is any
   backport planned?

Did I miss something? I'm curious to know, how looks current TODO for 
security in NetBSD: will be these issues fixed, or - maybe - some features
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christos Zoulas | 5 Apr 2010 23:58

Re: NetBSD 5.x security

In article <20100405201404.GB19056 <at> drozd.smutek.pl>,
Piotr Meyer  <aniou <at> smutek.pl> wrote:
>I made some research and I found following issues on NetBSD 5.x / i386
>in features described in security(8):
>
>1. ASLR
>
>   a) Bug described in: 
>      http://mail-index.netbsd.org/netbsd-bugs/2009/08/12/msg012786.html
>      still exists and made ASLR unusable (random crashes, frequently
>      in applications linked with '-ltph').

This has to do with stack size; you can reduce the number of random
bits via sysctl if you want to use large stack sizes, or disable ASLR
on the binary. The bug report is still open, and we'll fix it properly
but this is a work-around.

>
>   b) System built witch MKPIE doesn't work at all, init still panics,
>      as described in:
>      http://mail-index.netbsd.org/port-i386/2009/05/01/msg001339.html
>
>   - I tested botch cases. Yes, this doesn't work.

I think it is missing /lib/libgcc_s.so too. This has been fixed in current.
I think you can either compile init without PIE or copy the library there.

>2. SSP (Stack Smashing Protection) is disabled by default:
>   http://mail-index.netbsd.org/current-users/2009/11/12/msg011206.html
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alistair Crooks | 6 Apr 2010 15:55

SoC project suggestion

Hi folks,

Some people have asked me for more information about the Summer of
Code project to implement file system flags to scrub the data blocks
on files which have a flag associated with them.  The details are to
be found here:

	http://www.netbsd.org/contrib/soc-projects.html#fs_scrub_flags

To give a bit more information - this is not intended to be an
all-encompassing disk wipe/shred utility, or an implementation of
a utility to overwrite spared sectors.

Instead, I'm thinking of the number of times we delete a file, only to
have a nagging suspicion that ''rm -P'' should have been used.  By the
time the thought has formed, it is too late, and the data blocks
themselves are on the freelist.  The only way to overwrite the data
blocks would be to fill up all partitions on that disk to 100%, which
is not always a feasible course of action.

This project is meant to associate a system and user flag with a file
in userland, similar to the immutable flags we already have, and, on
the last unlink of the file, the data blocks would be overwritten. 
It would be useful to have for shadow password files and dbs (and
temporary entries), pgp and ssh keys, and other sensitive data that a
user may have - which is where the user flag comes in.  There are
various ways of doing this scrubbing, and part of this project is to
investigate this.

If you are interested in this project, which is useful without being
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thor Lancelot Simon | 6 Apr 2010 23:16
Picon
Favicon

alternate secmodel example?

Has anyone got an example of a secmodel other than the default 44bsd
model that I could look at?

--

-- 
Thor Lancelot Simon	                               tls <at> rek.tjls.com
  "All of my opinions are consistent, but I cannot present them all
   at once."	-Jean-Jacques Rousseau, On The Social Contract
Permalink | Reply | 0 comments |
headers
Jed Davis | 8 Apr 2010 19:08
Picon
Favicon
Gravatar

Re: SoC project suggestion

Alistair Crooks <agc <at> pkgsrc.org> writes:

> This project is meant to associate a system and user flag with a file
> in userland, similar to the immutable flags we already have, and, on
> the last unlink of the file, the data blocks would be overwritten. 
> It would be useful to have for shadow password files and dbs (and
> temporary entries), pgp and ssh keys, and other sensitive data that a
> user may have - which is where the user flag comes in.  There are
> various ways of doing this scrubbing, and part of this project is to
> investigate this.

One interesting thing is that this would -- in theory -- allow scrubbing
files on LFS, both on deletion and when blocks are relocated due to
either copy-on-write or the segment cleaner.  Because the cleaner, as I
understand it, already has to walk through the inode to determine if a
block is garbage, it can find out "for free" whether it should overwrite
the block before marking the segment clean.

LFS has bigger problems, of course, and this is likely out of scope for
a SoC project anyway, but it might be worth noting.

--

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))
Permalink | Reply | 0 comments |
headers
Piotr Meyer | 19 Apr 2010 13:30
Picon
Gravatar

Re: NetBSD 5.x security

On Mon, Apr 05, 2010 at 09:58:38PM +0000, Christos Zoulas wrote:

> >   b) System built witch MKPIE doesn't work at all, init still panics,

[...]

> I think it is missing /lib/libgcc_s.so too. This has been fixed in current.
> I think you can either compile init without PIE or copy the library there.

I try -current and, after some troubles ([1] i [2] - could developers looks
at this, please?), I got working system, even with Full RELRO [3]. :)

1 - http://mail-index.netbsd.org/current-users/2010/04/17/msg013128.html
2 - http://mail-index.netbsd.org/current-users/2010/04/18/msg013147.html
    http://mail-index.netbsd.org/current-users/2010/04/19/msg013156.html
3 - http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html

--

-- 
Piotr 'aniou' Meyer
Permalink | Reply | 1 comment |
headers
Christos Zoulas | 19 Apr 2010 15:03

Re: NetBSD 5.x security

On Apr 19,  1:30pm, aniou <at> smutek.pl (Piotr Meyer) wrote:
-- Subject: Re: NetBSD 5.x security

| On Mon, Apr 05, 2010 at 09:58:38PM +0000, Christos Zoulas wrote:
| 
| > >   b) System built witch MKPIE doesn't work at all, init still panics,
| 
| [...]
| 
| > I think it is missing /lib/libgcc_s.so too. This has been fixed in current.
| > I think you can either compile init without PIE or copy the library there.
| 
| I try -current and, after some troubles ([1] i [2] - could developers looks
| at this, please?), I got working system, even with Full RELRO [3]. :)
| 
| 
| 1 - http://mail-index.netbsd.org/current-users/2010/04/17/msg013128.html
| 2 - http://mail-index.netbsd.org/current-users/2010/04/18/msg013147.html
|     http://mail-index.netbsd.org/current-users/2010/04/19/msg013156.html
| 3 - http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html

I could not reproduce the problem [1],[2] on my systems. Is this for the
/rescue part of the build?

christos
Permalink | Reply | 0 comments |
headers
NetBSD Security Officer | 27 Apr 2010 00:14
Picon

NetBSD Security Advisory 2010-004: amd64 per-page No-execute (NX) bit disabled


		 NetBSD Security Advisory 2010-004
		 =================================

Topic:		amd64 per-page No-execute (NX) bit disabled

Version:	NetBSD-current:		affected prior to April 19, 2010
		NetBSD 5.0.*:		affected
		NetBSD 5.0:		affected
		NetBSD 4.0.*:		not affected
		NetBSD 4.0:		not affected

Severity:	Possible execution of arbitrary code without memory protection

Fixed:		NetBSD-current:		April 19, 2010
		NetBSD-5-0 branch:	April 22, 2010
		NetBSD-5 branch:	April 22, 2010

Please note that NetBSD releases prior to 4.0 are no longer supported.
It is recommended that all users upgrade to a supported release.

Abstract
========

An issue in the x86 CPU features detection code disables the use of the
per-page NX bit under amd64, making it impossible to mark certain pages
of memory as not being executable.

Technical Details
=================
(Continue reading)

Permalink | Reply | 0 comments |
headers
NetBSD Security Officer | 27 Apr 2010 00:15
Picon

NetBSD Security Advisory 2010-005: NTP server Denial of Service vulnerability


		 NetBSD Security Advisory 2010-005
		 =================================

Topic:		NTP server Denial of Service vulnerability

Version:	NetBSD-current:		affected prior to 2009-12-08
		NetBSD 5.0.2:		not affected
		NetBSD 5.0.1:		affected
		NetBSD 5.0:		affected
		NetBSD 4.0.*:		affected
		NetBSD 4.0:		affected
		pkgsrc:			ntp package prior to 4.2.4p8

Severity:	Remote Denial of Service

Fixed:		NetBSD-current:		Dec 8, 2009
		NetBSD-5-0 branch:	Dec 8, 2009
		NetBSD-5 branch:	Dec 8, 2009
		NetBSD-4-0 branch:	Dec 8, 2009
		NetBSD-4 branch:	Dec 8, 2009
		pkgsrc 2009Q4:		ntp-4.2.4p8 corrects this issue

Please note that NetBSD releases prior to 4.0 are no longer supported.
It is recommended that all users upgrade to a supported release.

Abstract
========

A programming error in the handling of NTP MODE_PRIVATE packets
(Continue reading)

Permalink | Reply | 0 comments |

Gmane