Audit Linux privileges now to limit compromise, escalation, and system-wide damage. Review Linux Privileges×

Alerts This Week
Warning Icon 1 428
Alerts This Week
Warning Icon 1 428

Stay Secure with the Latest Linux Advisories

Filter%20icon Refine advisories
X Clear Filters
X Clear Filters
View More

Get the latest News and Insights

Get the latest Linux and open source security news straight to your inbox.

Community Poll

Should Linux servers automatically install security updates?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/157-should-linux-servers-automatically-install-security-updates?task=poll.vote&format=json
157
radio
0
[{"id":506,"title":"Yes \u2014 critical security patches should install automatically.","votes":0,"type":"x","order":1,"pct":0,"resources":[]},{"id":507,"title":"No \u2014 every update should be tested before deployment.","votes":3,"type":"x","order":2,"pct":60,"resources":[]},{"id":508,"title":"Only critical vulnerabilities should auto-install.","votes":0,"type":"x","order":3,"pct":0,"resources":[]},{"id":509,"title":"I patch when Reddit starts panicking.","votes":2,"type":"x","order":4,"pct":40,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200
Loading...

Explore Latest Linux Security advisories

We found -7 articles for you...
89

Fedora 38: 2024-45b9d72ebf Vital: Python Fabric SSH Patch

Terrapin fix. -------------------------------------------------------------------------------- Fedora Update Notification FEDORA-2024-39a8c72ea9 2024-01-11 02:15:43.703845 -------------------------------------------------------------------------------- Name : python-paramiko Product : Fedora 38 Version : 3.4.0 Release : 1.fc38 URL : https://github.com/paramiko/paramiko Summary : SSH2 protocol library for python Description : Paramiko (a combination of the Esperanto words for "paranoid" and "friend") is a module for python 2.3 or greater that implements the SSH2 protocol for secure (encrypted and authenticated) connections to remote machines. Unlike SSL (aka TLS), the SSH2 protocol does not require hierarchical certificates signed by a powerful central authority. You may know SSH2 as the protocol that replaced telnet and rsh for secure access to remote shells, but the protocol also includes the ability to open arbitrary channels to remote services across an encrypted tunnel (this is how sftp works, for example). -------------------------------------------------------------------------------- Update Information: Terrapin fix -------------------------------------------------------------------------------- ChangeLog: * Tue Dec 19 2023 Gwyn Ciesla - 3.4.0-1 - 3.4.0 * Sun Jul 30 2023 Paul Howarth - 3.3.1-1 - Update to 3.3.1 (rhbz#2227478) - Cleaned up some very old root level files, mostly just to exercise some of our doc build and release machinery * Fri Jul 28 2023 Gwyn Ciesla - 3.3.0-1 - 3.3.0 - Add support and tests for 'Match final ..' (frequently used in ProxyJump configurations to exclude the jump host) to our SSH config parser (GH#1907, GH#1992) - Add an explicit 'max_concurrent_prefetch_requests' argument to 'paramiko.client.SSHClient.get' and 'paramiko.client.SSHClient.getfo', allowing users to limit the number of concurrent requests used during prefetch (GH#1587, GH#2058) * Fri Jul 21 2023Fedora Release Engineering - 3.2.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Thu Jun 15 2023 Python Maint - 3.2.0-2 - Rebuilt for Python 3.12 * Sat May 27 2023 Paul Howarth - 3.2.0-1 - Update to 3.2.0 (rhbz#2210398) - Fixed a very sneaky bug found at the apparently rarely-traveled intersection of RSA-SHA2 keys, certificates, SSH agents, and stricter-than-OpenSSH server targets, which manifested as yet another "well, if we turn off SHA2 at one end or another, everything works again" problem, for example with version 12 of the Teleport server endpoint - The 'server-sig-algs' and 'RSA-SHA2' features added around Paramiko 2.9 or so, had the annoying side effect of not working with servers that don't support *either* of those feature sets, requiring use of 'disabled_algorithms' to forcibly disable the SHA2 algorithms on Paramiko's end (GH#1961, GH#2012 and countless others) - The *experimental* '~paramiko.transport.ServiceRequestingTransport' (noted in its own entry in this changelog) includes a fix for this issue, specifically by falling back to the same algorithm as the in-use pubkey if it's in the algorithm list (leaving the "first algorithm in said list" as an absolute final fallback) - Implement '_fields()' on '~paramiko.agent.AgentKey' so that it may be compared (via '==') with other '~paramiko.pkey.PKey' instances - Since its inception, Paramiko has (for reasons lost to time) implemented authentication as a side effect of handling affirmative replies to 'MSG_SERVICE_REQUEST' protocol messages; what this means is Paramiko makes one such request before every 'MSG_USERAUTH_REQUEST', i.e. every auth attempt (GH#23) - OpenSSH doesn't care if clients send multiple service requests, but other server implementations are often stricter in what they accept after an initial service request (due to the RFCs not being clear), which can result in oddbehavior when a user doesn't authenticate successfully on the very first try (for example, when the right key for a target host is the third in one's ssh-agent) - This version of Paramiko now contains an opt-in '~paramiko.transport.Transport' subclass, '~paramiko.transport.ServiceRequestingTransport', which more-correctly implements service request handling in the Transport, and uses an auth-handler subclass internally that has been similarly adapted; users wanting to try this new experimental code path may hand this class to 'SSHClient.connect` as its 'transport_factory' kwarg - This feature is *EXPERIMENTAL* and its code may be subject to change - Minor backwards incompatible changes exist in the new code paths, most notably the removal of the (inconsistently applied and rarely used) 'event' arguments to the 'auth_xxx' methods - GSSAPI support has only been partially implemented, and is untested - Some minor backwards-*compatible* changes were made to the *existing* Transport and AuthHandler classes to facilitate the new code; for example, 'Transport._handler_table' and 'AuthHandler._client_handler_table' are now properties instead of raw attributes - Users of '~paramiko.client.SSHClient' can now configure the authentication logic Paramiko uses when connecting to servers; this functionality is intended for advanced users and higher-level libraries such as 'Fabric' (https://www.fabfile.org/); see '~paramiko.auth_strategy' for details (GH#387) - Fabric's co-temporal release includes a proof-of-concept use of this feature, implementing an auth flow much closer to that of the OpenSSH client (versus Paramiko's legacy behavior); it is *strongly recommended* that if this interests you, investigate replacing any direct use of 'SSHClient' with Fabric's 'Connection' - This feature is **EXPERIMENTAL**; please see its docs for details -Enhanced '~paramiko.agent.AgentKey' with new attributes, such as: - Added a 'comment' attribute (and constructor argument); 'Agent.get_keys()' now uses this kwarg to store any comment field sent over by the agent; the original version of the agent feature inexplicably did not store the comment anywhere - Agent-derived keys now attempt to instantiate a copy of the appropriate key class for access to other algorithm-specific members (e.g. key size); this is available as the '.inner_key' attribute - This functionality is now in use in Fabric's new '--list-agent-keys' feature, as well as in Paramiko's debug logging - '~paramiko.pkey.PKey' now offers convenience "meta-constructors", static methods that simplify the process of instantiating the correct subclass for a given key input - For example, 'PKey.from_path' can load a file path without knowing *a priori* what type of key it is (thanks to some handy methods within our cryptography dependency); going forwards, we expect this to be the primary method of loading keys by user code that runs on "human time" (i.e. where some minor efficiencies are worth the convenience) - In addition, 'PKey.from_type_string' now exists, and is being used in some internals to load ssh-agent keys - As part of these changes, '~paramiko.pkey.PKey' and friends grew a '~paramiko.pkey.PKey.identifiers' classmethod; this is inspired by the '~paramiko.ecdsakey.ECDSAKey.supported_key_format_identifiers' classmethod (which now refers to the new method); this also includes adding a '.name' attribute to most key classes (which will eventually replace '.get_name()') - '~paramiko.pkey.PKey' grew a new '.algorithm_name' property that displays the key algorithm; this is typically derived from the value of '~paramiko.pkey.PKey.get_name'; for example, ED25519 keys have a 'get_name' of 'ssh-ed25519' (the SSH protocol key typefield value), and now have a 'algorithm_name' of 'ED25519' - '~paramiko.pkey.PKey' grew a new '.fingerprint' property that emits a fingerprint string matching the SHA256+Base64 values printed by various OpenSSH tooling (e.g. 'ssh-add -l', 'ssh -v'); this is intended to help troubleshoot Paramiko-vs-OpenSSH behavior and will eventually replace the venerable 'get_fingerprint' method - '~paramiko.agent.AgentKey' had a dangling Python 3 incompatible '__str__' method returning bytes; this method has been removed, allowing the superclass' ('~paramiko.pkey.PKey') method to run instead -------------------------------------------------------------------------------- References: [ 1 ] Bug #2255908 - TRIAGE CVE-2023-48795 python-paramiko: ssh: Prefix truncation attack on Binary Packet Protocol (BPP) [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=2255908 -------------------------------------------------------------------------------- This update can be installed with the "dnf" update program. Use su -c 'dnf upgrade --advisory FEDORA-2024-39a8c72ea9' at the command line. For more information, refer to the dnf documentation available at https://dnf.readthedocs.io/en/latest/command_ref.html All packages are signed with the Fedora Project GPG key. More details on the GPG keys used by the Fedora Project can be found at https://fedoraproject.org/security/ -------------------------------------------------------------------------------- -- _______________________________________________ package-announce mailing list -- This email address is being protected from spambots. You need JavaScript enabled to view it. To unsubscribe send an email to This email address is being protected from spambots. You need JavaScript enabled to view it. Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/This email address is being protected from spambots. You need JavaScript enabled to view it./ Do not reply to spam, report it: . The latestpython-paramiko upgrade in Fedora 38 provides essential security improvements and enhances SSH connectivity capabilities.. Fedora 38, Python Paramiko, SSH enhancement, security update. . Severity: Critical. LinuxSecurity.com Team

Calendar%202 Jan 11, 2024 Critical Fedora
202

openSUSE 15.1: openSUSE-SU-2020:2298-1 Moderate: OpenSSH Info Leak

An update that solves one vulnerability and has 5 fixes is now available. . openSUSE Security Update: Security update for openssh ______________________________________________________________________________ Announcement ID: openSUSE-SU-2020:2298-1 Rating: moderate References: #1115550 #1139398 #1142000 #1148566 #1173513 #1174162 Cross-References: CVE-2020-14145 Affected Products: openSUSE Leap 15.1 ______________________________________________________________________________ An update that solves one vulnerability and has 5 fixes is now available. Description: This update for openssh fixes the following issues: - CVE-2020-14145: Fixed a potential information leak during host key exchange (bsc#1173513). - Supplement libgtk-3-0 instead of libX11-6 to avoid installation on a textmode install (bsc#1142000) - Fixed an issue where oracle cluster with cluvfy using "scp" failing/missinterpreted (bsc#1148566). - Fixed sshd termination of multichannel sessions with non-root users (bsc#1115550,bsc#1174162). - Added speculative hardening for key storage (bsc#1139398). This update was imported from the SUSE:SLE-15-SP1:Update update project. Patch Instructions: To install this openSUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". Alternatively you can run the command listed for your product: - openSUSE Leap 15.1: zypper in -t patch openSUSE-2020-2298=1 Package List: - openSUSE Leap 15.1 (i586 x86_64): openssh-7.9p1-lp151.4.18.1 openssh-cavs-7.9p1-lp151.4.18.1 openssh-cavs-debuginfo-7.9p1-lp151.4.18.1 openssh-debuginfo-7.9p1-lp151.4.18.1 openssh-debugsource-7.9p1-lp151.4.18.1 openssh-fips-7.9p1-lp151.4.18.1 openssh-helpers-7.9p1-lp151.4.18.1 openssh-helpers-debuginfo-7.9p1-lp151.4.18.1 - openSUSELeap 15.1 (x86_64): openssh-askpass-gnome-7.9p1-lp151.4.18.1 openssh-askpass-gnome-debuginfo-7.9p1-lp151.4.18.1 openssh-askpass-gnome-debugsource-7.9p1-lp151.4.18.1 References: https://www.suse.com/security/cve/CVE-2020-14145.html https://bugzilla.suse.com/1115550 https://bugzilla.suse.com/1139398 https://bugzilla.suse.com/1142000 https://bugzilla.suse.com/1148566 https://bugzilla.suse.com/1173513 https://bugzilla.suse.com/1174162 _______________________________________________ openSUSE Security Announce mailing list -- This email address is being protected from spambots. You need JavaScript enabled to view it. To unsubscribe, email This email address is being protected from spambots. You need JavaScript enabled to view it. List Netiquette: List Archives: . OpenSUSE has released a vital security update for OpenSSH addressing a critical information leak vulnerability, essential for system integrity and confidentiality. OpenSSH Security Update, openSUSE 15.1, Moderate Severity Patch. . LinuxSecurity.com Team

Calendar%202 Dec 20, 2020 OpenSUSE
News Add Esm H240

Get the latest News and Insights

Get the latest Linux and open source security news straight to your inbox.

Community Poll

Should Linux servers automatically install security updates?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/157-should-linux-servers-automatically-install-security-updates?task=poll.vote&format=json
157
radio
0
[{"id":506,"title":"Yes \u2014 critical security patches should install automatically.","votes":0,"type":"x","order":1,"pct":0,"resources":[]},{"id":507,"title":"No \u2014 every update should be tested before deployment.","votes":3,"type":"x","order":2,"pct":60,"resources":[]},{"id":508,"title":"Only critical vulnerabilities should auto-install.","votes":0,"type":"x","order":3,"pct":0,"resources":[]},{"id":509,"title":"I patch when Reddit starts panicking.","votes":2,"type":"x","order":4,"pct":40,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200