Category: wolfSSH

The latest version of wolfSSH, 1.4.19, brings improvements, stability fixes and an additional feature! DH Group 14 with SHA-256 Key Exchange (KEX) support was added in with this release.

Along with this new feature some of the improvements that were added are: CI testing, macro guards around TTY modes, use of wolfSSL kyber implementation, and an update to the Espressif example. Among the fixes there were additions for gracefully handling non-existent directories with SFTP and handling of re-key/window full cases with wolfSSHd. For a full list of changes see the bundled ChangeLog.md

Contact facts@wolfSSL.com for more information regarding wolfSSL and wolfSSH.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Did you know wolfSSH can use X.509 certificates in place of SSH public keys? wolfSSH supports RFC 6187, “X.509v3 Certificates for Secure Shell Authentication”. This uses wolfSSL’s certificate management for TLS, so the certificates may be checked against CRLs and OCSP.

wolfSSH has been used in applications as a server where it needed to validate some FPKI (Federal Public Key Infrastructure) profiles. It is used with clients that authenticate the user’s credentials accessed via a card reader. wolfSSH’s client can be given an X.509 certificate to authenticate the user with the server.

If you have questions about wolfSSH, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Recently, Qualys found an exploit in OpenSSH’s sshd server application that they named regreSSHion. This exploit lets attackers run arbitrary code by exploiting a race condition in a signal handler.

wolfSSH is not a port or fork of OpenSSH. It is written from scratch by wolfSSL Inc. While wolfSSHd is using the same alarm signal to time out users, our signal handler only sets a flag. OpenSSH’s handler, on the other hand, called unsafe functions.

How wolfSSH Avoids This Vulnerability

wolfSSH’s signal handling is designed to be safer due to:

1. Minimalist Signal Handling: Our handler only sets a flag, reducing race condition risks.
2. Async-Signal Safe Operations: We ensure all operations within the signal handler are safe.
3. Independent Implementation: wolfSSH is a complete rewrite, avoiding inherited vulnerabilities.

Conclusion

The regreSSHion exploit in OpenSSH underscores the need for safe signal handling. wolfSSH’s simple and secure approach to signal handling avoids the vulnerabilities found in OpenSSH, making it a safer choice for SSH server applications.

If you have any questions or want to talk about wolfSSH, please feel free to send us an email at facts@wolfssl.com or sales@wolfssl.com, or call us at +1 425 245 8247.

Download wolfSSL Now

It is Christmas in July! The summer release of wolfSSH is here, version 1.4.18!

Version 1.4.18 brings with it bug fixes, new features, and some enhancements as well! New features in this release include new algorithms and a memory configuration option.

We also have a nice round of enhancements which range from channel setup callbacks, better testing, improved portability, and more!

New Features

• wolfSSL style static memory pool allocation support.
• Ed25519 public key support.
• Banner option for wolfSSHd configuration.
• Non-blocking socket support to the example SCP client.

Improvements

• Documentation updates.
• Update the Zephyr test action.
• Add a no-filesystem build to the Zephyr port.
• Update the macOS test action.
• Refactor certificate processing. Only verify certificates when a signature is present.
• Update the Kyber test action.
• Refactor the Curve25519 Key Agreement support.
• Update the STM32Cube Pack.
• Increase the memory that Zephyr uses for a heap for testing.
• Add a macro wrapper to replace the ReadDir function.
• Add callback hook for keying completion.
• Add function to return strings for the names of algorithms.
• Add asynchronous server side user authentication.
• Add ssh-rsa (SHA-1) to the default user auth algorithm list when sha1-soft-disable is disabled.
• Update Espressif examples using Managed Components.
• Add SCP test case.
• Refactor RSA sign and verify.
• Refresh the example echoserver with updates from wolfSSHd.
• Add callback hooks for most channel messages including open, close, success, fail, and requests.
• Reduce the number of memory allocations SCP makes.
• Improve wolfSSHd’s behavior on closing a connection. It closes channels and waits for the peer to close the channels.

Fixes

• Refactor wolfSSHd service support for Windows to fix PowerShell Write-Progress.
• Fix partial success case with public key user authentication.
• Fix the build guards with respect to cannedKeyAlgoNames.
• Error if unable to open the local file when doing a SCP send.
• Fix some IPv6 related build issues.
• Add better checks for SCP error returns for closed channels.
• In the example SCP client, move the public key check context after the WOLFSSH object is created.
• Fix error reporting for wolfSSH_SFTP_STAT.
• In the example SCP client, fix error code checking on shutdown.
• Change return from wolfSSH_shutdown() to WS_CHANNEL_CLOSED.
• Fix SFTP symlink handling.
• Fix variable initialization warnings for Zephyr builds.
• Fix wolfSSHd case of non-console output handles.
• Fix testsuite for single threaded builds. Add single threaded test action.
• Fix wolfSSHd shutting down on fcntl() failure.
• Fix wolfSSHd on Windows handling virtual terminal sequences using exec commands.
• Fix possible null dereference when matching MAC algos during key exchange.

Visit our download page to download the release bundle, or clone it from GitHub. Feel free to email us at facts@wolfssl.com or support@wolfssl.com or call us at +1 425 245 8247 with any questions about the wolfSSH embedded SSH library or other products.

Download wolfSSL Now

Affected Users:

Anyone using wolfSSH server versions prior to release v1.4.17.

Summary:

It is possible for a malicious client to bypass user authentication when logging into a wolfSSH server. The wolfSSH server was not rigorous about checking the current state of the key exchange when handling channel open messages.

wolfSSH’s example echoserver and the wolfSSHd server will not allow one to obtain a shell as root or any other user. By skipping the user authentication, the user’s login name won’t be set, and the server will error out because it cannot find the user’s home directory. At this point, the server has allocated some memory resources for a channel, but then releases them immediately.

Due to the way wolfSSH server handles incoming connections, forwarding requires an active shell connection to work. If user authentication is skipped, the server will terminate the connection with an error before allowing any forwarding.

This issue with message processing is in the library. The application using the library has the responsibility of checking that the username is set and checking the credentials. One could have an application that gives access to the system without checking the user authentication.

Recommendation:

Prompt update to wolfSSH v1.4.17. This version rejects out-of-sequence channel messages before user authentication has completed and rejects user authentication messages after user authentication is complete.

Additional Details:

The patch fixing this issue can be viewed at the links:

• https://github.com/wolfSSL/wolfssh/pull/670
• https://github.com/wolfSSL/wolfssh/pull/671

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSH is following the industry common practice of removing SHA-1 as a default configuration option. SHA-1 has been considered broken for a while now and shouldn’t be used for security purposes. [RFC 8332](https://datatracker.ietf.org/doc/html/rfc8332) recognizes this for the SSH protocol and offers new RSA-based algorithms for signing authentication messages.

In the wolfSSH v1.4.15 release, we were heavy-handed when it came to disabling SHA-1 and removed it from the compile using a preprocessor flag. There was an option to add it back in, but its use wasn’t clear. This was a mistake.

For wolfSSH v1.4.17, we restored SHA-1 to the library, but it is “soft-disabled.” This means it is not offered in the default list of algorithms available during key exchange. One may add the algorithm “ssh-rsa” back as an available algorithm, along with DHE using SHA-1, at runtime. To support this, there is now a set of functions to set the algorithm lists used during key exchange and to poll the library on which algorithms are enabled in the build. Please see the wolfSSH manual section 13 for more information on the [Key Exchange Algorithm Configuration].

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSH has several useful features that were introduced in this most recent release.

We have made wolfSSH builds for various systems better and easier. This includes changes to configuration scripts and modifying code to work with various compiler quirks. We’ve made building wolfSSH for Nucleus, QNX, Windows, and ESP32 builds better. And we’ve fixed an issue working with the Zephyr file system involving redundant file mode bits.

We’ve improved testing of wolfSSH. There are new scripts to test details of the wolfSSHd server. Also, the Zephyr SFTP test uses a different file for the transfer test. The new file used is available in all situations.

The terminal support with shells is improved. The terminal size bounds were not getting set correctly in all builds, and that is now fixed. The shell environment now sets up things like the `$SHELL` variable and the `$0` value as expected. We fixed a potential memory leak when receiving the terminal modes from the peer. For Windows builds, the shell environment has its own quirks and we are working with those better.

wolfSSH has been able to run commands and scripts over a connection for a while. We’ve recently improved this behavior with wolfSSHd and use the I/O pipes better. The return code from the script or command is captured and returned to the peer as expected.

Missed with the SHA-1 disable and reenable was a bug with verifying RSA signatures. Disabling SHA-1, the testing used ECDSA authentication instead. This bug is now fixed.

Finally, we try to keep wolfSSH tunable for size. If you don’t want a feature, you can easily leave it out of a build. This is good for embedded targets with constraints on code and memory usage. A few of the guard checks were incorrect and have been fixed.

In all, we think this makes wolfSSH a better product. If you have any questions or are wondering about wolfSSH on other platforms, please email support@wolfSSL.com. Thank you!

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSH now has Curve25519 support as of version 1.4.17! Go ahead and download it today. You’ll need both wolfSSL and wolfSSH. Here are instructions to get this up and running to try out yourself.

Compile wolfSSL with support for wolfSSH and Curve25519.

$ cd wolfssl
$ ./configure --enable-wolfssh --enable-curve25519
$ make all
$ sudo make install
$ sudo ldconfig

After building and installing wolfSSL, you can simply configure wolfSSH with no options and build:

$ cd wolfssh
$ ./configure
$ make all

The wolfSSH client and server will automatically negotiate the use of Curve25519 for key exchange.

Run the server:

$ ./examples/echoserver/echoserver -f

In a separate terminal, run the client: 


$ ./examples/client/client -u jill -P upthehill

Congratulations! You’ve just made an SSH connection where the key exchange was done with Curve25519.

Our next natural step is to add support for hybrid Curve25519 and Kyber/ML-KEM at NIST security level 1. Want to see this work at a higher priority and accelerated? Let our management know. Simply send a message saying you support our efforts in developing this implementation to facts@wolfSSL.com.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

The wolfSSH 1.4.15 release includes brand new support for the Zephyr RTOS. wolfSSH is a lightweight SSH library designed for embedded systems. It is a performant and low footprint solution, making it an ideal choice for IoT devices. The Zephyr RTOS is an open-source, scalable, and flexible real-time operating system tailored for resource-constrained devices. Its modular architecture and broad hardware support make it a popular choice for various embedded applications.

wolfSSH is introduced as a new module in the Zephyr ecosystem. Necessary steps to get started include setting up wolfSSH as a Zephyr module, modifying the west manifest, and finally building your project. In-depth instructions to set up wolfSSH with Zephyr can be found at the wolfSSH Github.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now