Nabble - freebsd-security

Re: rtld.patch -- effects on running system.

2009-12-01T05:14:57Z

Rudy Rucker <rudy@...> writes:
> Causes lots of things to freeze up or crash (example: apache /
> mysql).

That's... strange. I'm sure there is a good explanation, though.

I would just reboot the system after applying the patch.

> Now, how do I go about updating /libexec/ld-elf32.so.1 (I am on an
> amd64 box, FreeBSD 7.x)?

# make buildworld && make installworld && shutdown -r now new world

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Upcoming FreeBSD Security Advisory

2009-12-01T05:12:02Z

Alex Huth <a.huth@...> writes:
> I am new to patching systems, so forgive "stupid" questions. We have
> some 6.1 systems. Are or will there be a patch for them or are they
> not involved in this problem?

Support for 6.1 ended one and a half years ago (almost to the day), so
no to the first part of your question. As to the second: yes, 6.1 is
most likely affected.

There is a good chance (but no guarantee) that the patch for 6.3 will
apply cleanly on 6.1. The security advisory will contain instructions
on how to apply and deploy the patch.

> How do i apply such a patch? With freebsd-update? As far as i know is
> this tool only for systems >= 6.3 or?

freebsd-update will work on 6.3 since 6.3 is still supported (until the
end of January).

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Upcoming FreeBSD Security Advisory

2009-12-01T04:26:52Z

Jan Muenther napsal/wrote, On 12/01/09 12:53:
> I'd be greatly surprised if the affected code looked different in 6.x.

True, affected code is same. But unsetenv() "return" 'void' on 6.x, so
the code can't be patched the same way as in 7.x/8.x/HEAD

We need something like

if (getenv(...) != NULL ) {
unsetenv(...);
if (getenv(...) != NULL )
ABORT - BROKEN ENVIRONMENT
}

Dan

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Upcoming FreeBSD Security Advisory

2009-12-01T03:53:47Z

Hi,

> I am new to patching systems, so forgive "stupid" questions. We have some 6.1
> systems. Are or will there be a patch for them or are they not involved in
> this problem?
>
> I am new to patching systems, so forgive me any stupid questions. We have some
> 6.1 and 6.3 systems. Are or will there be patches fro them or are they not
> involved in this problem?
>
> How do i apply such a patch? With freebsd-update? As far as i know is this
> tool only for systems >= 6.3 or?
>

Patches are patches for the source code, so you'll have to apply them
with the patch(1) program and then re-compile.
I'd be greatly surprised if the affected code looked different in 6.x.

The bug itself is fairly interesting actually, if only for the reason
that it displays what can happen if you don't check return values -
other prime example of this causing security issues that I can think of
off the top of my head are Windows impersonation bugs.

stealth wrote this up:
http://xorl.wordpress.com/2009/12/01/freebsd-ld_preload-security-bypass/

Maybe that sheds some light.

Cheers,
Jan
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Upcoming FreeBSD Security Advisory

2009-12-01T03:16:27Z

* Eygene Ryabinkin schrieb:
> Colin, *, good day.
>
> Tue, Dec 01, 2009 at 01:20:45AM +0000, FreeBSD Security Officer wrote:
> > A short time ago a "local root" exploit was posted to the full-disclosure
> > mailing list; as the name suggests, this allows a local user to execute
> > arbitrary code as root.

I am new to patching systems, so forgive "stupid" questions. We have some 6.1
systems. Are or will there be a patch for them or are they not involved in
this problem?

I am new to patching systems, so forgive me any stupid questions. We have some
6.1 and 6.3 systems. Are or will there be patches fro them or are they not
involved in this problem?

How do i apply such a patch? With freebsd-update? As far as i know is this
tool only for systems >= 6.3 or?

Thx

Alex
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Upcoming FreeBSD Security Advisory

2009-12-01T01:01:08Z

yeah noexec /tmp is nice

cat /tmp/shellscript | bash

same with executables

It is good against level0 kiddies and bots

On Tue, Dec 1, 2009 at 4:28 AM, Bryan Drewery <bryan@...> wrote:

> Colin,
>
> Thank you so much for alerting us and providing a temporary patch. I had
> a user attempt to use the public exploit today, but due to /tmp being
> noexec, it failed. Luckily I caught him before he modified the script to
> work though. Now I am patched and can sleep tonight :)
>
> Thanks,
> Bryan
>
> FreeBSD Security Officer wrote:
> > Hi all,
> >
> > A short time ago a "local root" exploit was posted to the full-disclosure
> > mailing list; as the name suggests, this allows a local user to execute
> > arbitrary code as root.
> >
> > Normally it is the policy of the FreeBSD Security Team to not publicly
> > discuss security issues until an advisory is ready, but in this case
> > since exploit code is already widely available I want to make a patch
> > available ASAP. Due to the short timeline, it is possible that this
> > patch will not be the final version which is provided when an advisory
> > is sent out; it is even possible (although highly doubtful) that this
> > patch does not fully fix the issue or introduces new issues -- in short,
> > use at your own risk (even more than usual).
> >
> > The patch is at
> > http://people.freebsd.org/~cperciva/rtld.patch
> > and has SHA256 hash
> > ffcba0c20335dd83e9ac0d0e920faf5b4aedf366ee5a41f548b95027e3b770c1
> >
> > I expect a full security advisory concerning this issue will go out on
> > Wednesday December 2nd.
>
> _______________________________________________
> freebsd-security@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@...
> "
>

--
the sun shines for all

http://l1xl1x.blogspot.com
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Upcoming FreeBSD Security Advisory

2009-11-30T23:52:33Z

Colin, *, good day.

Tue, Dec 01, 2009 at 01:20:45AM +0000, FreeBSD Security Officer wrote:

> A short time ago a "local root" exploit was posted to the full-disclosure
> mailing list; as the name suggests, this allows a local user to execute
> arbitrary code as root.
>
> [...]
>
> The patch is at
> http://people.freebsd.org/~cperciva/rtld.patch
> and has SHA256 hash
> ffcba0c20335dd83e9ac0d0e920faf5b4aedf366ee5a41f548b95027e3b770c1

Just to ease other's life: for 7.1 (and 7.0, but it seems to be at EoL
now, so there is already no support for it), one should use another patch:
-----
http://codelabs.ru/fbsd/patches/vulns/freebsd-7.0-rtld-unsetenv.diff

SHA256 (freebsd-7.0-rtld-unsetenv.diff) = e5ebbea24073bf644d3bc0c1ba37674a387af656b4c7e583a564a83598930897
SHA1 (freebsd-7.0-rtld-unsetenv.diff) = 24a79be52be0ea00ed0ea279f25efbf597f9c850
-----
Actually, every system that has rtld.c with r190323 or lower, should
use this variant -- clearing of LD_ELF_HINTS_PATH was introduced only
in r190324.

By the way, if people are using NO_DYNAMIC_ROOT and all setuid
executables come from the system itself (no sudo and other stuff from
ports or manual installations), such system is obviously safe from this
issue -- no dynamic loading takes place. I don't mean that people with
such systems shouldn't upgrade, but they probably can do it with a least
urgency.

Thanks for posting the patch!
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

rtld.patch -- effects on running system.

2009-11-30T22:49:17Z

Regarding patch here:
http://lists.freebsd.org/pipermail/freebsd-security/2009-December/005369.html

I am trying to patch running systems and find some interesting behavior...

This Process:

cd /usr/src/libexec/rtld-elf/
fetch http://people.freebsd.org/~cperciva/rtld.patch
patch < rtld.patch
make
make install
ls -l /libexec/ld-elf.so.1

Causes lots of things to freeze up or crash (example: apache / mysql).
Restarting those services gets them back online. :)
For example: /usr/local/etc/rc.d/mysql restart

Now, how do I go about updating /libexec/ld-elf32.so.1 (I am on an
amd64 box, FreeBSD 7.x)?

Rudy

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Upcoming FreeBSD Security Advisory

2009-11-30T21:21:51Z

At 06:20 PM 11/30/2009, FreeBSD Security Officer wrote:

>A short time ago a "local root" exploit was posted to the full-disclosure
>mailing list; as the name suggests, this allows a local user to execute
>arbitrary code as root.

Yargh. Thank you for catching this.

--Brett

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Upcoming FreeBSD Security Advisory

2009-11-30T20:28:58Z

Colin,

Thank you so much for alerting us and providing a temporary patch. I had
a user attempt to use the public exploit today, but due to /tmp being
noexec, it failed. Luckily I caught him before he modified the script to
work though. Now I am patched and can sleep tonight :)

Thanks,
Bryan

FreeBSD Security Officer wrote:

> Hi all,
>
> A short time ago a "local root" exploit was posted to the full-disclosure
> mailing list; as the name suggests, this allows a local user to execute
> arbitrary code as root.
>
> Normally it is the policy of the FreeBSD Security Team to not publicly
> discuss security issues until an advisory is ready, but in this case
> since exploit code is already widely available I want to make a patch
> available ASAP. Due to the short timeline, it is possible that this
> patch will not be the final version which is provided when an advisory
> is sent out; it is even possible (although highly doubtful) that this
> patch does not fully fix the issue or introduces new issues -- in short,
> use at your own risk (even more than usual).
>
> The patch is at
> http://people.freebsd.org/~cperciva/rtld.patch
> and has SHA256 hash
> ffcba0c20335dd83e9ac0d0e920faf5b4aedf366ee5a41f548b95027e3b770c1
>
> I expect a full security advisory concerning this issue will go out on
> Wednesday December 2nd.

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Upcoming FreeBSD Security Advisory

2009-11-30T17:20:45Z

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

Hi all,

A short time ago a "local root" exploit was posted to the full-disclosure
mailing list; as the name suggests, this allows a local user to execute
arbitrary code as root.

Normally it is the policy of the FreeBSD Security Team to not publicly
discuss security issues until an advisory is ready, but in this case
since exploit code is already widely available I want to make a patch
available ASAP. Due to the short timeline, it is possible that this
patch will not be the final version which is provided when an advisory
is sent out; it is even possible (although highly doubtful) that this
patch does not fully fix the issue or introduces new issues -- in short,
use at your own risk (even more than usual).

The patch is at
http://people.freebsd.org/~cperciva/rtld.patch
and has SHA256 hash
ffcba0c20335dd83e9ac0d0e920faf5b4aedf366ee5a41f548b95027e3b770c1

I expect a full security advisory concerning this issue will go out on
Wednesday December 2nd.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAksUbjcACgkQFdaIBMps37LP9ACgljaYCfgVuhD2gd9Natpq4H/9
i48An1mgl+Mih+AWN7J9KZ1rsiEU31IZ
=MPXj
-----END PGP SIGNATURE-----

--
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

HEADS UP: removal of PECOFF support in RELENG_[67]

2009-11-22T14:05:48Z

Hi,

I'd like to give you a heads up that I intend to also remove PECOFF
support from the stable/7 and stable/6 branches. PECOFF support is
non-working and unmaintained in those FreeBSD releases and has lately
still seen public security problems.

PECOFF support is already gone in the upcoming 8.0 RELEASE or the
9-CURRENT development branch.

Should no valid complaints come up saying that someone needs (and
actively uses *cough* PECOFF support on FreeBSD it'll be removed
earliest Novemeber 29th 2009 00:00 UTC (in about one week).

/bz

--
Bjoern A. Zeeb It will not break if you know what you are doing.
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Openssl TLS Reneg "Bug"

2009-11-19T07:19:34Z

Tue, Nov 17, 2009 at 12:47:14PM +0100, Daniel wrote:
> new here so sorry if I am missing any important points. I was
> wondering#: Does anyone know of the status of the "amended" openssl
> packages for FreeBSD. I'd like to try running our site with "reneg
> off", but I can't seem to find any notion of this on freebsd sites ?
> Any ideas, pointers ?

OpenSSL port was updated to 0.9.8l:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/openssl/Makefile?rev=1.158;content-type=text%2Fx-cvsweb-markup

OpenSSL in the base system wasn't patched, according to the
svn.frebsd.org.
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Openssl TLS Reneg "Bug"

2009-11-17T23:18:55Z

Daniel wrote:
> Dear List,
> new here so sorry if I am missing any important points. I was
> wondering#: Does anyone know of the status of the "amended" openssl
> packages for FreeBSD. I'd like to try running our site with "reneg
> off", but I can't seem to find any notion of this on freebsd sites ?
> Any ideas, pointers ?

The only way of doing that at present is to use openssl-0.9.8l which
has simply had the renegotiation stuff diked out of it. That's available
as the security/openssl port, but be aware that you will have to
rebuild any SSL-aware application to link against the shlibs it
installs.

The fix in 0.9.8l is an interim measure which cripples certain openssl
functionality: installing it may cause websites to malfunction, so make
sure you have good backups and have thought about how you can back the
change out if needed.

openssl-0.9.8m will provide the corrected renegotiation mechanisms as
described in

https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

However, 0.9.8m has not yet been released. I'd assume that this will
probably be the subject of a FreeBSD Security Advisory once the fixes
are available, and that supported FreeBSD branches will be updated to
0.9.8m or otherwise patched to the same effect in the base system.

Cheers,

Matthew

--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW

signature.asc (267 bytes) Download Attachment

Openssl TLS Reneg "Bug"

2009-11-17T03:47:14Z

Dear List,
new here so sorry if I am missing any important points. I was
wondering#: Does anyone know of the status of the "amended" openssl
packages for FreeBSD. I'd like to try running our site with "reneg
off", but I can't seem to find any notion of this on freebsd sites ?
Any ideas, pointers ?
Best
Daniel
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley

2009-11-11T23:45:16Z

On Wed, 11 Nov 2009, Eygene Ryabinkin wrote:

> Date: Wed, 11 Nov 2009 22:37:44 +0300
> From: Eygene Ryabinkin <rea-fbsd@...>
> To: Damian Weber <dweber@...>
> Cc: Bjoern A. Zeeb <bzeeb-lists@...>,
> freebsd-security@..., wkoszek@...,
> Oliver Pinter <oliver.pntr@...>
> Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of
> Service Exploit 23 R D Shaun Colley
>
> Wed, Nov 11, 2009 at 07:14:48PM +0100, Damian Weber wrote:
> > FWIW, I got another result on 6.4-STABLE
> >
> > FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3 13:06:12 CEST 2009 root@...:/usr/obj/usr/src/sys/MYMACHINE i386
> >
> > $ ./pecoff
> > MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa????aaaa
> > [I'm truncating here, ~3500 a's follow]aaaaa: File name too long
>
> You have no pecoff module loaded or compiled-in to the kernel,
> aren't you? Your "File name too long" is spitted by the shell,
> so it was not handled by the PE loader at all.

Confirmed. The code crashes the 6.4-stable machine when pecoff module
is loaded.

Wojciech A. Koszek wrote:
> I think the best way would be to remove PECOFF from 6.x and 7.x.
Now, I'm inclined to think that, too ;-)

-- Damian

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley

2009-11-11T15:07:27Z

On Wed, Nov 11, 2009 at 05:37:50PM +0000, Bjoern A. Zeeb wrote:

> On Mon, 20 Jul 2009, Oliver Pinter wrote:
>
> Hi,
>
>> http://milw0rm.com/exploits/9206
>
> has anyone actually been able to reproduce a problem scenario with
> this on any supported releases (7.x or 6.x)?
>
> The only thing I gould get from that was:
> execve returned -1, errno=8: Exec format error
>
> Similar results applied to the scenario from
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/80742
> which had been filed for a 5.x system by Wojciech A. Koszek long
> before the above.
>

Hello,

This report has been lying in the PR database for a long time. I removed
PECOFF from CURRENT some time ago, since absolutely noone was able to give
any sensible argument for keeping PECOFF handler.

Because PECOFF has been introduced years before I became a commiter, I wasn't
sure if MFC is a good idea back then. The reason I didn't perform MFC to
stable releases after "newer" report is our merge policy. I simply haven't yet
studied it.

We can consider PECOFF bug as having "security implications", but in order to
make it "active", someone has to study NOTES and enable this option. For the
first glance I see that ports/ situation didn't change -- we seem to have 0
ports requiring PECOFF to be present.

And I can't right now confirm whether the bug is still there -- I have no 6.x
and 7.x systems for testing anymore.

If you want to try my code out (available in the PR), compile PECOFF -- I remember
that I provided some sample case to panic the kernel.

I think the best way would be to remove PECOFF from 6.x and 7.x.

Thanks for CCing me.

--
Wojciech A. Koszek
wkoszek@...
http://FreeBSD.czest.pl/~wkoszek/
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley

2009-11-11T11:37:44Z

Wed, Nov 11, 2009 at 07:14:48PM +0100, Damian Weber wrote:
> FWIW, I got another result on 6.4-STABLE
>
> FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3 13:06:12 CEST 2009 root@...:/usr/obj/usr/src/sys/MYMACHINE i386
>
> $ ./pecoff
> MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa????aaaa
> [I'm truncating here, ~3500 a's follow]aaaaa: File name too long

You have no pecoff module loaded or compiled-in to the kernel,
aren't you? Your "File name too long" is spitted by the shell,
so it was not handled by the PE loader at all.
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley

2009-11-11T11:22:11Z

On Wed, 11 Nov 2009, Bjoern A. Zeeb wrote:

> Date: Wed, 11 Nov 2009 18:59:24 +0000 (UTC)
> From: Bjoern A. Zeeb <bzeeb-lists@...>
> To: Damian Weber <dweber@...>
> Cc: freebsd-security@..., wkoszek@...,
> Oliver Pinter <oliver.pntr@...>
> Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of
> Service Exploit 23 R D Shaun Colley
>
> On Wed, 11 Nov 2009, Damian Weber wrote:
>
> >
> >
> > On Wed, 11 Nov 2009, Bjoern A. Zeeb wrote:
> >
> > > Date: Wed, 11 Nov 2009 17:37:50 +0000 (UTC)
> > > From: Bjoern A. Zeeb <bzeeb-lists@...>
> > > To: Oliver Pinter <oliver.pntr@...>
> > > Cc: freebsd-security@..., wkoszek@...
> > > Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of
> > > Service Exploit 23 R D Shaun Colley
> > >
> > > On Mon, 20 Jul 2009, Oliver Pinter wrote:
> > >
> > > Hi,
> > >
> > > > http://milw0rm.com/exploits/9206
> > >
> > > has anyone actually been able to reproduce a problem scenario with
> > > this on any supported releases (7.x or 6.x)?
> > >
> > > The only thing I gould get from that was:
> > > execve returned -1, errno=8: Exec format error
> > >
> >
> > FWIW, I got another result on 6.4-STABLE
> >
> > FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3
> > 13:06:12 CEST 2009 root@...:/usr/obj/usr/src/sys/MYMACHINE
> > i386
> >
> > $ ./pecoff
> > MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaîîîîaaaa
> > [I'm truncating here, ~3500 a's follow]aaaaa: File name too long
>
>
> Not sure if you'd see it with ktrace or not; I ran into that with my
> tests as well and was told that it's a shell problem.
>
> try to run it from this:
> ------------------------------------------------------------------------
> #include <unistd.h>
> #include <err.h>
>
> int
> main(int argc, char *argv[])
> {
>
> if (execl("./pecoff", "./pecoff", NULL) == -1)
> err(1, "execl()");
>
> return (0);
> }
> ------------------------------------------------------------------------

execl() and /usr/local/bin/bash (bash-3.2.48_1) produce same result

ktrace/kdump show

...
2380 pecoff CALL open(0x8048764,0x1,0)
2380 pecoff NAMI "evilprog.exe"
2380 pecoff RET open 3
2380 pecoff CALL write(0x3,0xbfbfce80,0xfe0)
2380 pecoff GIO fd 3 wrote 4064 bytes
0x0000 4d5a 6161 6161 6161 6161 6161 6161 6161 6161 |MZaaaaaaaaaaaaaaaa|
0x0012 6161 6161 6161 6161 6161 6161 6161 6161 6161 |aaaaaaaaaaaaaaaaaa|
...

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley

2009-11-11T10:59:24Z

On Wed, 11 Nov 2009, Damian Weber wrote:

>
>
> On Wed, 11 Nov 2009, Bjoern A. Zeeb wrote:
>
>> Date: Wed, 11 Nov 2009 17:37:50 +0000 (UTC)
>> From: Bjoern A. Zeeb <bzeeb-lists@...>
>> To: Oliver Pinter <oliver.pntr@...>
>> Cc: freebsd-security@..., wkoszek@...
>> Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of
>> Service Exploit 23 R D Shaun Colley
>>
>> On Mon, 20 Jul 2009, Oliver Pinter wrote:
>>
>> Hi,
>>
>>> http://milw0rm.com/exploits/9206
>>
>> has anyone actually been able to reproduce a problem scenario with
>> this on any supported releases (7.x or 6.x)?
>>
>> The only thing I gould get from that was:
>> execve returned -1, errno=8: Exec format error
>>
>
> FWIW, I got another result on 6.4-STABLE
>
> FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3 13:06:12 CEST 2009 root@...:/usr/obj/usr/src/sys/MYMACHINE i386
>
> $ ./pecoff
> MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaîîîîaaaa
> [I'm truncating here, ~3500 a's follow]aaaaa: File name too long

Not sure if you'd see it with ktrace or not; I ran into that with my
tests as well and was told that it's a shell problem.

try to run it from this:
------------------------------------------------------------------------
#include <unistd.h>
#include <err.h>

int
main(int argc, char *argv[])
{

if (execl("./pecoff", "./pecoff", NULL) == -1)
err(1, "execl()");

return (0);
}
------------------------------------------------------------------------

/bz

--
Bjoern A. Zeeb It will not break if you know what you are doing.
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley

2009-11-11T10:14:48Z

On Wed, 11 Nov 2009, Bjoern A. Zeeb wrote:

> Date: Wed, 11 Nov 2009 17:37:50 +0000 (UTC)
> From: Bjoern A. Zeeb <bzeeb-lists@...>
> To: Oliver Pinter <oliver.pntr@...>
> Cc: freebsd-security@..., wkoszek@...
> Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of
> Service Exploit 23 R D Shaun Colley
>
> On Mon, 20 Jul 2009, Oliver Pinter wrote:
>
> Hi,
>
> > http://milw0rm.com/exploits/9206
>
> has anyone actually been able to reproduce a problem scenario with
> this on any supported releases (7.x or 6.x)?
>
> The only thing I gould get from that was:
> execve returned -1, errno=8: Exec format error
>

FWIW, I got another result on 6.4-STABLE

FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3 13:06:12 CEST 2009 root@...:/usr/obj/usr/src/sys/MYMACHINE i386

$ ./pecoff
MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaîîîîaaaa
[I'm truncating here, ~3500 a's follow]aaaaa: File name too long

-- Damian

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley

2009-11-11T09:37:50Z

On Mon, 20 Jul 2009, Oliver Pinter wrote:

Hi,

> http://milw0rm.com/exploits/9206

has anyone actually been able to reproduce a problem scenario with
this on any supported releases (7.x or 6.x)?

The only thing I gould get from that was:
execve returned -1, errno=8: Exec format error

Similar results applied to the scenario from
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/80742
which had been filed for a 5.x system by Wojciech A. Koszek long
before the above.

/bz

--
Bjoern A. Zeeb It will not break if you know what you are doing.
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[patch] OpenSSL in base: fix CVE-2009-3555

2009-11-07T05:43:47Z

>Submitter-Id: current-users
>Originator: Eygene Ryabinkin
>Organization: Code Labs
>Confidential: no
>Synopsis: [patch] OpenSSL in base: fix CVE-2009-3555
>Severity: critical
>Priority: high
>Category: bin
>Class: sw-bug
>Release: FreeBSD 8.0-BETA2 amd64
>Environment:

System: FreeBSD 8.0-BETA2 amd64

>Description:

See [1] (not much information just now) and [2].

>How-To-Repeat:

[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
[2] http://cvs.openssl.org/fileview?f=openssl-web/news/announce.txt&v=1.52

>Fix:

The following patch applies to OpenSSL both from HEAD and 8-STABLE.

It completely disables renegotiation inside TLS/SSL sessions and I had
verified that no renegotiations will take place with s_client and
s_server.

--- fix-cve-2009-3555.diff begins here ---
>From 01c641ca1a88d08fea282f79ff0f1a86d5319ba7 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin <rea-fbsd@...>
Date: Sat, 7 Nov 2009 15:45:32 +0300

Obtained-From: http://cvs.openssl.org/chngview?cn=18791
Obtained-From: http://cvs.openssl.org/chngview?cn=18794

Signed-off-by: Eygene Ryabinkin <rea-fbsd@...>
---
crypto/openssl/CHANGES | 9 +++++++++
crypto/openssl/ssl/s3_lib.c | 3 +++
crypto/openssl/ssl/s3_pkt.c | 4 +++-
crypto/openssl/ssl/s3_srvr.c | 8 ++++++++
crypto/openssl/ssl/ssl.h | 1 +
crypto/openssl/ssl/ssl3.h | 9 +++++----
crypto/openssl/ssl/ssl_err.c | 1 +
7 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/crypto/openssl/CHANGES b/crypto/openssl/CHANGES
index 04d332e..cd445c9 100644
--- a/crypto/openssl/CHANGES
+++ b/crypto/openssl/CHANGES
@@ -2,6 +2,15 @@
OpenSSL CHANGES
_______________

+ Changes between 0.9.8k and 0.9.8l [5 Nov 2009]
+
+ *) Disable renegotiation completely - this fixes a severe security
+ problem at the cost of breaking all renegotiation. Renegotiation
+ can be re-enabled by setting
+ OPENSSL_ENABLE_UNSAFE_LEGACY_SESSION_RENEGOTATION at
+ compile-time. This is really not recommended.
+ [Ben Laurie]
+
Changes between 0.9.8j and 0.9.8k [25 Mar 2009]

*) Don't set val to NULL when freeing up structures, it is freed up by
diff --git a/crypto/openssl/ssl/s3_lib.c b/crypto/openssl/ssl/s3_lib.c
index 8916a0b..5aa7bb2 100644
--- a/crypto/openssl/ssl/s3_lib.c
+++ b/crypto/openssl/ssl/s3_lib.c
@@ -2592,6 +2592,9 @@ int ssl3_renegotiate(SSL *s)
if (s->s3->flags & SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS)
return(0);

+ if (!(s->s3->flags & SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION))
+ return(0);
+
s->s3->renegotiate=1;
return(1);
}
diff --git a/crypto/openssl/ssl/s3_pkt.c b/crypto/openssl/ssl/s3_pkt.c
index 9476dcd..b98b840 100644
--- a/crypto/openssl/ssl/s3_pkt.c
+++ b/crypto/openssl/ssl/s3_pkt.c
@@ -985,6 +985,7 @@ start:

if (SSL_is_init_finished(s) &&
!(s->s3->flags & SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS) &&
+ (s->s3->flags & SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION) &&
!s->s3->renegotiate)
{
ssl3_renegotiate(s);
@@ -1117,7 +1118,8 @@ start:
if ((s->s3->handshake_fragment_len >= 4) && !s->in_handshake)
{
if (((s->state&SSL_ST_MASK) == SSL_ST_OK) &&
- !(s->s3->flags & SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS))
+ !(s->s3->flags & SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS) &&
+ (s->s3->flags & SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION))
{
#if 0 /* worked only because C operator preferences are not as expected (and
* because this is not really needed for clients except for detecting
diff --git a/crypto/openssl/ssl/s3_srvr.c b/crypto/openssl/ssl/s3_srvr.c
index 80b45eb..79f3706 100644
--- a/crypto/openssl/ssl/s3_srvr.c
+++ b/crypto/openssl/ssl/s3_srvr.c
@@ -718,6 +718,14 @@ int ssl3_get_client_hello(SSL *s)
#endif
STACK_OF(SSL_CIPHER) *ciphers=NULL;

+ if (s->new_session
+ && !(s->s3->flags&SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION))
+ {
+ al=SSL_AD_HANDSHAKE_FAILURE;
+ SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, ERR_R_INTERNAL_ERROR);
+ goto f_err;
+ }
+
/* We do this so that we will respond with our native type.
* If we are TLSv1 and we get SSLv3, we will respond with TLSv1,
* This down switching should be handled by a different method.
diff --git a/crypto/openssl/ssl/ssl.h b/crypto/openssl/ssl/ssl.h
index ff8a128..5ef11a3 100644
--- a/crypto/openssl/ssl/ssl.h
+++ b/crypto/openssl/ssl/ssl.h
@@ -1952,6 +1952,7 @@ void ERR_load_SSL_strings(void);
#define SSL_R_NO_PRIVATE_KEY_ASSIGNED 190
#define SSL_R_NO_PROTOCOLS_AVAILABLE 191
#define SSL_R_NO_PUBLICKEY 192
+#define SSL_R_NO_RENEGOTIATION 318
#define SSL_R_NO_SHARED_CIPHER 193
#define SSL_R_NO_VERIFY_CALLBACK 194
#define SSL_R_NULL_SSL_CTX 195
diff --git a/crypto/openssl/ssl/ssl3.h b/crypto/openssl/ssl/ssl3.h
index 4b1e2e9..a1a19cb 100644
--- a/crypto/openssl/ssl/ssl3.h
+++ b/crypto/openssl/ssl/ssl3.h
@@ -326,10 +326,11 @@ typedef struct ssl3_buffer_st
#define SSL3_CT_NUMBER 7

-#define SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS 0x0001
-#define SSL3_FLAGS_DELAY_CLIENT_FINISHED 0x0002
-#define SSL3_FLAGS_POP_BUFFER 0x0004
-#define TLS1_FLAGS_TLS_PADDING_BUG 0x0008
+#define SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS 0x0001
+#define SSL3_FLAGS_DELAY_CLIENT_FINISHED 0x0002
+#define SSL3_FLAGS_POP_BUFFER 0x0004
+#define TLS1_FLAGS_TLS_PADDING_BUG 0x0008
+#define SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION 0x0010

typedef struct ssl3_state_st
{
diff --git a/crypto/openssl/ssl/ssl_err.c b/crypto/openssl/ssl/ssl_err.c
index 24a994f..ce2a555 100644
--- a/crypto/openssl/ssl/ssl_err.c
+++ b/crypto/openssl/ssl/ssl_err.c
@@ -384,6 +384,7 @@ static ERR_STRING_DATA SSL_str_reasons[]=
{ERR_REASON(SSL_R_NO_PRIVATE_KEY_ASSIGNED),"no private key assigned"},
{ERR_REASON(SSL_R_NO_PROTOCOLS_AVAILABLE),"no protocols available"},
{ERR_REASON(SSL_R_NO_PUBLICKEY) ,"no publickey"},
+{ERR_REASON(SSL_R_NO_RENEGOTIATION) ,"no renegotiation"},
{ERR_REASON(SSL_R_NO_SHARED_CIPHER) ,"no shared cipher"},
{ERR_REASON(SSL_R_NO_VERIFY_CALLBACK) ,"no verify callback"},
{ERR_REASON(SSL_R_NULL_SSL_CTX) ,"null ssl ctx"},
--
1.6.3.1
--- fix-cve-2009-3555.diff ends here ---

It will be very good if __FreeBSD_version will be bumped after this
update, because there are some fixes for the ports that use OpenSSL,
but disable renegotiation by themselves. These fixes shouldn't be
applied when system OpenSSL will be updated (port was already
updated to 0.9.8k).
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: issue with outbound SA selection

2009-10-27T06:33:47Z

On Tue, 27 Oct 2009, Naveen BN wrote:

Hi,

let me copy & paste what I rpelied on bugs@ already.

> My Linux kernel version is 2.6.23.1-42.fc8

Unfortunately this is not a linux but a FreeBSD mailing list. If your
issue is with a FreeBSD kernel we can certainly help, if you are
running a linux kernel I'd try the linux-ipsec list, which no longer
seems to exist? A good fallback might be linux-net or linux-netdev or a
similar list. Good luck there.

/bz

--
Bjoern A. Zeeb It will not break if you know what you are doing.
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

issue with outbound SA selection

2009-10-27T03:59:06Z

Hi All,

I have a problem using SA with selectors based on <src IP>, <dest IP>
and <dst port> for outbound traffic.
I have written two out bound SA's for the same destination IP with
different destination port, but I am seeing
wrong SA has been selected for outbound traffic. My concern is why the
SA is not getting selected based on
ports mentioned security policy.

FYI..
content of file setkey.conf
/************************* start setkey.conf ************************/
flush;
spdflush;

add 172.16.8.36 172.16.8.38[*800]* esp 0x201 -m tunnel -E 3des-cbc
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831
-A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;

add 172.16.8.38[500] 172.16.8.36 esp 0x301 -m tunnel -E 3des-cbc
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df
-A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

add 172.16.8.36 172.16.8.38[*500] *esp 0x208 -m tunnel -E 3des-cbc
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831
-A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;

# Security policies
spdadd 172.16.8.36 172.16.8.38[*800]* esp -P out ipsec
esp/tunnel/172.16.8.36-172.16.8.38/require;

spdadd 172.16.8.38[*800] *172.16.8.36 esp -P in ipsec
esp/tunnel/172.16.8.38-172.16.8.36/require;
/************************* end setkey.conf ************************/

*When a packet is sent to dest port 800 , SA which is getting selected
is 0x208[spi]
with dstport 500 instead of 0x201[spi] **with dstport 800 instead**.*

Please provide the criteria for outboud SA selection, please guide me
regarding this issue .
My Linux kernel version is 2.6.23.1-42.fc8

Thanks and Regards
Naveen

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages

2009-10-24T11:28:45Z

Fri, May 01, 2009 at 10:42:21PM +0400, Eygene Ryabinkin wrote:

> Gentlemen, good day.
>
> Just a reminder about this PR -- it is already a bit old. But it is
> still viable and kicking on many machines of mine. I am seeing speedups
> from 10x to 26x comparing to the plain portaudit. Since VuXML database
> will only grow, this will be good to consider these patches and (likely)
> integrate them into main trees.
>
> Could someone, please, look at the patches? I had uploaded slightly
> modified patches to the old locations. Most of changes were cosmetic:
> whitespace and so on. No real code was changed.

Hmm, I am going to be a bit nasty this time -- the PR lies for 1.5 years
and no one really looked at it. Though, Simon and Martin promised to
do so. If you really don't want this patch to go in -- just say, I'll
try to rework it to suit the project's needs. But for me it is rediculous
that no one is really interested in speeding up the stuff: number of
installed ports and number of VuXML entries will only grow and the patch
provides great opportunity to keep things very fast for the vast amount
of time.

Sorry for a slightly harsh tone, but I am really disappointed with
the handling of this PR.
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

HEADS UP: FreeBSD 6.3 EoL coming soon

2009-10-18T05:36:26Z

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

Hi all,

On January 31st, FreeBSD 6.3 will reach its End of Life and will no longer be
supported by the FreeBSD Security Team. Users of this release are strongly
encouraged to upgrade to a newer release before that date -- more conservative
users will probably wish to upgrade to FreeBSD 6.4 or FreeBSD 7.1 (which are
both extended-support branches), while others will probably wish to upgrade to
FreeBSD 7.2 or the upcoming FreeBSD 8.0.

The freebsd-update(8) utility can be used to upgrade i386 and amd64 systems
from 6.3-RELEASE (or 6.3-RELEASE-pX for some X) to 6.4-RELEASE using binary
updates (i.e., without compiling from source) as described in the 6.4-RELEASE
announcement; given an adequate internet connection, this process usually takes
15 minutes or less.

The current supported branches and expected EoL dates are:

+---------------------------------------------------------------------+
| Branch | Release | Type | Release date | Estimated EoL |
|-----------+------------+--------+-----------------+-----------------|
|RELENG_6 |n/a |n/a |n/a |November 30, 2010|
|-----------+------------+--------+-----------------+-----------------|
|RELENG_6_3 |6.3-RELEASE |Extended|January 18, 2008 |January 31, 2010 |
|---------------------------------------------------------------------|
|RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010|
|---------------------------------------------------------------------|
|RELENG_7 |n/a |n/a |n/a |last release + 2y|
|-----------+------------+--------+-----------------+-----------------|
|RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 |
|-----------+------------+--------+-----------------+-----------------|
|RELENG_7_2 |7.2-RELEASE |Normal |May 4, 2009 |May 31, 2010 |
+---------------------------------------------------------------------+

When FreeBSD 8.0-RELEASE is released, it will receive "Normal" support, i.e., it
will be supported for at least 12 months.

- --
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkrbC8oACgkQFdaIBMps37KQOQCgmnXQGtI/hKlFCT+dKAXzGX90
gi4An0uC5y3SLNtrTxOvYD6HqpnrR99k
=fl+f
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: openssh concerns

2009-10-17T15:36:53Z

If this hasn't been mentioned already, disable password logins
in sshd_config and require RSA authentication only.

I do this on all hosts I administer that are internet accessible
and it allows me to confidently ignore all of the password
guessing attacks, resulting in peace of mind.

Darren

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

RE: FreeBSD equivalent to Sun crypto framework APIs (PKCS#11) (for hardware AES-CTR)

2009-10-15T19:26:41Z

> There are a number of hardware solutions for performing AES-CTR in
> hardware - for example the broadcom BCM5825, which is supported by
> the ubsec driver.
>
> The problem is that OpenSSL does not currently support hardware
> acceleration of AES-CTR. The solution on a Sun system is to use the
> Sun crypto framework APIs (PKCS#11) which does support AES-CTR in
> hardware.
>
> Is there an analagous API in FreeBSD that I could implement in my
> code so as to use the hardware AES-CTR of devices supported by ubsec ?

> Aside from crypto(3) (OpenSSL), there's also crypto(9) (kernel) and
> crypto(4) (userland), but they don't appear to support CTR - just CBC.

Understood.

How difficult or trivial would it be to add AES-CTR to either crypto(9) or
crypto(4) ?

Are those just derived from OpenSSL in some way anyway ? If not, who is
responsible for this kind of work ?
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: FreeBSD equivalent to Sun crypto framework APIs (PKCS#11) (for hardware AES-CTR)

2009-10-14T15:23:07Z

On Wed, 14 Oct 2009 18:02:36 +0000 (UTC)
John Case <case@...> wrote:

>
> There are a number of hardware solutions for performing AES-CTR in
> hardware - for example the broadcom BCM5825, which is supported by
> the ubsec driver.
>
> The problem is that OpenSSL does not currently support hardware
> acceleration of AES-CTR. The solution on a Sun system is to use the
> Sun crypto framework APIs (PKCS#11) which does support AES-CTR in
> hardware.
>
> Is there an analagous API in FreeBSD that I could implement in my
> code so as to use the hardware AES-CTR of devices supported by ubsec ?

Aside from crypto(3) (OpenSSL), there's also crypto(9) (kernel) and
crypto(4) (userland), but they don't appear to support CTR - just CBC.

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

FreeBSD equivalent to Sun crypto framework APIs (PKCS#11) (for hardware AES-CTR)

2009-10-14T11:02:36Z

There are a number of hardware solutions for performing AES-CTR in
hardware - for example the broadcom BCM5825, which is supported by the
ubsec driver.

The problem is that OpenSSL does not currently support hardware
acceleration of AES-CTR. The solution on a Sun system is to use the Sun
crypto framework APIs (PKCS#11) which does support AES-CTR in hardware.

Is there an analagous API in FreeBSD that I could implement in my code so
as to use the hardware AES-CTR of devices supported by ubsec ?

Or do I need to directly manipulate ubsec with my actual application in
order to do this ?
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: GPU crypto acceleration?

2009-10-09T23:36:43Z

On Oct 9, 2009, at 8:57 PM, remodeler wrote:

> I'm wondering if there's any core functionality or third-party
> utilities to
> off-load cryptographic processing to the GPU or audio chip, instead
> of using a
> hardware acceleration expansion card? This is on amd64 build.

Check out the Nvidia Tesla, although it probably will only work on
Windows and Linux.

What is your application, though?

--
http://www.noncombatant.org/
http://hemiolesque.blogspot.com/

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

GPU crypto acceleration?

2009-10-09T20:57:23Z

I'm wondering if there's any core functionality or third-party utilities to
off-load cryptographic processing to the GPU or audio chip, instead of using a
hardware acceleration expansion card? This is on amd64 build.

Thank you.
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: Update on protection against slowloris

2009-10-08T09:19:01Z

Martin Turgeon a écrit :

> Thomas Rasmussen a écrit :
>> Martin Turgeon wrote:
>>> Hi list!
>>>
>>> We tested mod_antiloris 0.4 and found it quite efficient, but before
>>> putting it in production, we would like to hear some feedback from
>>> freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is
>>> anyone using it? Do you have any other way to patch against
>>> Slowloris other than putting a proxy in front or using the HTTP
>>> accept filter?
>>>
>>> Thanks for your feedback,
>>>
>>> Martin
>>> _______________________________________________
>>> freebsd-security@... mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-security
>>> To unsubscribe, send any mail to
>>> "freebsd-security-unsubscribe@..."
>> Hello,
>>
>> I am using it succesfully although not under any serious load, same
>> Apache and FreeBSD versions. I found it easy (compared to the
>> alternatives) and efficient, and no I don't know of any other ways of
>> blocking the attack, short of using Varnish or similar. However,
>> accf_http doesn't help at all, since HTTP POST requests bypass the
>> filter. HTTP POST can be enabled by passing the -httpready switch to
>> Slowloris.
>>
>> Please report back with your findings, I've been wondering how it
>> would perform under load.
>>
>> Best of luck with it,
>>
>> Thomas Rasmussen
>>
> Hi everyone,
>
> We haven't put mod_antiloris in production yet, but I wrote this
> little shell script to protect us against distributed attack. It's
> running every minutes in crontab. It checks for any IP with more than
> 100 connections in FIN_WAIT_2 state and block those IP in PF.
>
> #!/bin/sh
>
> /usr/bin/netstat -nfinet | grep FIN_WAIT_2 > netstat.out
>
> /usr/local/sbin/expiretable -t 300 slowloris
>
> for ip in `awk '{print $5}' netstat.out | awk -F. '{print
> $1"."$2"."$3"."$4}' | sort | uniq` ; do
> if [ `grep -c $ip netstat.out` -gt 100 ] ; then
> pfctl -t slowloris -Ta $ip 2> /dev/null
> fi
> done
>
> Did anyone have any comments on the script itself or the method used
> to detect the attackers?
>
> Thanks for your input,
>
> Martin
>

Sorry for replying to my own post, but I have new informations to share.
We putted in production mod_antiloris and my script yesterday night. No
problem yet with the module but I got a few false positive with my
script. It seems that there are a few IP that got more than 100
simultaneous connections in FIN_WAIT_2 state. We noticed that a lot of
the FIN_WAIT_2 connections were related to a jail running Lighttpd
(immune to slowloris, which IP is 127.0.0.25) so I modified the initial
netstat so it looks like that:

/usr/bin/netstat -nfinet | grep -v 127.0.0.25 | grep FIN_WAIT_2 >
netstat.out

We didn't get any false positive since then but I'm wondering how a
client can have so many unclosed connections? To get in FIN_WAIT state,
it's the server that closed the connections but the client never closed
it's side of the connections. Does anyone have an idea how this can
happen? Is this because of a bad browser, a bad OS/TCP stack or
something else?

Thanks for taking the time to shed some light on this,

Martin
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

Re: openssh concerns

2009-10-06T14:08:56Z

<<On Tue, 6 Oct 2009 15:49:16 -0400, jhell <jhell@...> said:

> Don't forget about making good use of the following configuration
> turntables. You can enforce a default policy of deny by just saying that a
> user must be in the group of AllowGroups. This does enforce a little bit
> more of a administrative overhead but that's for your staff and policy to
> decide.

Indeed, for a personal server that only I ever log in to, one of the
first things that I do is add "AllowUsers wollman" to
/usr/local/etc/ssh/sshd_config. That's just a belt-and-suspenders
thing, though, to make sure that I don't fat-finger the password file
or something. I generally ignore the ssh "invalid user" complaints --
I have a modified version of /etc/periodic/security/800.loginfail that
filters them out -- because they're totally irrelevant and have no
impact on security. That allows me to pay attention to the (very
occasional) password failures on real user accounts.

-GAWollman
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."