On 8 April 2014 14:45, Nathan Dorfman wrote:
> Are you sure about that? The only email I saw stated that FreeBSD 8.x
> and 9.x weren't vulnerable because they were using an older OpenSSL,
> from before the vulnerability was introduced.
That is correct.
> FreeBSD 10-STABLE, on the other hand, see
On 8 April 2014 14:53, Ed Maste wrote:
> I see that the fixes were committed a few minutes ago:
Oops, some typos in the revision numbers in my last email (but the
links were fine) -- here are the correct revision numbers:
FreeBSD current: r264265
http://svnweb.freebsd.org/base?view=revis
On 10 April 2014 06:33, Kimmo Paasiala wrote:
>
> Going back to this original report of the vulnerability. Has it been
> established with certainty that the attacker would first need MITM capability
> to exploit the vulnerability? I'm asking this because MITM capability is not
> something that
On 27 January 2016 at 03:20, FreeBSD Security Advisories
wrote:
>
> The following command can be used to test if the Linux binary
> compatibility layer is loaded:
>
> # kldstat -m linuxelf
If it is not loaded, kldstat reports:
kldstat: can't find module linuxelf: No such file or directory
If it
> There are patches ready for FreeBSD to use and it's ready to be shipped
> in FreeBSD. However, for some reason FreeBSD developers do not want to
> ship ASLR in FreeBSD. Why can't it be included at least as non-default
> src.conf option and marked as experimental?
A little while ago I asked kib@
On 22 August 2016 at 20:28, Gleb Smirnoff wrote:
>
> The freebsd-update build code attempts to extract and ignore timestamps in
> order
> to determine whether files are 'really' changing between builds;
> unfortunately these
> particular files contain a build artifact which the freebsd-update co
On 3 September 2016 at 02:31, Garrett Wollman wrote:
>
> I see now that this was fixed by emaste@ yesterday (r305269). I'm a
> bit disappointed that it was done using MAXLOGNAME, but looking at the
> way it's used in the code, fixing it to use the proper POSIX parameter
> {LOGIN_NAME_MAX} would r
On 28 December 2016 at 06:31, Dimitry Andric wrote:
>
> This looks like a minor bug in elfcopy, when used as objcopy,
> specifically when in combination with the --input-target binary flag:
>
> $ mkdir /tmp/foo
> $ export TMPDIR=/tmp/foo
> $ ls -l /tmp/foo/
> $ /usr/bin/objcopy --input-target bina
On 20 June 2017 at 04:13, Vladimir Terziev wrote:
> Hi,
>
> I assume FreeBSD security team is already aware about the Stack Clash
> vulnerability, that is stated to affect FreeBSD amongst other Unix-like OS.
Yes, the security team is aware of this. Improvements in stack
handling are in progress
On 20 June 2017 at 16:22, Ed Maste wrote:
> On 20 June 2017 at 04:13, Vladimir Terziev wrote:
>> Hi,
>>
>> I assume FreeBSD security team is already aware about the Stack Clash
>> vulnerability, that is stated to affect FreeBSD amongst other Unix-like OS.
>
> Y
On 21 June 2017 at 20:22, Ed Maste wrote:
> These changes are expected to be
> committed to FreeBSD soon, and from there they will be merged to
> stable branches and into updates for supported releases.
The changes have now been merged to HEAD in r320317.
https://svnweb.freebsd.org/
On 3 July 2017 at 12:29, Michelle Sullivan wrote:
>
> Been watching for it in 10-STABLE... didn't see it go in... did I miss it?
It hasn't yet been merged -- there were a couple of issues with the
initial commit which were fixed shortly after in HEAD. We are now
waiting on the MFC timer for the f
With respect to
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
The FreeBSD Security Team recently learned of the details of these
issues that affect certain CPUs. Details could not be discussed
publicly, but mitigation work is in progress.
Work is ongoing to develop
On 12 January 2018 at 05:36, Zahrir, Abderrahmane
wrote:
> Hi Gordon,
>
> Is it possible to include me in your distribution list so that I can get
> notified when the FreeBSD patch is available.
The best way ensure you'll be notified when the changes are available
as a patch or SA for releases i
On 27 February 2018 at 15:36, Davide Davini wrote:
> Hi,
>
> I'd like to know too. Maybe I missed something but as I understand it there
> are only patches on 11-stable now, is that correct?
The change is committed to stable/11, and a patch against 11.1 is
available for testing now. Kostik posted
Background
--
A number of issues relating to speculative execution were found last
year and publicly announced January 3rd. A variety of techniques used to
mitigate these issues have been committed to FreeBSD-CURRENT and have
been merged to the stable/11 branch.
The changes will be merged
On 18 March 2018 at 13:54, Jan Demter wrote:
> Hi Andrea!
>
> Am 16.03.18 um 17:11 schrieb Andrea Venturoli via freebsd-security:
>>
>> On 03/14/18 05:29, FreeBSD Security Advisories wrote:
>>>
>>> # sysctl vm.pmap.pti
>>> vm.pmap.pti: 1
>>
>> Of course I find this enabled on the Intel box and not
On 27 April 2018 at 22:39, grarpamp wrote:
> https://www.youtube.com/watch?v=bT_k06Xg-BE
>
> [Conference talk abstract and bio omitted]
By all means do post interesting and relevant discussion on the lists,
but please don't cross-post to multiple mailing lists with nothing but
cut-and-pasted cont
On Wed, 3 Jul 2019 at 06:05, Doug Hardie wrote:
>
> > Afterwards, reboot the system and run:
> >
> > # fsck -t ufs -f -p -T ufs:-z
> >
> > to clean up your existing filesystems.
>
> After rebooting the system I get:
>
> master# fsck -t ufs -f -p -T ufs:-z
> /dev/ada0p2: NO WRITE ACCESS
> /dev/ada0
On Wed, 3 Jul 2019 at 11:21, Doug Hardie wrote:
>
> That is going to be a bit tricky to do on a headless server that is remote.
> None of mine have consoles. They are all accessed via SSH. Any ideas how
> this situation can be handled?
Probably an rc.d script with BEFORE: root that invokes t
Upstream OpenSSH-portable removed libwrap support in version 6.7,
released in October 2014. We've maintained a patch in our tree to
restore it, but it causes friction on each OpenSSH update and may
introduce security vulnerabilities not present upstream. It's (past)
time to remove it.
Although the
On Fri, 14 Feb 2020 at 15:27, Joey Kelly wrote:
>
> On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote:
> > Upstream OpenSSH-portable removed libwrap support in version 6.7,
> > released in October 2014. We've maintained a patch in our tree to
> > restore it, b
On Sat, 15 Feb 2020 at 05:03, Bjoern A. Zeeb
wrote:
>
> I am also worried that the change will make a lot of machines
> unprotected upon updating to 13 if there is no big red warning flag
> before the install.
At least having sshd emit a warning is a prerequisite, certainly. I
don't yet know if t
On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote:
>
> Hi,
>
> Together with our customers, Semihalf is interested in improving the status
> of security mitigations enablement in FreeBSD.
Happy to hear that there's interest in this work!
> 1. Are there any hard blockers, like missing features or
On Fri, 17 Apr 2020 at 09:13, Shawn Webb wrote:
>
> Quick note: paxtest's algorithms for measuring ASLR was meant to test
> ASLR, not FreeBSD's ASR implementation. Thus, paxtest results for
> FreeBSD's ASR are moot.
paxtest's entropy estimate is superficial, and indeed can produce a
more or less
On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty
wrote:
>
> I'm on a similar ride. We run applications in both i386 and amd64 jails
> with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good.
Great!
> On the build server, the i386 jail with aslr enabled wasn't able to
> build gcc9;
On Tue, 21 Apr 2020 at 15:29, Eugene Grosbein wrote:
>
> 21.04.2020 23:55, FreeBSD Security Advisories wrote:
> > =
> > FreeBSD-SA-20:10.ipfw Security
> > Advisory
> >
On Tue, 21 Apr 2020 at 18:50, Eugene Grosbein wrote:
>
> > I believe this is correct; what about this statement:
> >
> > No workaround is available. Systems not using the ipfw firewall, and
> > systems that use the ipfw firewall but without any rules using "tcpoptions"
> > or "tcpmss" keywords, a
On Thu, 23 Apr 2020 at 11:38, Brooks Davis wrote:
>
> > I was thinking if it is possible to come up with such wide test
> > coverage to test every single application from the base system. Do you
> > think it is achievable or should we rather follow the approach to do
> > as many tests as possible,
On Wed, 22 Apr 2020 at 02:10, Dewayne Geraghty
wrote:
>
> Thank-you for the pointer to elfctl. Unfortunately it looks like I need
> to create the section in the image file, due to my: (for example)
>
> # elfctl -l /usr/bin/ztest
> Known features are:
> aslrDisable ASLR
> protmax
On Mon, 20 Apr 2020 at 10:22, Marcin Wojtas wrote:
>
> Indeed I thought of kyua and measuring buildworld execution time for
> stressing the DUT and having the first comparison numbers for the low
> price.
>
> Do you think it is possible to get help here, i.e. is there a FreeBSD
> devops team, main
On Mon, 4 May 2020 at 19:39, Dewayne Geraghty
wrote:
>
> It would be palatable to have a "secure.mk" under /usr/ports/Mk/Uses
> that enables pie, relro, now, noexecstack and elfctl features. Then
> port users can enable/disable their (elfctl) default features as they wish.
The general intent fo
On Wed, 20 May 2020 at 03:20, Damien DEVILLE
wrote:
>
> Hi everyone,
>
> This a very good news. Thanks to Semihalf to their commitment on this subject.
> At Stormshield as a security vendor using FreeBSD we are highly interested in
> all subjects that enhance the security level of FreeBSD.
> What
On Sat, 16 May 2020 at 20:02, Ihor Antonov wrote:
>
> Hello FreeBSD Community,
>
> I am looking for possible options to sandbox an untrusted application that
> runs with root privileges.
>
> I can't use Jails or Capsicum as modification of the application is outside of
> the scope of my task and a
On Mon, 25 May 2020 at 14:00, Ihor Antonov wrote:
>
> I was looking at Capsicumizer and it looks very interesting.
> The only reason I was hesitant is that this is an external application, not a
> FreeBSD core. Is it going to be included in FreeBSD in some distant future?
There are no explicit pl
Kostik and I recently committed a couple of changes to improve PIE
binary support:
r361725 Do not allow to load ET_DYN object with DF_1_PIE flag set.
r361740 lld: Set DF_1_PIE for -pie
Previously there could be ambiguity as to whether an object is a
shared library (DSO) or Position Independent Ex
On Thu, 4 Jun 2020 at 20:15, Dewayne Geraghty
wrote:
>
> Thank-you Ed. Though I have two questions:
>
> 1. We've recompiled all the ports I use with either -fPIC or -fPIE and
> the linker flag -pie. Is there something required for ports to utilise
> these changes, or are the changes only in the m
On Wed, 9 Dec 2020 at 18:03, FreeBSD Security Advisories
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> =
> FreeBSD-SA-20:33.opensslSecurity Advisory
>
On Thu, 10 Dec 2020 at 10:43, Wall, Stephen wrote:
>
> > A query: am I right that the patch doesn’t bump the OpenSSL version to
> > 1.1.1.i ?
>
> That is correct.
Further to that, OpenSSL 1.1.1i includes some additional, minor
changes beyond the vulnerability fix. 1.1.1i is now in HEAD (as of
r3
On Mon, 14 Dec 2020 at 11:46, Ed Maste wrote:
>
> On Thu, 10 Dec 2020 at 10:43, Wall, Stephen wrote:
> >
> > > A query: am I right that the patch doesn’t bump the OpenSSL version to
> > > 1.1.1.i ?
> >
> > That is correct.
>
> Further to that
We now have OpenSSH 8.7p1 in the base system and I will MFC it to
stable branches soon. (FIDO/U2F support is one of the most anticipated
new features available in this OpenSSH version, but it is not yet
enabled in the base system - additional work is ongoing.)
There is an important caveat to be aw
On Thu, 9 Sept 2021 at 14:01, Ed Maste wrote:
>
> There is an important caveat to be aware of for the next base system
> update though - I've reproduced it below (from OpenSSH's release
> notes, https://www.openssh.com/releasenotes.html).
Upstream has also made a change to
On Thu, 1 Dec 2022 at 10:28, mike tancsa wrote:
>
> My concern is the "evil server in the middle" ... Things like route
> highjacking are not that uncommon. I have a number of IoT devices out
> there I will need to patch, some still based on RELENG_11.
The bug was introduced after releng/11, so t
We've seen many blog posts and news articles about this issue and
unfortunately most of them get the details wrong. So, to clarify:
- This issue affects only /sbin/ping, not kernel ICMP handling.
- The issue relies on receipt of malicious packet(s) while the ping
utility is running (i.e., while
On Thu, 16 Feb 2023 at 13:48, Michael Grimm wrote:
>
>
>
> > On 16. Feb 2023, at 19:23, FreeBSD Security Advisories
> > wrote:
>
> […]
>
> > Branch/path Hash Revision
> > - -
>
On Mon, 6 Mar 2023 at 08:16, András László Farkas
wrote:
>
> Dear FreeBSD Security support team.
>
> According to your official advisory on FreeBSD-SA-22:15.ping, the affected
> versions are "All supported versions of FreeBSD", which means in practice
> 12.3, 12.4 and 13.1.
>
> My question.:
> I
Upstream OpenSSH has been working on deprecating DSA keys for some
time, and I intend to follow suit in FreeBSD.
>From the OpenSSH 9.8p1 release notes:
===
OpenSSH has disabled DSA keys by default since 2015 but has retained
run-time optional support for them. DSA was the only mandatory-to-
imple
On Wed, 29 Jan 2025 at 23:53, Oleksandr Kryvulia wrote:
>
> Do we really need to reboot or restart sshd is enough?
Just restart sshd. If you're applying a binary patch via
freebsd-update this is done automatically for you.
48 matches
Mail list logo
