Hacker News Reader

Comment by westmeal | Hacker News Reader

How on earth did this get past the developer dear god

This is the state of libssh. As if it wasn’t already, “many eyeballs theory” is turning over in it’s grave.

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

Just, wow.

libssh is pretty niche. This isn't openssh.

So "niche" it was used by github, albeit in a configuration that protected them from this

libssh is used because openssh isn't suited to be used as a library. So it's one of the most popular ways to automate the most popular remote shell protocol.

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 client code is used pretty commonly for that sort of thing.

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

Except for github, its unlikely you use any software that uses libssh.

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

What does git use?

OpenSSH.

Actually, just whatever 'ssh' binary is installed. That is not necessarily OpenSSH, but it is the most common choice.

>> developers should be liable for the damage caused by their negligent code

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.

I found that same exact issue in Terraform Go code where it generates passwords for AWS IAM users: https://www.cvedetails.com/cve/CVE-2018-9057/

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

Easy: it's implemented in C.

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.

I don't see how different language would protect you from this kind of vulnerability. Array of callbacks looks identical everywhere. Rust or Java would protect from out-of-bounds memory access (and that is a very good thing in that case), but this particular bug would be present.

You're assuming there would even be an array of callbacks if the code had been written in a different language, rather than the other language offering some nicer abstraction that eliminated the array. Having not seen the code, I can't be sure of this, but I know that, for instance, I rarely need to write array index arithmetic in the languages I usually work with (Python, JavaScript) whereas on the occasions I've dabbled with C such arithmetic came up constantly. If I introduced a nasty bug in some C code due to an array arithmetic error, arguing "Python wouldn't be any better because it doesn't do anything to make manually writing array index manipulations easier" would be missing the point.

Array of callbacks (or long switch which is essentially the same) is a standard method to implement state machine.

And that's why you should use a thoroughly tested implementation instead of implementing a bug-ridden ad-hoc square wheel.

"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 can use type system to ensure that there are no wrong state transitions, e.g. you could transit to another state only if you are authorized.

https://github.com/paramiko/paramiko/issues/1283

Same bug in python ssh library.

A perfect example of why "use safe languages! C is the root of all RCE!" makes me immediately weary of a developer. Had the original poster been the author of such a library, he wouldn't have been motivated to spent much or any time investigating his implementation because he used a safe language.

Same issue and might even explain it better: They took the client-side implementation and effective state machine, flipped it around, and called it good.

> 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.

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

you 're assuming an incompetent programmer here, or just spreading FUD about non managed languages.

Reply on news.ycombinator.com