Language Selection

English French German Italian Portuguese Spanish

OpenSSH 8.0 released

Filed under
Security
BSD

This release contains mitigation for a weakness in the scp(1) tool
and protocol (CVE-2019-6111): when copying files from a remote system
to a local directory, scp(1) did not verify that the filenames that
the server sent matched those requested by the client. This could
allow a hostile server to create or clobber unexpected local files
with attacker-controlled content.

This release adds client-side checking that the filenames sent from
the server match the command-line request,

The scp protocol is outdated, inflexible and not readily fixed. We
recommend the use of more modern protocols like sftp and rsync for
file transfer instead.

Read more

Written by Michael Larabel hours later

  • OpenSSH 8.0 Released - Addresses SCP Vulnerability, New SSH Additions

    Theo de Raadt and the OpenBSD developers maintaining OpenSSH today unveiled OpenSSH 8.0.

    OpenSSH 8.0 does have an important security fix if you use scp for copying files to/from remote systems. Up until now when copying files from remote systems to a local directory, SCP was not verifying the filenames of what was being sent from the server to client and that could allow a hostile server to create or clobber unexpected local files with attack-controlled data regardless of what file(s) were actually requested for copying from the remote server.

OpenSSH 8.0 released

  • OpenSSH 8.0 released

    OpenSSH 8.0 has just been released. It will be available from the
    mirrors listed at http://www.openssh.com/ shortly.

    OpenSSH is a 100% complete SSH protocol 2.0 implementation and
    includes sftp client and server support.

    Once again, we would like to thank the OpenSSH community for their
    continued support of the project, especially those who contributed
    code or patches, reported bugs, tested snapshots or donated to the
    project. More information on donations may be found at:
    http://www.openssh.com/donations.html

OpenSSH 8.0 released

  • OpenSSH 8.0 released; addresses SCP vulnerability and new SSH additions

    Theo de Raadt and the OpenBSD developers who maintain the OpenSSH, today released the latest version OpenSSH 8.0.

    OpenSSH 8.0 has an important security fix for a weakness in the scp(1) tool when you use scp for copying files to/from remote systems. Till now when copying files from remote systems to a local directory, SCP was not verifying the filenames of what was being sent from the server to client. This allowed a hostile server to create or clobber unexpected local files with attack-controlled data regardless of what file(s) were actually requested for copying from the remote server. OpenSSH 8.0 adds client-side checking that the filenames sent from the server match the command-line request.

    While this client-side checking added to SCP, the OpenSSH developers recommend against using it and instead use sftp, rsync, or other alternatives. “The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead.“, mention OpenSSH developers.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Security Leftovers

  • Why Are Cryptographers Being Denied Entry into the US?

    Is there some cryptographer blacklist? Is something else going on? A lot of us would like to know.

  • Security Engineering: Third Edition

    Today I put online a chapter on Who is the Opponent, which draws together what we learned from Snowden and others about the capabilities of state actors, together with what we’ve learned about cybercrime actors as a result of running the Cambridge Cybercrime Centre. Isn’t it odd that almost six years after Snowden, nobody’s tried to pull together what we learned into a coherent summary?

    There’s also a chapter on Surveillance or Privacy which looks at policy. What’s the privacy landscape now, and what might we expect from the tussles over data retention, government backdoors and censorship more generally?

  • Google halts some business with China's Huawei: report

    Huawei will reportedly no longer be able to access Android updates, the Gmail app, the Google Play store and new versions of Google phones outside of China.

  • Google restricts Huawei's use of Android

    Existing Huawei smartphone users will be able to update apps and push through security fixes, as well as update Google Play services.

    But when Google launches the next version of Android later this year, it may not be available on Huawei devices.

    Future Huawei devices may no longer have apps such as YouTube and Maps.

  • Forget Huawei, The Internet Of Things Is The Real Security Threat
    We've noted for a while how a lot of the US protectionist security hysteria surrounding Huawei isn't supported by much in the way of hard data. And while it's certainly possible that Huawei helps the Chinese government spy, the reality is that Chinese (or any other) intelligence services don't really need to rely on Huawei to spy on the American public. Why? Because people around the world keep connecting millions of internet of broken things devices to their home and business networks that lack even the most rudimentary of security and privacy protections. Week after week we've documented how these devices are being built with both privacy and security as a distant afterthought, resulting in everything from your television to your refrigerator creating both new attack vectors and wonderful new surveillance opportunities for hackers and state actors.

today's howtos

Android Leftovers

A Look At The MDS Cost On Xeon, EPYC & Xeon Total Impact Of Affected CPU Vulnerabilities

This weekend I posted a number of benchmarks looking at the performance impact of the new MDS/Zombieload vulnerabilities that also included a look at the overall cost of Spectre/Meltdown/L1TF/MDS on Intel desktop CPUs and AMD CPUs (Spectre). In this article are similar benchmarks but turning the attention now to Intel Xeon hardware and also comparing those total mitigation costs against AMD EPYC with its Spectre mitigations. This article offers a look at the MDS/Zombieload mitigations on a 1st Gen Skylake Xeon Scalable server as well as a Kabylake Xeon E3 server for reference. Following that is a look at the total CPU vulnerability mitigation costs for 1st Gen Xeon Scalable, 2nd Gen Xeon Scalable (Cascade Lake), and an AMD EPYC 2P server as well for its Spectre mitigations. As expected given Intel's guidance last week of their latest Xeon processors being mitigated for MDS, indeed, the dual Xeon Platinum 8280 Cascade Lake server reported it was not affected by the MDS mitigations and thus not enabled. So for the MDS tests up first it's just some reference results using a dual Xeon Gold 6138 Skylake server running Ubuntu 19.04 with the Linux 5.0 patched kernel and reference results side-by-side for a separate Xeon E3-1275 v6 server. Read more