under Project control - where a
vulnerability affects multiple vendors, there is almost always general
agreement on a common announcement date. If the Project leaks information
about unannounced vulnerabilities, it will stop receiving advance
information about vulnerabilities - this definitely
fix in 10,4 kernel.
That code was re-written in r82122, retaining the use of arc4random() for
ISN initialisation. As a result, it's no longer possible to point at
specific code and say "that code fixes weak TCP ISNs".
--
Peter Jeremy
signature.asc
Description: PGP signature
22 so the
code no longer exists in that form. Please advise what problem you
believe still exists in FreeBSD 10.4.
--
Peter Jeremy
signature.asc
Description: PGP signature
rary virtual address. An attacker could import
code from another system so it's not possible to mitigate the vulnerability
by (eg) implementing bounds checking in a compiler.
--
Peter Jeremy
signature.asc
Description: PGP signature
n January 2014, so you have had 3½ years to resolve
the problem that your servers aren't compatible with 10.x.
>Not asking for new versions or new releases.. just patches applied for
>previous -STABLE trees
As has been stated, the FreeBSD project will patch the supported -STA
need for a SSHv1 client
creates a net/ssh1 port (ie not in the "security" category) that installs a
client (only) that supports SSHv1 only, and comes with a big red flashing
"DANGER: INSECURE, DO NOT USE UNLESS YOU KNOW WHAT YOU ARE DOING" warning.
--
Peter Jeremy
signature.asc
Description: PGP signature
ones were correct).
--
Peter Jeremy
signature.asc
Description: PGP signature
't in the r284295 cherry-pick.
--
Peter Jeremy
pgp2yPIu85W4Q.pgp
Description: PGP signature
pd(8) has provision for specifying a leapsecond file which presumably
makes it leap-second aware. I haven't looked into the details.
There's also posix2time(3) to convert between a TAI-based time_t and a
POSIX-based time_t.
--
Peter Jeremy
pgpHbANjcdE5S.pgp
Description: PGP signature
On 2015-Jun-24 07:21:28 +1000, Peter Jeremy wrote:
>The closest is the LEAPSECONDS option: If LEAPSECONDS is defined at build
>time, /usr/src/contrib/tzdata/leapseconds is baked into the individual
>timezone files (to be) installed into /usr/share/zoneinfo.
It seems that the tzdata fil
On 2015-Jun-23 22:00:49 +0100, Pawel Biernacki
wrote:
>On 23 June 2015 at 21:56, Peter Jeremy wrote:
>
>> On 2015-Jun-23 20:03:35 +0100, Pawel Biernacki
>> wrote:
>> >As we (hopefully) all know on 30th of June we'll observe leap second.
>> > tzdata in
on with update to share/zoneinfo/leap-seconds.list file.
None of my FreeBSD systems have a share/zoneinfo/leap-seconds.list file.
Why should the Project issue an EN for a non-existent file?
--
Peter Jeremy
pgpJJchdxWJlN.pgp
Description: PGP signature
pyc files at package install time. As far as I can see, this is what
Ubuntu and Debian (the two Linux distros I have ready access to) do.
>(Would slow down builds of dependent packages, but those are the
>breaks.)
It would be interesting to know how big an impact this is.
--
Peter Jeremy
pgpOFZRKGD3uH.pgp
Description: PGP signature
ned by a recognised CA. The hashes of the
>certificate keys are on the mirror website I pointed out in my email
The certificates are self-signed. Whilst the hashes are published on
the FreeBSD website, that site is only available via HTTP so there's
still a bootstrap issue - which I don't have a general solution for.
--
Peter Jeremy
pgpNni5WnFFmA.pgp
Description: PGP signature
orm and will
typically run at >>100MHz. In order to reproduce the state, you
need to feed the same input in with sub-microsecond timing.
And this all occurs well before user logins are allowed. If you have
an attacker that can tightly control what happens during early system
startup, you have more serious problems than the amount of entropy in
/dev/random.
--
Peter Jeremy
pgpY5da166SDY.pgp
Description: PGP signature
On 2012-Sep-06 02:09:34 +0100, RW wrote:
>On Thu, 6 Sep 2012 07:27:34 +1000
>Peter Jeremy wrote:
>> Is it worth splitting harvestfifo into multiple queues to prevent
>> this? At least a separate queue for RANDOM_WRITE and potentially
>> separate queues for each entropy so
within the kernel) being discarded. There
would still be a small amount of entropy from the get_cyclecount()
calls but this is minimal.
Is it worth splitting harvestfifo into multiple queues to prevent
this? At least a separate queue for RANDOM_WRITE and potentially
separate queues for eac
it does so in a predictable
way so it doesn't add any entropy.
On the downside, it doesn't appear to be possible to queue more than
4KB of input every 100msec - excess input is just discarded. This
implies that feeding boilerplate into /dev/random just increases the
probability that r
e to get a round
>'tuit.)
You might like to look at kern/134225 (which is misfiled, sorry).
--
Peter Jeremy
pgp9XYONOHZxL.pgp
Description: PGP signature
des provision for displaying information prior to login - see
the "Banner" option in sshd_config. Note that this is most definitely
the wrong place to include system version details.
--
Peter Jeremy
pgpFqMq1LTlO2.pgp
Description: PGP signature
y team. Thanks for your efforts during
2011 and I hope you have a quiet and uneventful holiday period and 2012.
--
Peter Jeremy
pgpvKbjvy3cxc.pgp
Description: PGP signature
th them.
> FWIW, it should use rtld_printf() instead of printf(),
>but this is moot point.
Accepted.
On 2011-Dec-19 21:02:49 +0100, Clément Lecigne wrote:
>Dont know but the ld_printerror != '\0' in the patch should be
>*ld_printerror != '\0', no?
Oops, my mistake. Yes
root
cert and distribute that with FreeBSD. That certificate would at
least have the same trust level as FreeBSD.
--
Peter Jeremy
pgp6JsnJdHcJo.pgp
Description: PGP signature
memorise the lowest N and response.
--
Peter Jeremy
pgpzftFfptj93.pgp
Description: PGP signature
Alternatively, you could follow the reference links and determine
whether the particular vulnerabilities apply to your particular
situation. This obviously requires a greater level of skill and
reviewing if the situation changes.
--
Peter Jeremy
pgpAoAdrgOz4B.pgp
Description: PGP signature
s and is not recommended for new applications. This
is why FreeBSD has moved to using a combination of MD5 and SHA256.
Also, your website mentions DSA is unsafe. Could you please provide
a reference for this claim as I am unaware of any results suggesting
that DSA is less secure than RSA.
--
Peter Jeremy
pgpxfWXP1FEFO.pgp
Description: PGP signature
G, NextG etc) to communicate with your systems.
Note that using very large sequence numbers should slow down an
attacker (though only linerarly) since they still need to iterate
MD5 by that many rounds.
--
Peter Jeremy
pgpO5m4qUmf47.pgp
Description: PGP signature
to
>change the md5-algorithm by default towards sha1 as recommended after
>the md5-collisions has been published?
Note that both MD5 and SHA1 are broken in the cryprographic sense. As
various people have noted, the known breaks do not impact on MD5
password hashes.
--
Peter Jeremy
Please
o generate random challenges using opiechallenge
No. The seed has to match the seed that was used to generate the
hash with opiepasswd.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed beh
t to copy the
remaining files. In particular, you should merge your local changes
to /etc/ssh/ssh{,d}_config because just copying those files across
is quite likely to give the newer ssh a degree of indigestion.
--
Peter Jeremy
pgpStG3V5YukL.pgp
Description: PGP signature
upported" version of the software.
The FreeBSD SO has advised that 5.x will receive security updates
until 31 May 2008. This gives you 15 months to either migrate to
6.x (or 7.x) or arrange alternative security support.
--
Peter Jeremy
pgpkJeH4Igp4V.pgp
Description: PGP signature
ug's suggestion that
not MFCing bind 9.3.4 to RELENG_5 is an incentive to upgrade to 6.x).
--
Peter Jeremy
pgp59Aryg16r5.pgp
Description: PGP signature
user has new mail but you aren't running biff. To stop it, add
the following lines to your sendmail.mc file, rebuild sendmail.cf and
restart sendmail:
dnl Disable biff notification
define(`LOCAL_MAILER_ARGS', `mail.local -Bl')
--
Peter Jeremy
pgpzGx8OtFw34.pgp
Description: PGP signature
atisfy a pagein request.
FreeBSD tries to reduce the effective overhead of page zeroing by
zeroing them in the idle loop and keeping a cache of pre-zeroed pages
for handing out to processes.
--
Peter Jeremy
pgpQP35QW4vB2.pgp
Description: PGP signature
On Tue, 2006-May-23 08:53:00 -0700, Roger Marquis wrote:
>Peter Jeremy wrote:
>>One of the major problems with unattended/automatic updating is
>>that it is hard to filter them.
Actually, I didn't.
--
Peter Jeremy
___
freebsd-
ate process needs to balance
the benefits of reducing the number of unpatched boxes against the
risks of the update system being subverted.
--
Peter Jeremy
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
on that?
I've gone through the CAcert assurance process and it seems to work,
though a lot depends on your access to other assurers. Note that the
CAcert certificates are now part of ports/security/ca-roots though the
issue of bootstrapping remains (how do you know that your roots file
is gen
On Sun, 2006-Jan-29 12:10:34 +0100, Christian Baer wrote:
>On Sun, 29 Jan 2006 13:29:43 +1100 Peter Jeremy wrote:
>I am reading up on the basics of this subject. However, the theory
>doesn't really cover too much of the practical sides like the real
>differences between approaches
omputer without setting off the
alarm. You might find it easier to protect the master keys with a
(volatile) passphrase and rely on adequate protection of the
passphrase. (You might also consider looking up "secret sharing"
"threshold system").
>After considering this, am I b
since the
>attacker controls too much, or you can say the probability is high
>enough that you got a copy of the original repository.
This is non-trivial because the repository is not static and CVS
doesn't store transaction logs that would allow you to reproduce the
r
On Wed, 2005-Nov-30 14:38:11 -0500, Kris Kennaway wrote:
>On Thu, Dec 01, 2005 at 04:58:36AM +1100, Peter Jeremy wrote:
>
>> Note that the only ports-related file that can't be moved out of the
>> ports tree is 'INDEX'.
>
>Set INDEXFILE.
INDEXFILE always app
org security:
If you don't trust the FreeBSD Project you wouldn't run FreeBSD.
> Without ssh access there's no way to insert a key into the CVS
>repository.
Assuming no security holes in the infrastructure... How can I tell
that my private copy of the FreeBSD Pro
roam
>around in /etc.
And, hence, require root privileges.
>BTW, those scripts fail (of course), if /tmp is mounted with the noexec
>option.
I think the solution to this is to set PKG_TMPDIR somewhere else.
--
Peter Jeremy
___
freebsd-secur
is
closer to the X.509 model. The base system already includes tools for
handling X.509 signatures (openssl) and there is already a collection
of X.509 keys embedded in the ports system (security/ca-roots).
--
Peter Jeremy
___
freebsd-security@freebsd.org m
ment from the mailing list
archive
(http://lists.freebsd.org/pipermail/freebsd-announce/2005-November/001023.html).
Whilst the signature was still intact, the content has been changed
so the signature no longer verifies. (The changes are presumably
mechanical changes as part of its conversion from
te obtaining a X.509 certificate for the FreeBSD Project
- Signing ISO images with a Project key and/or certificate in addition
to providing MD5 checksums.
- Investigate providing authenticated protocols for updating FreeBSD.
--
Peter Jeremy
pgpjIjOjnnn1g.pgp
Description: PGP signature
on it as your only security. But, IMHO, it is
worth doing in addition to other security measures.
--
Peter Jeremy
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tions of them.
I strongly recommend that you disable reusable passwords on any system
exposed to the Internet - RSA/DSA or OPIE are much harder to brute force.
You can also use AllowUsers to further limit exposure.
--
Peter Jeremy
___
freebsd-security@fr
1).
We can probably leverage off the work that NetBSD has done in this
area. This would significantly simplify the work involved in supporting
the various architectures.
--
Peter Jeremy
___
freebsd-security@freebsd.org mailing list
http://lists.
through the documentation and can't find any reference to a
runtime OpenSSL configuration file that would let me do this.
--
Peter Jeremy
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To un
On Wed, 2005-Oct-12 00:12:35 -0700, Arne Wörner wrote:
>Btw: Why should the string "OpenSSL" be contained in each and
>every executable, that might use OpenSSL?
OpenSSL has a version string of the form "OpenSSL 0.9.7e 25 Oct 2004"
embedde
; long-term-supported. I'm sure one of the two will, as one of the two will
>> reflcet ultimately the walk-of-life of 5-STABLE, won't it?
>
>Why don't we just skip 6 and name it "FreeBSD X" or "FreeBSD 10" ?
Why not just merge XFree86 (or X.
ile~ Fri Mar 11 14:09:20 2005
+++ MakefileSun Mar 13 09:56:42 2005
@@ -1,5 +1,5 @@
-.PATH: /usr/src/sys/crypto/
-CFLAGS+= -I/usr/src/sys/crypto
+.PATH: ${.CURDIR}/../../crypto
+CFLAGS+= -I${.CURDIR} -I${.CURDIR}/../../crypto
KMOD= mac_chkexec
SRCS= vnode_if.h \
server#
-
53 matches
Mail list logo
