-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NetBSD Security Advisory 2008-011
=================================

Topic: ICMPv6 MLD query

Version: NetBSD-current: affected
NetBSD 4.0: affected
NetBSD 3.1.*: not affected
NetBSD 3.1: not affected
NetBSD 3.0.*: not affected
NetBSD 3.0: not affected

Severity: Denial of service

Fixed: NetBSD-current: August 22, 2008
NetBSD-4-0 branch: August 23, 2008
(4.0.1 will include the fix)
NetBSD-4 branch: August 23, 2008
(4.1 will include the fix)

Abstract
========

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Just to let everyone know there have been some further updates to BIND
in the NetBSD CVS trees in order to address performance issues with the
initial fixes to address CVE-2008-1447. All the updates have been
documented in NetBSD Security Advisory 2008-009 which is available at:

ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2008-009.txt.asc

On behalf of security-officer@NetBSD.org,

adrian.

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAki7EXIACgkQLc2rR0mnFJ+fuwCg+4E5igu7txRdVNLYPWH+3+Q1
CfoAoLUOIfPmKVJBV/hFX+vRm/OPBK4t
=4hRD

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NetBSD Security Advisory 2008-010
=================================

Topic: Malicious PPPoE discovery packet can overrun a kernel buffer

Version: NetBSD-current: affected
NetBSD 4.0: affected
NetBSD 3.1.*: affected
NetBSD 3.1 affected
NetBSD 3.0.*: affected
NetBSD 3.0: affected

Severity: Remote denial-of-service

Well, blow me down! I'm still using my old mk.conf. I haven't even noticed
there's MKPAM and USE_PAM. Lots of thanks for the tip, Greg!

On 19-Aug-08, at 12:23 AM, SODA Noriyuki wrote:

I think it's pretty fair. No consensus was reached on the contentious
points

I've never seen any real technical evaluation showing PAM to be more
secure.

Show me where the evaluation is.

http://summit.googlebong.com

Dolf Jasin GoogleBong

img { border: 2px solid Black }

pre { font: 6pt/8pt }

p,blockquote { font: 16pt; font-family: verdana, arial, 'sans serif' }

h1,h2,h3,h4,ul { font-family: verdana, arial, 'sans serif'; font: 14p }

table,li,td { font-family: verdana, arial, 'sans serif'; font: 12p }

ul { list-style: disc }

ol { list-style: decimal }

body { background: "#EEEEEE" }

h1,h2,h3,h4,hr,p,ul,blockquote,pre { color:Black }

a:link { color:Blue }

a:visited { color:Blue }

a:active { color:"#008000" }

a:hover { color:"#008000" }

h1.header { padding:0em; margin:0 }

div.container { width:100%%; margin:0px; border:1px solid Black; line-height:150%% }

div.header,div.footer { padding:0.5em; color:white; background-color:Black; clear:left }

div.left { width:15%%; margin:0; float:left; padding:0; }

It is done.

One actually cool byproduct which I'd hadn't thought of before (although
it is quite obvious) is the ability to mount suspicious file system
images using non-kernel code. I am suspecting it would be quite easy
to construct a file system image so that if mounted it would compromise
the host kernel.

As the usual usecase is being handed a usb stick with fat on it, I
converted rump_msdos to have the same syntax as mount_msdos by sharing
the option parsing code. It should be possible to use them entirely
interchangeably, except the former will of course only compromise the
integrity of the file server process.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NetBSD Security Advisory 2008-009
=================================

Topic: BIND cache poisoning

Version: NetBSD-current: affected
NetBSD 4.0: affected
NetBSD 3.1.*: affected
NetBSD 3.1: affected
NetBSD 3.0.*: affected
NetBSD 3.0: affected
bind 8.x packages
bind 9.4.x packages prior to 9.4.2pl1
bind 9.5.x packages prior to 9.5.0pl1

Severity: Remote DNS cache poisoning

When I checked the pam-pwauth_suid module for information
leaks I found that kernel buffers used for IPC keep
sensitive information for longer time too.
Most notably tty buffers, because raw tty devices
are used normally to enter passwords.
In this case, since tty input is processed character by
character anyway, it would not cost much to clear the
buffer out after the reader got the data.
Do you think this is OK?

This could be taken much further, but for sockets we have
encrypted protocols. Remain pipes... don't know whether
something should be done here. Would be easy in
the !PIPE_SOCKETPAIR case.

best regards
Matthias

-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich

Extra files that previously not there in the "NetBSD" source tree like the
PDF documentation (src/dist/bind/doc/arm/Bv9ARM.pdf but not in netbsd-3).

Well maybe I should start all over and do it the bind2netbsd way. Just to
clarify: Okay if I do the commits as I follow the steps (that say to
commit)?

And when did you do cvs update for the steps?

Can you double check the steps as outlined in the few scripts to add
missing steps?

Thanks