> me: "can i log in?"

> server: "no. you need a password."

> me: "hacker voice i'm in"

> server: "login successful. you're in"

https://mobile.twitter.com/FioraAeterna/status/1052294419607...

Contrast this level of insanity to a proposed standard of “developers should be liable for the damage caused by their negligent code”.

Just, wow.

To be fair, at this point I would rather see developers not writing code; rather than writing buggy one.

I had a friend on FB who's just completed a security course and wrote a password generator in Go. The random was seeded from a current date in nanoseconds. The issue is that while no one will probably ever reverse his passwords, but the guy open-sourced his script. How many people will be influenced by that piece of code?

Lawyers have that: if you can't be liable - you're not a lawyer. GTFO.

We need to find out who is teaching this stupidity and make them stop.

It's not really niche - I'd say it's an average popularity library and likely used by a bunch of internal projects.

The libssh server code, on the other hand, is pretty niche.

Just because it has that name dosen't make it some kind of official SSH library that tons of software uses.

While the brain cells of the C programmers are busy handling errors, managing memory, and avoiding buffer overflow, they forget about sound software engineering rules and proper design. While the code of libssh looks cleaner than eg. FreeBSD, there are still quite a number of functions that are bigger than a screen height.

Same bug in python ssh library.

"Whoopsies, I forgot to ban some state transitions" won't happen if all you're writing is a state machine spec, and not a state machine spec and its ad-hoc implementation.

Don't roll your own crypto? Extend it to "don't roll your own low-level constructs".

You seem to be a very smart guy; will making my font smaller so my functions are shorter improve my code?

(The only notable exception, github.com backends, were not using the auth logic code in question, so again just not used and not given attention...)

For me this is much less “OMG how could they be so careless” and much more “There but for the grace of a diligent set of testers go I”

If you wanted 10x better, you could throw in some code that exhibits undefined (but known on major compilers) behavior, or super subtle C issues. Even a simple if statement in C forces all kinds of wonderful promotions and type conversions which can truncate, wrap, and drastically change values in ways that even most C developers aren’t aware.

I encourage folks to go check out the “underhanded C contest” before suggesting that this bug is a backdoor.

*The person who found this, Peter, is indeed insanely good.

Or do like WEP and recycle your one time pads. Lots of subtle design flaws one can introduce that generally get spotted in blackbox testing, and not in code.

If I were to put a backdoor into this code, I’d want the following properties:

- tricky to spot in code review

- virtually undiscoverable via current best-of-breed fuzzing

- tricky to spot in network captures or any type of IDS

This bug passes #2 (unless you’ve got a state-aware network fuzzer and panic() in the right places), but fails on the other two.

But who knows, maybe this was a low-investment effort and it paid off for some time, with a trivial-to-exploit (IE no mem corruption) bug they knew would eventually be retired?

    $ apt-cache rdepends libssh-4
    libssh-4
    Reverse Depends:
      libpam-x2go
      yafc
      x2goclient
      tmate
      remmina-plugin-nx
      remmina
      openvas-nasl
      libopenvas9
      libssh-dev
      cockpit-bridge
      kio-extras
      hydra

https://twitter.com/GitHubSecurity/status/105231733337972326...

[1] http://brewformulas.org/Libssh

According to the brew uses command the possible dependents are ffmpeg, [email protected], hydra, sshtrix, tmate, wireshark, and yafc. I say possible because some of those can optionally depend upon libssh, but the user has to opt-in to building with libssh support.

That sounds reassuring. It's not as if hacking some random IoT device is going to win the jackpot.

Oh wait, it totally can: https://www.washingtonpost.com/news/innovations/wp/2017/07/2...

It's unlikely that ssh - a protocol that powers large swaths of software, has such an error, but always good to hear from the experts that this is indeed a coding error.

(Unless your server uses the relatively uncommon libssh on your server. If you use openssl you're not vulnerable. Github's not vulnerable either.)

First we had the YouTube outage and a bit later, this issue appeared...