Re: FreeBSD Security Advisory FreeBSD-SA-08:05.openssh

2008-04-17 Thread Ian Smith
On Thu, 17 Apr 2008, FreeBSD Security Advisories wrote: IV. Workaround Disable support for IPv6 in the sshd(8) daemon by setting the option AddressFamily inet in /etc/ssh/sshd_config. Disable support for X11 forwarding in the sshd(8) daemon by setting the option X11Forwarding no

Re: FreeBSD Security Advisory FreeBSD-SA-08:05.openssh

2008-04-17 Thread mouss
Ian Smith wrote: On Thu, 17 Apr 2008, FreeBSD Security Advisories wrote: IV. Workaround Disable support for IPv6 in the sshd(8) daemon by setting the option AddressFamily inet in /etc/ssh/sshd_config. Disable support for X11 forwarding in the sshd(8) daemon by setting the

Re: FreeBSD Security Advisory FreeBSD-SA-08:05.openssh

2008-04-17 Thread Ian Smith
On Thu, 17 Apr 2008, Peter Pentchev wrote: On Thu, Apr 17, 2008 at 04:07:56PM +1000, Ian Smith wrote: On Thu, 17 Apr 2008, FreeBSD Security Advisories wrote: IV. Workaround Disable support for IPv6 in the sshd(8) daemon by setting the option AddressFamily inet in

Re: FreeBSD Security Advisory FreeBSD-SA-08:05.openssh

2008-04-17 Thread Matthew Seaman
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Ian Smith wrote: On Thu, 17 Apr 2008, Peter Pentchev wrote: On Thu, Apr 17, 2008 at 04:07:56PM +1000, Ian Smith wrote: On Thu, 17 Apr 2008, FreeBSD Security Advisories wrote: IV. Workaround Disable support for

openssldoesn't -overwrite-base again (was: FreeBSD-SA-08:05.openssh)

2008-04-17 Thread Roger Marquis
I'd like to thank the openssh-portable port maintainer/s for preserving the -overwrite-base option. This eases our systems and security update jobs measurably. Unfortunately, openSSL has dropped the -overwrite-base option (again), leaving us with two versions of openssl and some confusion over

Re: FreeBSD Security Advisory FreeBSD-SA-08:05.openssh

2008-04-17 Thread Dag-Erling Smørgrav
Matthew Seaman [EMAIL PROTECTED] writes: Hmmm... something that wasn't immediately clear to me reading the advisory: the requirement for an attacker to listen(2) on tcp port 6010 means that they have to have a login on the box being attacked. ie. it's a *local* information leak rather than a