Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-16:19.sendmsg

2016-05-17 Thread Alan Somers
I think you put the wrong revision numbers in here.  Revision 300093 is the
kbd fix for stable/9.  300092 is the right revision for the sendmsg fix in
stable/10.

On Tue, May 17, 2016 at 4:40 PM, FreeBSD Security Advisories <
security-advisor...@freebsd.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
> =
> FreeBSD-SA-16:19.sendmsgSecurity
> Advisory
>   The FreeBSD
> Project
>
> Topic:  Incorrect argument handling in sendmsg(2)
>
> Category:   core
> Module: kernel
> Announced:  2016-05-17
> Credits:CTurt and the HardenedBSD team
> Affects:FreeBSD 10.x
> Corrected:  2016-05-17 22:30:43 UTC (stable/10, 10.3-STABLE)
> 2016-05-17 22:28:27 UTC (releng/10.3, 10.3-RELEASE-p3)
> 2016-05-17 22:28:20 UTC (releng/10.2, 10.2-RELEASE-p17)
> 2016-05-17 22:28:11 UTC (releng/10.1, 10.1-RELEASE-p34)
> CVE Name:   CVE-2016-1887
>
> For general information regarding FreeBSD Security Advisories,
> including descriptions of the fields above, security branches, and the
> following sections, please visit https://security.FreeBSD.org/>.
>
> I.   Background
>
> The sendmsg(2) system call allows to send data to a socket.  The data
> may be accompanied by optional ancillary data.
>
> II.  Problem Description
>
> Incorrect argument handling in the socket code allows malicious local
> user to overwrite large portion of the kernel memory.
>
> III. Impact
>
> Malicious local user may crash kernel or execute arbitrary code in the
> kernel,
> potentially gaining superuser privileges.
>
> IV.  Workaround
>
> No workaround is available.
>
> V.   Solution
>
> Perform one of the following:
>
> 1) Upgrade your vulnerable system to a supported FreeBSD stable or
> release / security branch (releng) dated after the correction date.
>
> Reboot is required.
>
> 2) To update your vulnerable system via a binary patch:
>
> Systems running a RELEASE version of FreeBSD on the i386 or amd64
> platforms can be updated via the freebsd-update(8) utility:
>
> # freebsd-update fetch
> # freebsd-update install
>
> Reboot is required.
>
> 3) To update your vulnerable system via a source code patch:
>
> The following patches have been verified to apply to the applicable
> FreeBSD release branches.
>
> a) Download the relevant patch from the location below, and verify the
> detached PGP signature using your PGP utility.
>
> # fetch https://security.FreeBSD.org/patches/SA-16:19/sendmsg.patch
> # fetch https://security.FreeBSD.org/patches/SA-16:19/sendmsg.patch.asc
> # gpg --verify sendmsg.patch.asc
>
> b) Apply the patch.  Execute the following commands as root:
>
> # cd /usr/src
> # patch < /path/to/patch
>
> c) Recompile your kernel as described in
> https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
> system.
>
> VI.  Correction details
>
> The following list contains the correction revision numbers for each
> affected branch.
>
> Branch/path  Revision
> - -
> stable/10/r300093
> releng/10.1/  r300085
> releng/10.2/  r300086
> releng/10.3/  r300087
> - -
>
> To see which files were modified by a particular revision, run the
> following command, replacing NN with the revision number, on a
> machine with Subversion installed:
>
> # svn diff -cNN --summarize svn://svn.freebsd.org/base
>
> Or visit the following URL, replacing NN with the revision number:
>
> https://svnweb.freebsd.org/base?view=revision&revision=NN>
>
> VII. References
>
> http://cturt.github.io/sendmsg.html>
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1887>
>
> The latest revision of this advisory is available at
> https://security.FreeBSD.org/advisories/FreeBSD-SA-16:19.sendmsg.asc>
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCgAGBQJXO50VAAoJEO1n7NZdz2rnWOAP/RyUks4Xf30YVGra+bHUjOsw
> gFQEJ7HNNJHkkaJ5l0LpVh87YQxr7VXnlddskDRcL6MDf7IjW5bkpw+875iEFz93
> VykCN+1l84D0WlXAi9YZwg1GWoQs3SBfNpT1dtr9GuqJYAAeBfvMydJI1jHbJzJJ
> 7inDzgvhfPOaq8wQBfjXbUN0GgYiz6dJc3xir4+4JRw0C9sgzh1pI14o1oREJbZ0
> glmHRCpuijndqluabl7rF19mSSDyF0AV7RqDCZIt7AkYHWvR1yLl4o0LGGBYCLXx
> iArz2ayzbAqBVw1JktVHzGx0HuVpobxb/yOpDuYBcaxtSL6riuSYrkzHp0Dca+JT
> 0/qENdMnXDN98ZMBcvVR66uWUuTVEF3/T2LXCi6G+RllrcoavvLqrcjghqT5k84P
> jmAjO3Q3rIeAinjArfyexHo/f/A5CHGJylsY0FZd41A35xWaYg/dd0cT+8qsoigD
> 65Ix+/6AOIjocqqQToFXiHKBCN5unwrn/UT5heU0K3ZqESGmxUrx+6yJ3mjDjtLh
> C7zWcNaJu1whcT7e4eKx9vMlAFFt6OrSnr1V09KnqPiHPtIu95PZhGlrizlZV

Re: Periodic jobs lockf timeout

2017-10-24 Thread Alan Somers
On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos  wrote:
>
> Hi,
>
> I’ve come across a problem with the “daily” security job. On an overloaded 
> system with lots of ZFS datasets,
> lots of files, heavy system load and, to add insult to injury, a ZFS crub 
> going on the find’s issued by the
> periodic checks can take forever. They can take so long, I have found several 
> lockf’s waiting.
>
> Is it sane to have an unlimited timeout for lockf? Probably it would be 
> better to have at least a configurable
> timeout for each cathegory. It’s really unlikely to see an overlap for a 
> weekly or monthly job, but for daily
> jobs it would be good to have a sane default, say, an hour or two.
>
> There’s even a parameter on /etc/defaults/periodic.conf but it seems it’s not 
> used right now.
>
> # Max time to sleep to avoid causing congestion on download servers
> anticongestion_sleeptime=3600
>
>
> The alternative would be to have defaults for a sane timeout for each 
> cathegory, like
>
> daily_lockf_timeout
> weekly_lockf_timeout
> monthly_lockf_timeout
>
> Thoughts? It’s pretty simple to do and overlapping periodic jobs are really 
> useless.

Are you talking about the lockf in /usr/sbin/periodic?  It already has
a timeout of 0, which should prevent overlapping periodic jobs.  Or is
there some other lockf involved?  Without knowing which lockf you're
talking about, I can't understand your problem.

The anticongestion_sleeptime variable is unrelated to lockf.

-Alan
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Wrong patch link in FreeBSD-EN-21:24.libcrypto

2021-08-24 Thread Alan Somers
The just published errata notice contains a bad url.
is: fetch https://security.FreeBSD.org/patches/EN-21:17/libcrypto.patch
should be: https://security.FreeBSD.org/patches/EN-21:24/libcrypto.patch

-Alan
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"


Re: Wrong patch link in FreeBSD-EN-21:24.libcrypto

2021-08-24 Thread Alan Somers
Sounds good.

On Tue, Aug 24, 2021 at 4:51 PM Gordon Tetlow  wrote:

> There's always one. Thanks for the check. I've just pushed this to the
> website with the corrected link. It should be corrected in the next 5-10
> minutes online.
>
> Regards,
> Gordon
>
> On Tue, Aug 24, 2021 at 2:36 PM Alan Somers  wrote:
>
>> The just published errata notice contains a bad url.
>> is: fetch https://security.FreeBSD.org/patches/EN-21:17/libcrypto.patch
>> should be: https://security.FreeBSD.org/patches/EN-21:24/libcrypto.patch
>>
>> -Alan
>>
>
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"


Backdoor in xz 5.6.0

2024-03-29 Thread Alan Somers
A malicious developer added a backdoor to xz 5.6.0 and 5.6.1, and
snuck it into Fedora builds.  That's the same version that FreeBSD
CURRENT uses.  For multiple reasons we aren't vulnerable (the
malicious code isn't included in xz's git repo, only its dist
tarballs, the malicious code is only triggered on x86_64 linux in an
rpm or deb build, and the malicious code resides in a .m4 file which
our build process doesn't use).  But upstream considers all of 5.6.0
to be untrustworthy and recommends that everyone to 5.4.5.

summary: 
https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/
details: https://www.openwall.com/lists/oss-security/2024/03/29/4