Syncplify Server! is also *NOT* vulnerable to CVE-2024-6409

Following up to our previous post in which we informed our user-base that Syncplify Server! is not affected by CVE-2028-6387, today we have the pleasure to share with you that Syncplify Server! is also completely unaffected by the newly discovered CVE-2024-6409.

CVE-2024-6409 is a signal handler race condition vulnerability in the OpenSSH server (sshd) that occurs when a client fails to authenticate within the LoginGraceTime, potentially leading to information disclosure, denial of service, or unauthorized access.

Syncplify Server!, by virtue of not being based on OpenSSH, does not have such vulnerability.

Syncplify Server! is *NOT* vulnerable to CVE-2024-6387

OpenSSH, a widely used secure shell-protocol handling software, has recently disclosed a critical vulnerability (CVE-2024-6387) affecting its server component. This flaw could potentially allow unauthenticated remote code execution with root privileges on glibc-based Linux systems. The vulnerability, present in OpenSSH versions 8.5p1 through 9.7p1, is a signal handler race condition that affects the default configuration of sshd.

Qualys researchers have identified over 14 million potentially vulnerable OpenSSH server instances exposed to the internet[1]. While exploitation requires continuous connections for 6-8 hours under lab conditions, the potential impact is severe, allowing full system compromise and takeover.

It’s important to note that Syncplify Server! is not affected by this vulnerability. Unlike many other SSH servers, Syncplify Server! is not based on OpenSSH in any way. This independent implementation ensures that Syncplify Server! users are protected from vulnerabilities specific to OpenSSH, including CVE-2024-6387.

For those using OpenSSH, it’s crucial to apply the latest patches promptly. Additionally, limiting SSH access through network-based controls and enforcing network segmentation can help mitigate potential risks.

Why PGP is an extremely bad choice for a file server’s at-rest encryption, and how to do it right

Pretty Good Privacy (PGP and all of its variants) is a well-known encryption program that provides cryptographic privacy and authentication for data communication. While PGP is excellent for securing emails and individual files, using it for at-rest file encryption on a file server is not advisable. This article explains why PGP is unsuitable for this purpose and why a streaming encryption method is a better alternative.

Read More

The VirusTotal false-positive problem seems to be resolved

Not too long ago we reported that VirusTotal was reporting that some of its antivirus (1 or 2) were erroneously identifying our software as malware, which was clearly a mistake and a false-positive.

Since then, we embarked in the endeavor to ditch nssm (a third party tool, not developed by Syncplify) which was identified as the root cause of the issue.

Today we are happy to report that our efforts seem to have paid off: new scans on VirusTotal show our software now 100% clean and virus-free.

Syncplify Server! has no known vulnerabilities in the NIST NVD

In the aftermath of the already infamous MOVEit hack, which is only the most recent one in a long list of competitors exposing their customers data, we would like to take this opportunity to underscore a few important facts about Syncplify Server!

In fact, Syncplify Server! is the only enterprise-grade, commercial SFTP server on the market that has never been hacked, and has literally zero vulnerabilities listed in the NIST NVD, which is the National Vulnerability Database owned and operated by the National Institute of Standards and Technology.

But hey, it’s easy to toss around such a bold claim without proof, right? That’s why we’re not asking you to take our word for it. This is something you can verify yourself.

How? Here you go:

  • Point your browser to the NIST NVD website search page
  • Type in Syncplify Server! or even just Syncplify, and verify that no vulnerabilities are found (here’s a direct link if you don’t want to type)
  • Now go back to the NIST NVD search page and try to search for any of our competitors; chances are anyone you search for will have a list of known vulnerabilities hackers can, have, and will exploit to gain access to your data

This is not a random result; where many of our competitors have chosen to give in to flashy UIs and unreasonable support for old/legacy algorithms now obsolete and proven weak, we have never been afraid to lead our customers onto a path of true security without trade-offs.

Stay safe, choose unrelenting security, use Syncplify.

A much improved Admin UX is coming…

First of all, let’s clarify: UX is not UI.

While UI refers to the User Interface (what a human-machine interface looks like), UX refers to the User eXperience (how a human-machine interface behaves).

With Syncplify Server! V6 we think we’ve done a pretty good job at UI… but there are things in our UX that could be improved. For that reason, one of the v6.x upcoming releases will be focused on UX, and on ways to improve and make it easier for an administrator to manage our software.

In order to do that, we had to start with identifying what could be done better, and we have indeed identified a few areas, namely:


The current strategy is: validate everything, and report all mistakes in a technical way that overlaps with the fields our REST API manages. This is probably still the best for those very few people who know the inner workings of our REST API inside out. But let’s be honest, how many of them are there? We cannot expect our customers to have this type of knowledge, they didn’t design our software, and they don’t only have our software to manage in their daily routine.

So, we need to go from: validate –> report everything (in tech notation)

To: sanitize –> validate –> report if needed (in plain English)

Most things can actually be sanitized. For example, let’s say you created a Virtual Folder for a User, but forgot that all virtual folders must be POSIX-root-based (i.e. begin with a forward-slash). We can simply add that leading forward-slash for you, and not even bother reporting a validation error.

Validation errors will still be reported (but in plain English) only when there is no unambiguous way to automatically sanitize the contents of a field that were filled-in wrong by the administrator.

As a result, our Admin interface will produce a lot fewer error messages (as many mistakes will be automatically sanitized) and the few errors that will be displayed to the administrator will be in plain English, thus far easier to understand and know what to change to fix them.

Reduce the “nulls” to check via REST API

Most modern OpenAPI-compliant JavaScript frameworks are not designed to automatically generate the logic to check for null conditions in every return value. The result is that this logic often has to be written-in by hand by the developer, which leads to bugs and errors.

We’re working hard to ensure that our REST API always returns a predictable set of non-null fields for every call. This will make the UI-side logic abundantly easier and cleaner to design and develop.

Tackling memory leaks… the Go way

We recently discovered two small memory leaks in our worker process, one that affected only the ARM architecture build, and one that affected all builds regardless of the CPU architecture (but only if you use scripting and event-handling). Although both of them were very small and limited in scope, over long periods of time they could lead to the unwanted allocation of a significant part of your system memory.

As many of you know, Go has a pretty nifty garbage-collector, but that doesn’t mean that all memory issues are magically prevented. Programmers still have to be clever with allocations and references.

Long story short, we spent the last week delving in pprof to hunt down, identify, and resolve these two memory leaks, and here’s the result:

As you can see, after our fixes now the worker process uses a stable amount of memory (~120 MB) and CPU (~0.7%) under constant load (~750 Mbps sustained transfer rate from 3 concurrent clients). The chart above was acquired over an observation period of 24 hours under stress-test conditions.

These fixes will be incorporated into version 6.0.22.

Invoices are now in your Customer UI

As many of you know, starting with the release of Syncplify Server! version 6 we have also introduced the Syncplify Customer Center Portal, which is a web UI for customers to manage their own licenses, maintenance/support subscriptions, orders, … and now also invoices!

Yes, invoices are now inside of your Customer UI:

To access an invoice, log into your Syncplify Customer Center Portal and go to the Orders page. From there, locate the order you want an invoice for, and click on the little blue icon that looks like a document next to the date-time and order ID.

This will display the invoice in your browser, from there you can print it or export it as a PDF using your browser’s built-in printing functions.

New support/ticketing system coming soon!

For several years we’ve been using Freshdesk to provide an online support/ticketing system to our customers. It’s a good and feature-rich solution, but it’s not deeply integrated with all of the other subsystems in our pipeline.

To improve on that, and to provide our customers with better, more tailor-made, more accurate support, we will soon switch to a more tightly integrated support/ticketing system.

When the new support/ticketing system is deployed, all support requests will need to be initiated from within your Syncplify Customer Center portal. Your information will be automatically injected into the ticket, so that you will have to write less, and we will have more information up front to help you better and more accurately.

Yet another step towards providing the best customer service we possibly can. 🙂

So, what is this SyngoDB everyone is asking us about?

Previous versions of our flagship software, Syncplify Server!, did use MongoDB to store their configuration and metadata. Over the years, though, we had to accept that MongoDB is not always reliable, especially on Windows, when certain circumstances arise. This becomes painfully obvious when an unclean shutdown of the operating system occurs, and MongoDB fails to start when the machine reboots, until you manually clean up its lock file and/or repair its data files. It’s also not uncommon enough to find MongoDB suddenly unable to accept client connections for no apparent reason.

This was becoming more than just an annoyance. It was starting to affect our customers. So, mainly but not only for this reason, we embarked in the gigantic endeavor of developing our own backend DB.

First of all, the name. SyngoDB is not named after MongoDB, it’s actually the composition-abbreviation of three concepts: “Syn” for Syncplify, “go” because it’s written in Go, and “DB” because (drum-roll) it’s a DB.

So, what are the similarities and the differences between MongoDB and SyngoDB?

Let’s start with the similarities, because there are very few: both of them are schema-less, document-oriented, NoSQL databases. And that’s pretty much all they have in common.

The differences on the other hand, well, where do we even start? We’ll cover just a few of the most significant ones.

First and foremost, SyngoDB doesn’t have any of the powerful data manipulation and analytics functions that are a core value of MongoDB. Nor does it have MongoDB’s massive horizontal multi-node (replica-set) scalability. That wasn’t the goal in the first place.

SyngoDB, essentially and by design, had to achieve only three goals:

  • Highest reliability: it had to be always-available, never crash, and be consistent and reliable even across unclean reboot cycles; even if someone rips the power cable from the wall, SyngoDB must be able to run without issues and without data loss or corruption at the next OS restart.
  • Vertical scalability without compromising performance: your local data set may grow to petabytes without severely affecting operation time, especially insertion and querying time.
  • Built-in security out of the box: certificate-based authorization and optional built-in strong data encryption engine are part of SyngoDB’s core design.

We’re happy to report that SyngoDB has met, and even exceeded, our expectations. All of the design goals were achieved, and it’s now the backbone of our flagship product Syncplify Server!