F5: Don't panic but folks can slip past vulnerable firewall servers, thanks to libssh's credentials-optional 'security'

Also: AWS on avoiding state machine slips

Updated Network box maker F5 has shipped some firewall gear that is potentially vulnerable to the libssh authentication-bypass bug.

That means anyone who can reach the at-risk systems over the network or internet can, depending on the configuration, tunnel through to backend infrastructure simply by asking nicely.

The vulnerability, in general, allows an attacker to trick a server into letting her gain access without any valid credentials. When the server expects a SSH2_MSG_USERAUTH_REQUEST message, the hacker sends SSH2_MSG_USERAUTH_SUCCESS, the server swallows that, and it lets the miscreant log in, with no further questions asked.

There was much guffawing in the industry over this programming cockup, because it looks so simple on the face of it. However, as Amazon Web Service's Colm MacCárthaigh noted on Twitter: “State machines are hard!”

Equipment makers that use libssh in their firmware and software needed to review their products to work out which are using the vulnerable library, and to ship patches for gear as necessary. This flaw does not affect OpenSSH, so if you're running classic sshd on your equipment, you're not affected.

F5 has run its eyes over its portfolio, and in announcing the conclusion of its probe, here, said only a handful of boxes in its Big-IP Advanced Firewall Manager range are vulnerable.

Big-IP AFM, branches 12.x, 13.x, and 14.x, all have a vulnerable libssh-powered SSH proxy, Thursday advisory states, and are thus at risk of malicious access if they rely on key authentication. In other words, hackers can potentially slip through the vulnerable SSH proxy, and reach backend systems.

"There is no control plane exposure to this issue. It is only exposed when using the SSH proxy functionality of BIG-IP AFM data plane on a virtual server," the biz cautioned. "A vulnerability was found in libssh's server-side state machine before versions 0.7.6 and 0.8.4. A malicious client could create channels without first performing authentication, resulting in unauthorized access."

The manufacturer hasn't had time to ship a fix yet, but said for now admins can block AFM SSH proxy public key authentication, and send users back to using “password and keyboard interactive authentication” instead. This apparently doesn't trigger the bug because that password-based login uses the non-vulnerable OpenSSH.

State machines are hard

While we're on the topic of libssh, MacCárthaigh's whole thread (starting here) is an interesting digest of how the Amazon cloud juggernaut avoids similar issues.

The problem is that programmers are tempted to spaghetti-fy their message-handling state machine code, making it difficult to spot logic flaws.

MacCárthaig said catching a mistake like the one in libssh needs more than a casual code review: “It's hard to catch these in code reviews because the typical approach is to mix the code that parses messages and the code the proceeds to the next state. For example you might have a parser that handles the first 'Hello' message ... before it even runs some piece of code is probably like 'hey this is a hello message, call that parser!' and then at the end that parser will have a series of branches that are basically 'hey, if I'm in this mode with X enabled, go here next, otherwise go there next'.”

AWS Labs' has its own TLS/SSL implementation, s2n, and at this line of code you can see how it avoids having messages trigger confusing branches.

Your coding tip for the day, from AWS: tabulate the state machine ... Click to embiggen

With everything in a table of function pointers – MacCárthaigh attributes this design to AWS's Doug Lawrence and Signal's Trevor Perrin – you can “fully linearise every possible valid order” of the state machine, and s2n is written so “an out of order message shuts everything down.” ®

Updated to add

After this story was published, F5 updated its advisory with more details, and to stress this applies to BIG-IP AFM (Advanced Firewall Manager) virtual servers with an SSH proxy and key authentication. Here are the vital points:

A vulnerability was found in libssh's server-side state machine before versions 0.7.6 and 0.8.4. A malicious client could create channels without first performing authentication, resulting in unauthorized access. (CVE-2018-10933)

Note: This vulnerability does not allow any login directly to the BIG-IP system. It only applies to BIG-IP AFM SSH virtual servers and only those that use key-based authentication. There is no direct access to the BIG-IP management console. Login to the BIG-IP system is not exposed in any way.

A malicious client can bypass authentication to achieve unauthorized access to a back end server.