Not sure who to address this to, so hopefully someone more
knowledgeable about vuxml can explain what needs to be fixed here.
https://vuxml.freebsd.org/freebsd/094e4a5b-6511-11ed-8c5e-206a8a720317.html
gives incorrect "affected packages" for the main `krb5` package: it
claims that all versions < 1
< said:
> Trond Endrestøl wrote:
>>
>> #minute hourmdaymonth wdaywho command
>>
>> 52 4 1 * * rootcertbot renew --quiet
>> --pre-hook "service apache24 stop" --post-hook "service apache24 start"
>> 52 1 15 * * root
<
said:
> In message <2c3f9748-a17f-3778-9eaa-99087f33d...@freebsd.org>, Lev
> Serebryakov
> writes:
>> On 05.03.2019 22:55, Shawn Webb wrote:
>>
>> >> This came over my phone's news feed. Another example that Colin Perciv=
>> al was right when he wrote his paper on exploiting cache for fun and
< said:
> It's from 11.1-RELEASE-p1. I would hope that 11.1p1 is more correct than
> 10.4?
No, 11.1 predates 10.4.
-GAWollman
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, s
<
said:
> Hi,
>> On 8. Dec 2017, at 8:25 PM, FreeBSD Security Officer
>> wrote:
>>
>> +--+---+
>> |releng/11.1|11.1-RELEASE|n/a |July 26, 2017 |11.2-RELEASE + 3 months|
>> +---
< said:
> However, there is a definite advantage to having one signature for a
> huge number of MACs. Moreover, as I mention in the paper, the most
> feasible quantum-safe signature scheme at the present is SPHINCS, which
> has signatures about 40Kib in size. That's pretty terrible if you're
> s
< said:
> I'm open to committing patches to openssh-portable to support it that
> people send via PR or email. I just have no means to test it or
> motivation to maintain the GSS patch myself.
In all honesty, I'd really just like the official package builds to
include at least *an* openssh packa
I'm thinking right about now that it would be really nice if we could
go back to having a security/openssh-gssapi port that was completely
independent of security/openssh-portable so that it didn't break for
months on end after a new upstream release. Is there anyone else here
who cares about this
< said:
> Well, it's definitely too late for 11, now.
> But, Debian is preparing to remove their heimdal package entirely,
> imminently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728
The primary issue, so far as I can see, is that Heimdal and MIT were
only compatible in the parts of t
<
said:
> We manage the two separate databases using the -V option to pw, and
> then have a script to merge the two databases into the standard
> local database.
Thanks for the clue; if I can convince Puppet not to use getpwnam(3)
et al then this looks like it will actually be the best option.
<
said:
> You want to add a futher layer of complications to the the already
> far too complicated user/group/authentication code in FreeBSD,
> just because you don't want to look at Puppets Ruby code ?
Um, no, that's not remotely what I wrote.
I've spent far more time than is useful looking at
Presently, we have a bunch of machines under configuration management
(using Puppet, but that's not really relevant here). I'm hoping to
implement LDAP via nsswitch on these machines, but I've run into an
issue: the standard getpw*(3) mechanisms can't tell the difference
between users or groups in
<
said:
> bsm/libbsm.h:#defineAU_USER_NAME_MAX50
That's fine, since it means that the user name in an audit record
(i.e., output data) is bigger than what FreeBSD needs.
> netsmb/smb.h:#define SMB_MAXUSERNAMELEN 128
Not sure that this matters for anything.
> sys/param.h:#define
< said:
> I maintain a local patch to preserve this functionality which was in
> portaudit but not in pkg audit. Perhaps not bullet proof, but simple
> enough to be sure it does what I want it to do.
I have an open bug against pkg that it doesn't have this feature.
Would you consider submittin
< said:
> ntpd(8) has provision for specifying a leapsecond file which presumably
> makes it leap-second aware. I haven't looked into the details.
The current NTP protocol, as implemented by ntpd, distributes
leap-second information if provided. This information may be provided
by higher-stratu
< said:
> I assume that you're using official packages and don't have a locally
> compiled Python interpreter or anything like that?
We build our own package repositories.
> Could you perhaps turn on auditing in order to find out what's touching
> these files?
Maybe. It will probably take a wh
< said:
> Garrett Wollman writes:
>> Checking for packages with mismatched checksums:
>> p5-XML-SAX-0.99_2: /usr/local/lib/perl5/site_perl/XML/SAX/ParserDetails.ini
> This file is updated whenever you install or remove a SAX parser, so
> this is expected. There a
On some of my machines, I've been noticing the following in the
nightly security mail:
Checking for packages with mismatched checksums:
p5-XML-SAX-0.99_2: /usr/local/lib/perl5/site_perl/XML/SAX/ParserDetails.ini
python27-2.7.9: /usr/local/lib/python2.7/UserDict.pyc
python27-2.7.9: /usr/local/lib/p
< said:
> On Wed, Dec 24, 2014 at 05:42:16PM +0100, Andrei wrote:
>> On Wed, 24 Dec 2014 00:33:09 +0100 (CET)
>> FreeBSD Security Advisories wrote:
>> > ports, namely tcp/123 and udp/123 when it is not clear that all
>> > systems have been patched or have ntpd(8) stopped.
>>
>> Why tcp/123?
>>
< said:
> I think there is a lot of value in providing a syscall interface which can
> be the default way for applications to retrieve random bits.
The OpenBSD guys have proposed a new posix__random() family of
interfaces ( being undecided as yet) to the Austin Group,
specifically for th
< said:
> [1] There is no such thing as a perfect CA bundle (i.e. both
> secure *and* usable) given how broken the whole CA system is
> these days.
So is anyone working on DANE support in libfetch and other base-system
utilities? Let's lead on this rather than just flaming about how CAs
< said:
> bsd.openssl.mk has the falling checks:
> if WITH_OPENSSL_BASE is set, then use the base system's OpenSSL.
> if WITH_OPENSSL_BASE or WITH_OPENSSL_PORT are not set, check if
> ${LOCALBASE}/lib/libcrypto.so is installed, if it is then use the
> OpenSSL port, otherwise use the base system's
<
said:
> I've always allowed frags, as per the example rulesets in rc.firewall.
> I only recall seeing them on DNS responses from zen.spamhaus.org, where
> I see plenty of these after a resetlog before the logging limit kicks
> in. I doubt I'd be getting rid of ~90% of incoming spam without
< said:
> I believe Gary was talking about changing the control/status port
> and not the actual service port (UDP 123). That should be doable
> without breaking compatibility with existing NTP tools.
NTP does not have a separate "control/status port"; all NTP operations
that could be called "con
< said:
> Other than updating ntpd, you can filter out requests to 'monlist' command
> with 'restrict ... noquery' option that disables some queries for
> the internal ntpd status, including 'monlist'.
For a "pure" client, I would suggest "restrict default ignore" ought
to be the norm. (Followed
< said:
> Why isn't this bug being fixed in 9.1?
Because it doesn't affect 9.1.
> Affects:FreeBSD 10.0-BETA
The advisory only affects systems where the OpenSSL library supports
AES-GCM. The one in 9.1 (OpenSSL 0.9.8y) does not.
-GAWollman
__
<
said:
> And as Garrett Wollman correctly pointed out on twitter: It remains
> yet to be seen if any implementation of SSL/TLS can be non-crap,
> given that they are stuck with X.509.
I should say, by the way, that X.509 is not an inherent requirement of
SSL/TLS, *but* it's
[Cc added, bdrewery@ who is the maintainer of security/openssh-portable]
< said:
> http://lists.freebsd.org/pipermail/svn-src-head/2013-May/047921.html
> Change the default in /etc/ssh/sshd_config to
No /etc/ssh here; this is ports openssh, not base (which doesn't exist
in my world).
> UsePriv
Am I the only person to be seeing this log message from sshd:
fatal: cipher_init: EVP_CipherInit: set key failed for aes128-cbc [preauth]
?
(security/openssh-portable, with HPN patches and MIT Kerberos,
although Kerberos is not actually configured on this server.) A
work-around is to disable ae
< said:
> pkgng will have a crypto-signing mechanism for packages with
> per-repository public keys and so forth. It's not there yet -- stuff is
> awaiting review by security team people, who are (even moreso, given
> current events) generally insanely busy.
Huh? What's not there yet? I've bee
< said:
> Neither of which has any relevance to the actual root zone ZSK, which
> could require an emergency roll tomorrow.
Surely that's why there's a separate KSK. The ZSK can be rolled at
any time.
-GAWollman
___
freebsd-security@freebsd.org mailin
< said:
> Right. That's what Dag-Erling and I have been saying all along. If you
> have the private host key you can impersonate the server. That's not a
> MITM attack. That's impersonating the server.
If you can impersonate an ssh server, you can also do MitM, if the
client isn't using an authen
<
said:
> 2048 is well more than efficient. Speaking soley for RSA in that matter.
I asked R. about that a few months back, and he expressed the view
that 2,048 bits is the *minimum* RSA key size anyone should consider
using at this point. I'm willing to take his word for it.
-GAWollman
__
< said:
> On 05/04/11 06:57 +1000, Peter Jeremy wrote:
>> It has occurred to me that maybe the FreeBSD SO should create a root
>> cert and distribute that with FreeBSD. That certificate would at
>> least have the same trust level as FreeBSD.
>>
>> --
>> Peter Jeremy
> But what would that CA tr
< said:
> Is anybody planning to update the base system heimdal, which has been
> largely untouched since May 2008?
I would love for it to go away entirely, and those base-system
components that depend on it to learn how to use either Kerberos
implementation from ports. (I'd also love for the an
The IESG today approved the publication of the fix for the SSL/TLS
renegotiation protocol bug as a Proposed Standard. We should expect
to see updates from all the major security libraries (OpenSSL, GnuTLS,
and NSS) fairly quickly as the developers have all been involved in
the process and have alr
< said:
> NOTE WELL: This update causes OpenSSL to reject any attempt to renegotiate
> SSL / TLS session parameters. As a result, connections in which the other
> party attempts to renegotiate session parameters will break. In practice,
> however, session renegotiation is a rarely-used feature,
< 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 p
< said:
> The thing that concerned me is an entry I saw in netstat showing
> my system connecting back to a machine that was attempting to log
> in to ssh.
> Does the ssh server establish a socket to a client attempting login?
The SSH protocol does not, but you appear to be using "TCP wrappers"
< said:
> For the "usual suspects" of applications running, (e.g. sendmail,
> apache, BIND etc) would it be possible to pass crafted packets
> through to this function remotely via those apps ? ie how easy is this to do
> ?
inet_network() is a very infrequently-used function (perhaps because
<
said:
> This is correct -- login services must be modified to properly set up user
> audit state at login. I am not familiar with work relating to this with xdm,
> kdm, gdm, etc, but it would be very good to see this happen.
Surely this is something that belongs in a PAM module...? The who
< said:
> Failed password for illegal user qscand from 217.20.119.212 port 50657 ssh2
I modified my version of /etc/periodic/security/800.loginfail to
filter out all the "illegal user" messages from sshd; otherwise I
would be getting about 24,000 lines of crap a night in my security
report (3,000
< said:
> Personally, I would like to see sudo not only in the base system, but in
> the base system with a default configuration that mimics su(1) and thus
> replaces it entirely. The only difference is which password you need to
> provide. After a period for migration (or perhaps just in 6.
< said:
> No, you're wrong on this.
> Packets for TCP with SYN + FIN set are valid under T/TCP.
Packets for TCP with SYN + FIN set are valid under TCP, period. See
RFC 793 page 66, where it describes the processing of segments with
the SYN bit set:
The connection state should be change
< It is not invalid for a TCP segment to have both SYN and FIN set. See
> for instance RFC 1644.
RFC 793 is perhaps the better reference, followed by RFC 1025.
-GAWollman
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/l
< said:
> First of all, I know that not dropping SYN/FIN isn't really a big deal, it
> just makes no sense. But since it doesn't make any sense, I don't see
> the reason why not to discard them.
Perhaps because you are under the erroneous impression that such
packets are nonsensical.
-GAWollman
<
said:
> The political problem is that if all operating systems do that,
> Intel has a pretty dud feature on their hands, and they are not
> particularly eager to accept that fact.
Intel already had a pretty dud feature on their hands; just ask anyone
in the architecture community (probably inc
47 matches
Mail list logo
