Hi,

In MD5Init(3) there's a paragraph that says:

"""MD5 has not yet (1999-02-11) been broken, but sufficient attacks
have been made that its security is in some doubt. The attacks on both
MD4 and MD5 are both in the nature of finding ``collisions'' - that is,
multiple inputs which hash to the same value; it is still unlikely for an
attacker to be able to determine the exact original input given a hash
value.
"""

Shouldn't it be updated or at least the date of the statement moved to
somewhere in this century?

Andrew Thompson wrote:

Shouldn't that be considered a security flaw? After all,
you can perform "ifconfig $IF" inside a jail to list the
interface configuration, but you're not allowed to make
any changes.

Given your description above, it means that it is possible
to modify the interface configuration (cause a failover)
from within a jail. That's not good. I think that needs
to be fixed, or at the very least it needs to be properly
documented.

In message neptune.sinister.com>, Bob Keyes
writes:

No, I'm not wondering the least, it was pretty obvious that you behaved
like a spurned primadonna type and now you were going to tell us how
much we were missing out because we did not cater to your every whim
and fancy.

And since you had nothing concrete to bargain with, all you could do
was say "Ha!, then you can't play with my dolls!" and go home with your
nose in the sky, hoping that we would feel really miserable.

Well, we don't.

The FreeBSD project has been attempted blackmailed many times over
the year, and it havn't worked yet, and it won't ever, if I can
prevent it.

In message neptune.sinister.com>, Bob Keyes
writes:

I can warmly recommend you read the book "Blackmailing for dummies",
as I can see that you make several classical beginner mistakes in
this attempt.

Better luck next time.

Poul-Henning

What's really sad is that bad attitudes from various OS security
organizations, such as some people at FreeBSD, has made some people less
willing to share vulnerabilities that they have discovered. I speak
specifically from my experience in the year 2000, regarding the NAPTHA
DoS. Mr. Robert Watson was quite uncivilized in his criticisms of me and
the disclosure, even though it had been handled in the most reasonable way
(through CERT).

You may not believe it, but I've known about this BIND problem for some
years, but kept it in my vest pocket. Why? Because I was tired of being
made to suffer for doing what was right.

I have an inkling about other problems which affect commonly used
open-source software, but I see no reason to do a thorough investigation
and disclose the results in a responsible way. Because of the bad
attitudes of a number of people in the security community, I've been very
quiet, not revealing any of my accidental discoveries nor pursuing fixes
for the problems I see.

Until reasonable and diplomatic people are installed as the security
contacts for organizations such as FreeBSD, I will only make patches
available to me and my close friends.

[...]

Julian Elishcher suggested:

I hesitate to call this a "bug" as I don't know all the history behind
the ipfw2 decisions, so let me toss this out there and see I'm just
missing something.

Overview
========

The negated operator, "not recv any" was taken to mean "any packet never
received by an interface" believed to be equivalent to "any packet that
originated on the current machine's interfaces"

My logic being:
* If "recv any" means "received by any interface"
* then "not recv any" means "not received by any interface" (which
should be locally-generated packets)

In practice, both "recv any" and "not recv any" appear to be "no-op"
phrases.

Application was to be able to discriminate between:

* Packets from the current host that are going out
(and need stateful rules of the form
my.outside.IP <==> some.rest.of.world.host)

In message <200807241639.m6OGda4b004216@apollo.backplane.com>, Matthew Dillon w
rites:

Yes they do.

Really smart programs modify the strings after the check and get
to access the files anyway.

Is anyone else nervous trusting all his programs to have access to all
his files? Is there already a reasonable solution to this problem?

It makes me nervous for, say, Firefox and its plugins to be able to
read and write every file I own, whether it's gnucash, ~/.ssh, or
other sensitive files.

Programs could be set up to run under their own uids, but this is
cumbersome, especially in a desktop environment.

One possibility would be to "filewall" off a program--say, Firefox--so
that of all my uid's files Firefox is only able to read or write
~/.mozilla. If we had app signatures like it seems OS X does, then
maybe a "filewall" MAC module could use extended attributes to grant
access to files based on the app's signature. Permission could be
granted to the application to access other files through a special
file picker, so the user is always in control.

Thoughts?

Matt

Hi folks,

I ran freebsd-update today hoping it would have picked
up the BIND upgrade. freebsd-update reported: