headers
NetBSD Security Officer | 2 Feb 2010 20:04
Picon

Updated: NetBSD Security Advisory 2010-001: File system module autoloading Denial of Service attack


		 NetBSD Security Advisory 2010-001
		 =================================

Topic:		File system module autoloading Denial of Service attack

Version:	NetBSD-current:		affected prior to 2009-12-19 20:28:27 UTC
		NetBSD 5.0.1:		not affected
		NetBSD 5.0:		not affected
		NetBSD 4.0.*:		not affected
		NetBSD 4.0:		not affected

Severity:	Local Denial of Service

Fixed:		NetBSD-current:		Dec 19, 2009

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 coding error in the NetBSD VFS code allows a local attacker to
crash the local system by passing a soon-to-be-unmapped pointer
as a file system name to the mount system call.

Technical Details
=================

When entering the mount_get_vfsops() function, the string "fstype",
(Continue reading)

Permalink | Reply | 0 comments |
headers
NetBSD Security Officer | 2 Feb 2010 20:04
Picon

Updated: NetBSD Security Advisory 2010-002: OpenSSL TLS renegotiation man in the middle vulnerability


		 NetBSD Security Advisory 2010-002
		 =================================

Topic:		OpenSSL TLS renegotiation man in the middle vulnerability

Version:	NetBSD-current:		affected prior to 2009-12-04
		NetBSD 5.0:		affected
		NetBSD 4.0.*:		affected
		NetBSD 4.0:		affected
		pkgsrc:			openssl package prior to 0.9.8l

Severity:	Information disclosure

Fixed:		NetBSD-current:		Dec 03, 2009
		NetBSD-5-0 branch:	Jan 12, 2010
		NetBSD-5 branch:	Jan 12, 2010
		NetBSD-4-0 branch:	Jan 12, 2010
		NetBSD-4 branch:	Jan 12, 2010
		pkgsrc 2009Q4:		openssl-0.9.8l 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
========

An error in the OpenSSL TLS session renegotiation allows a remote
attacker to intercept communication and conduct a Man-in-the-Middle
attack on TLS sessions.
(Continue reading)

Permalink | Reply | 16 comments |
headers
NetBSD Security Officer | 3 Feb 2010 14:02
Picon

NetBSD Security Advisory 2010-003: azalia(4)/hdaudio(4) negative mixer index panic


		 NetBSD Security Advisory 2010-003
		 =================================

Topic:		azalia(4)/hdaudio(4) negative mixer index panic

Version:	NetBSD-current:		affected prior to 2010-01-21
		NetBSD 5.0.*:		affected
		NetBSD 5.0:		affected
		NetBSD 4.0.*:		affected
		NetBSD 4.0:		affected

Severity:	Local system crash

Fixed:		NetBSD-current:		Jan 21, 2010
		NetBSD-5-0 branch:	Jan 22, 2010
		NetBSD-5 branch:	Jan 22, 2010
		NetBSD-4-0 branch:	Jan 22, 2010
		NetBSD-4 branch:	Jan 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
========

A signedness issue in the azalia(4) and hdaudio(4) drivers allows a
local attacker to cause a kernel panic.

Technical Details
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Holland | 15 Feb 2010 21:44
Picon

less's .lesshst misfeature

With the last update to less it (and more along with it) grew a
misfeature where it saves all the patterns you search for within files
to ~/.lesshst for future retrieval.

This is a security/privacy hazard; search strings are expected to be
transient and process-private, and writing them to disk creates the
potential for unwanted disclosures. Writing them to a network-mounted
home directory, meanwhile, can disclose everything the user is doing
to anyone who happens to be listening; this is highly undesirable.

This misfeature can only be disabled by setting an environment
variable, which is a poor method of configuration under the best of
circumstances and fails rather drastically for e.g. running
single-user.

I already patched the code a while back so that attempting to defeat
the feature by e.g. linking /root/.lesshst -> /dev/null no longer
trashes the system.

However, it's been suggested, and several people have concurred, that
it ought to be disabled by default. This is easy to do.

The cost of disabling it by default, however, is that the behavior
diverges from upstream. Are we willing to buy into this? I think we
should, at least for more if not for less.

--

-- 
David A. Holland
dholland <at> netbsd.org
(Continue reading)

Permalink | Reply | 11 comments |
headers
Taylor R Campbell | 15 Feb 2010 22:09
Favicon

Re: less's .lesshst misfeature

I was disappointed to discover the feature a couple of years ago, and
have always disabled it since then.  I am but a mere user of NetBSD,
but in case my opinion counts for anything, I should be happy to see
it disabled by default (and even happier to see it disabled upstream).

(I am not subscribed to these lists, so please cc me in replies.)
Permalink | Reply | 0 comments |
headers
Jan Schaumann | 16 Feb 2010 03:39
Favicon
Gravatar

Re: less's .lesshst misfeature

David Holland <dholland <at> netbsd.org> wrote:

> I already patched the code a while back so that attempting to defeat
> the feature by e.g. linking /root/.lesshst -> /dev/null no longer
> trashes the system.

This, btw, was one of the more obscure bugs I've encountered.  Figuring
out why /dev/null had mode 0700 (or similar) and the various things that
broke was so bizarre that when I found out it was related to the version
of less, I immediately declared that one of my favorite software bugs of
all times.

> However, it's been suggested, and several people have concurred, that
> it ought to be disabled by default. This is easy to do.
> 
> The cost of disabling it by default, however, is that the behavior
> diverges from upstream. Are we willing to buy into this? I think we
> should, at least for more if not for less.

I'd say: Disable it for both and raise the issue with upstream.

Thanks!

-Jan
Permalink | Reply | 0 comments |
headers
Marc Balmer | 16 Feb 2010 12:46
Picon
Favicon

Re: less's .lesshst misfeature

Am 15.02.10 21:44, schrieb David Holland:
> With the last update to less it (and more along with it) grew a
> misfeature where it saves all the patterns you search for within files
> to ~/.lesshst for future retrieval.
> 
> This is a security/privacy hazard; search strings are expected to be
> transient and process-private, and writing them to disk creates the
> potential for unwanted disclosures. Writing them to a network-mounted
> home directory, meanwhile, can disclose everything the user is doing
> to anyone who happens to be listening; this is highly undesirable.
> 
> This misfeature can only be disabled by setting an environment
> variable, which is a poor method of configuration under the best of
> circumstances and fails rather drastically for e.g. running
> single-user.
> 
> I already patched the code a while back so that attempting to defeat
> the feature by e.g. linking /root/.lesshst -> /dev/null no longer
> trashes the system.
> 
> However, it's been suggested, and several people have concurred, that
> it ought to be disabled by default. This is easy to do.
> 
> The cost of disabling it by default, however, is that the behavior
> diverges from upstream. Are we willing to buy into this? I think we
> should, at least for more if not for less.

I am all for your proposal.  Disable it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Goyette | 16 Feb 2010 19:26

Re: less's .lesshst misfeature

On Tue, 16 Feb 2010, Constantine A. Murenin wrote:

> I like my tcsh's searchable history, but for less and more, — I agree,
> it better be disabled.

I have to agree here.  Esppecially since tsch at least gives you a 
'history -c' command to clear the history (no remembering the name of 
the .file).

-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Greg Troxel | 26 Feb 2010 17:47
Picon

password change logging


NetBSD doesn't currently log successful password changes or unsuccessful
attempts to change passwords.  Sometimes IT rules require this, and it
seems to be of general interest when running a tight ship.  Password
changes are rare, so this is hardly log noise compared to every ssh
connection and login.

Richard Hansen (also of BBN) wrote the following patch.  I've compiled
it on netbsd-5 on several arches and tested on i386.  It applied to
current cleanly and built find for amd64.

I'd like to commit this.  Any objections or encouragement?

Index: usr.bin/passwd/local_passwd.c
===================================================================
RCS file: /cvsroot/src/usr.bin/passwd/local_passwd.c,v
retrieving revision 1.33
diff -u -p -r1.33 local_passwd.c
--- usr.bin/passwd/local_passwd.c	17 Apr 2009 20:25:08 -0000	1.33
+++ usr.bin/passwd/local_passwd.c	26 Feb 2010 16:41:04 -0000
 <at>  <at>  -53,6 +53,7  <at>  <at>  __RCSID("$NetBSD: local_passwd.c,v 1.33 
 #include <unistd.h>
 #include <util.h>
 #include <login_cap.h>
+#include <syslog.h>

 #include "extern.h"

 <at>  <at>  -72,6 +73,10  <at>  <at>  getnewpasswd(struct passwd *pw, int min_
 	    strcmp(crypt(getpass("Old password:"), pw->pw_passwd),
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christos Zoulas | 26 Feb 2010 17:54

Re: password change logging

In article <rmiaauw54he.fsf <at> fnord.ir.bbn.com>,
Greg Troxel  <gdt <at> ir.bbn.com> wrote:
>-=-=-=-=-=-
>
>
>NetBSD doesn't currently log successful password changes or unsuccessful
>attempts to change passwords.  Sometimes IT rules require this, and it
>seems to be of general interest when running a tight ship.  Password
>changes are rare, so this is hardly log noise compared to every ssh
>connection and login.
>
>Richard Hansen (also of BBN) wrote the following patch.  I've compiled
>it on netbsd-5 on several arches and tested on i386.  It applied to
>current cleanly and built find for amd64.
>
>I'd like to commit this.  Any objections or encouragement?

I like this a lot!

christos
Permalink | Reply | 0 comments |

Gmane