Re: FreeBSD Security Advisory FreeBSD-SA-20:22.sqlite
05.08.20 20:54, FreeBSD Security Advisories пишет: a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 12.1] # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.12.1.patch # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.12.1.patch.asc # gpg --verify sqlite.12.1.patch.asc [FreeBSD 11.4] # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.11.4.patch # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.11.4.patch.asc # gpg --verify sqlite.11.4.patch.asc [FreeBSD 11.3] # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.11.3.patch # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.11.3.patch.asc # gpg --verify sqlite.11.3.patch.asc Hi, there is a typo in links -please replace "SA-20:21" with "SA-20:22" ___ 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"
A question about Security Advisories
Hi, Last years all Security Advisories regarding base system in the "update your vulnerable system via a source code patch " section recommends to rebuild a whole world instead of an affected part of a base system. This is in a most cases an overhead. For example 9 years old SA-11:04 [1] offers: b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/usr.bin/compress # make obj && make depend && make && make install # cd /usr/src/usr.bin/gzip # make obj && make depend && make && make install What is a reason we stop to do it? I understand that the preferred way now is a binary upgrade. Thank you. [1] https://www.freebsd.org/security/advisories/FreeBSD-SA-11:04.compress.asc ___ 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: FreeBSD Security Advisory FreeBSD-SA-25:01.openssh
29.01.25 23:31, FreeBSD Security Advisories: = FreeBSD-SA-25:01.openssh Security Advisory The FreeBSD Project Topic: OpenSSH Keystroke Obfuscation Bypass Category: contrib Module: openssh Announced: 2025-01-29 Credits: Philippos Giavridis Credits: Jacky Wei En Kung, Daniel Hugenroth and Alastair Beresford (University of Cambridge) Affects: FreeBSD 14.1 Corrected: 2024-07-15 18:45:16 UTC (stable/14, 14.2-STABLE) 2025-01-29 18:55:25 UTC (releng/14.1, 14.1-RELEASE-p7) 2024-08-01 15:03:50 UTC (stable/13, 13.4-STABLE) CVE Name: CVE-2024-39894 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 OpenSSH is an implementation of the SSH protocol suite, providing an encrypted and authenticated transport for a variety of services, including remote shell access. OpenSSH version 9.5 introduced a mechanism to mitigate keystroke timing attacks by "sending interactive traffic at fixed intervals when there is only a small amount of data being sent." II. Problem Description A logic error in the ssh(1) ObscureKeystrokeTiming feature (on by default) rendered this feature ineffective. III. Impact A passive observer could detect which network packets contain real keystrokes, and infer the specific characters being transmitted from packet timing. IV. Workaround No workaround is available. This bug does not affect connections when ObscureKeystrokeTiming was disabled or sessions where no TTY was requested. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Perform one of the following: 1) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms, or the i386 platform on FreeBSD 13, can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 2) 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. [FreeBSD 14.1] # fetch https://security.FreeBSD.org/patches/SA-25:01/openssh.patch # fetch https://security.FreeBSD.org/patches/SA-25:01/openssh.patch.asc # gpg --verify openssh.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in https://www.FreeBSD.org/handbook/makeworld.html>. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - stable/14/ bf9a275b24f6 stable/14-n268158 releng/14.1/ 88d5d8108711 releng/14.1-n267735 stable/13/ 79853e40abd8 stable/13-n258171 - Run the following command to see which files were modified by a particular commit: # git show --stat Or visit the following URL, replacing NN with the hash: https://cgit.freebsd.org/src/commit/?id=NN> To determine the commit count in a working tree (for comparison against nNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-39894> The latest revision of this advisory is available at https://security.FreeBSD.org/advisories/FreeBSD-SA-25:01.openssh.asc> Do we really need to reboot or restart sshd is enough?
Re: False positive
27.02.25 19:06, The Doctor: On Thu, Feb 27, 2025 at 07:14:14AM +0200, Oleksandr Kryvulia wrote: 26.02.25 22:51, The Doctor: This main server is seeing curl -v -v -v -v -v -v -v -v -v -v -v -vhttps://gateway.moneris.com/chktv2/request/request.php * !!! WARNING !!! * This is a debug build of libcurl, do not use in production. * STATE: INIT => SETUP handle 0x15e5070d7808; line 2393 * STATE: SETUP => CONNECT handle 0x15e5070d7808; line 2409 * Added connection 0. The cache now contains 1 members * STATE: CONNECT => RESOLVING handle 0x15e5070d7808; line 2308 * Curl_multi_closed, fd=4 multi is 0x15e507095008 * Curl_multi_closed, fd=4 entry is 0x15e507010508 * Host gateway.moneris.com:443 was resolved. * IPv6: (none) * IPv4: 23.249.192.196 * STATE: RESOLVING => CONNECTING handle 0x15e5070d7808; line 2266 * Trying 23.249.192.196:443... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS alert, unknown CA (560): * SSL certificate problem: self-signed certificate in certificate chain * multi_done[CONNECTING]: status: 60 prem: 1 done: 0 * multi_done, not reusing connection=0, forbid=0, close=0, premature=1, conn_multiplex=0 * Curl_disconnect(conn #0, aborted=1) * closing connection #0 * [CCACHE] closing #0 * Curl_multi_closed, fd=4 multi is 0x15e507095008 * Curl_multi_closed, fd=4 entry is (nil) * [CCACHE] trigger multi connchanged curl: (60) SSL certificate problem: self-signed certificate in certificate chain More details here:https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the webpage mentioned above. yet wen I check against KAli, the server says the certificate is correct. What could have gone wrong? I do not have this problem. ftp/curl built fom latest packages, version 8.12.1. % curl -v -v -v -v -v -v -v -v -v -v -v -v https://gateway.moneris.com/chktv2/request/request.php * Host gateway.moneris.com:443 was resolved. * IPv6: (none) * IPv4: 23.249.192.196 * Trying 23.249.192.196:443... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / prime256v1 / rsaEncryption * ALPN: server did not agree on a protocol. Uses default. * Server certificate: *?? subject: C=CA; ST=Ontario; L=Etobicoke; O=Moneris Solutions Corporation; CN=gateway.moneris.com *?? start date: Sep 20 14:46:33 2024 GMT *?? expire date: Oct 19 14:46:32 2025 GMT *?? subjectAltName: host "gateway.moneris.com" matched cert's "gateway.moneris.com" *?? issuer: C=US; O=Entrust, Inc.; OU=Seewww.entrust.net/legal-terms; OU=(c) 2012 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1K *?? SSL certificate verify ok. * Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha1WithRSAEncryption * Connected to gateway.moneris.com (23.249.192.196) port 443 * using HTTP/1.x GET /chktv2/request/request.php HTTP/1.1 Host: gateway.moneris.com User-Agent: curl/8.12.1 Accept: */* * Request completely sent off < HTTP/1.1 200 OK < Date: Thu, 27 Feb 2025 05:05:51 GMT < Set-Cookie: GWID=5r08cio9drsdgp3ht14vh5gm07; path=/; secure; HttpOnly < Expires: Thu, 19 Nov 1981 08:52:00 GMT < Cache-Control: no-store, no-cache, must-revalidate < Pragma: no-cache < Content-Length: 120 < Content-Type: application/json < Set-Cookie: TS019fcda0=015a7b8a0ba69d7487449af4e6244b5af029cd371252f3c29241d62c4f336e79130a22ac475f4f7fcfd170687cac1a3d9f3c133aa286fa274318844792223c93e9b50193bc; Path=/; Domain=.gateway.moneris.com; Secure; < Exception: Invalid JSON input Next question, either chatgpt or gemmini suggested rehash. How do I do a rehash if that is the problem? Do you have security/ca_root_nss installed? Or use curl -k to trust this certificate.
Re: False positive
26.02.25 22:51, The Doctor: This main server is seeing curl -v -v -v -v -v -v -v -v -v -v -v -v https://gateway.moneris.com/chktv2/request/request.php * !!! WARNING !!! * This is a debug build of libcurl, do not use in production. * STATE: INIT => SETUP handle 0x15e5070d7808; line 2393 * STATE: SETUP => CONNECT handle 0x15e5070d7808; line 2409 * Added connection 0. The cache now contains 1 members * STATE: CONNECT => RESOLVING handle 0x15e5070d7808; line 2308 * Curl_multi_closed, fd=4 multi is 0x15e507095008 * Curl_multi_closed, fd=4 entry is 0x15e507010508 * Host gateway.moneris.com:443 was resolved. * IPv6: (none) * IPv4: 23.249.192.196 * STATE: RESOLVING => CONNECTING handle 0x15e5070d7808; line 2266 * Trying 23.249.192.196:443... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS alert, unknown CA (560): * SSL certificate problem: self-signed certificate in certificate chain * multi_done[CONNECTING]: status: 60 prem: 1 done: 0 * multi_done, not reusing connection=0, forbid=0, close=0, premature=1, conn_multiplex=0 * Curl_disconnect(conn #0, aborted=1) * closing connection #0 * [CCACHE] closing #0 * Curl_multi_closed, fd=4 multi is 0x15e507095008 * Curl_multi_closed, fd=4 entry is (nil) * [CCACHE] trigger multi connchanged curl: (60) SSL certificate problem: self-signed certificate in certificate chain More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the webpage mentioned above. yet wen I check against KAli, the server says the certificate is correct. What could have gone wrong? I do not have this problem. ftp/curl built fom latest packages, version 8.12.1. % curl -v -v -v -v -v -v -v -v -v -v -v -v https://gateway.moneris.com/chktv2/request/request.php * Host gateway.moneris.com:443 was resolved. * IPv6: (none) * IPv4: 23.249.192.196 * Trying 23.249.192.196:443... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / prime256v1 / rsaEncryption * ALPN: server did not agree on a protocol. Uses default. * Server certificate: * subject: C=CA; ST=Ontario; L=Etobicoke; O=Moneris Solutions Corporation; CN=gateway.moneris.com * start date: Sep 20 14:46:33 2024 GMT * expire date: Oct 19 14:46:32 2025 GMT * subjectAltName: host "gateway.moneris.com" matched cert's "gateway.moneris.com" * issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2012 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1K * SSL certificate verify ok. * Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha1WithRSAEncryption * Connected to gateway.moneris.com (23.249.192.196) port 443 * using HTTP/1.x > GET /chktv2/request/request.php HTTP/1.1 > Host: gateway.moneris.com > User-Agent: curl/8.12.1 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK < Date: Thu, 27 Feb 2025 05:05:51 GMT < Set-Cookie: GWID=5r08cio9drsdgp3ht14vh5gm07; path=/; secure; HttpOnly < Expires: Thu, 19 Nov 1981 08:52:00 GMT < Cache-Control: no-store, no-cache, must-revalidate < Pragma: no-cache < Content-Length: 120 < Content-Type: application/json < Set-Cookie: TS019fcda0=015a7b8a0ba69d7487449af4e6244b5af029cd371252f3c29241d62c4f336e79130a22ac475f4f7fcfd170687cac1a3d9f3c133aa286fa274318844792223c93e9b50193bc; Path=/; Domain=.gateway.moneris.com; Secure; < Exception: Invalid JSON input
