News for hackers. Stuff that matters.
Re:Trivial authentication bypass in libssh leaves servers wi... by kevin_b_er on Wednesday October 17, 2018 @04:50PM (#18243683)
From the reading, the "hack" is pretty embarrassing. The server->client message that announces you're authenticated is instead sent client->server and the server just sets its mode to that. Abracadabra, you're logged in!
Re:Trivial authentication bypass in libssh leaves servers wi... by twtw on Thursday October 18, 2018 @02:09AM (#18246277)
> the vulnerability literally works like this:

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

Re:Trivial authentication bypass in libssh leaves servers wi... by wepple on Wednesday October 17, 2018 @06:27PM (#18244379)
The fix implements a basic state machine to ensure protocol state transitions are sane. Prior to this, attacker-supplied data was used in calculating the offset inside an array of callbacks. So you could just tell the server to call into the “auth success” handler.
Re:Trivial authentication bypass in libssh leaves servers wi... by westmeal on Wednesday October 17, 2018 @06:55PM (#18244532)
How on earth did this get past the developer dear god
Re:Trivial authentication bypass in libssh leaves servers wi... by zaroth on Wednesday October 17, 2018 @07:51PM (#18244836)
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.

Re:Trivial authentication bypass in libssh leaves servers wi... by heavenlyblue on Thursday October 18, 2018 @06:49AM (#18247277)
>> 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.

Re:Trivial authentication bypass in libssh leaves servers wi... by lrvick on Thursday October 18, 2018 @12:45PM (#18249861)
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.

Re:Trivial authentication bypass in libssh leaves servers wi... by Sir_Cmpwn on Wednesday October 17, 2018 @07:55PM (#18244856)
libssh is pretty niche. This isn't openssh.
Re:Trivial authentication bypass in libssh leaves servers wi... by akvadrako on Wednesday October 17, 2018 @10:11PM (#18245390)
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.

Re:Trivial authentication bypass in libssh leaves servers wi... by duskwuff on Wednesday October 17, 2018 @10:54PM (#18245561)
The libssh client code is used pretty commonly for that sort of thing.

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

Re:Trivial authentication bypass in libssh leaves servers wi... by kevingadd on Wednesday October 17, 2018 @08:42PM (#18245062)
So "niche" it was used by github, albeit in a configuration that protected them from this
Re:Trivial authentication bypass in libssh leaves servers wi... by throwaway2048 on Wednesday October 17, 2018 @09:14PM (#18245179)
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.

Re:Trivial authentication bypass in libssh leaves servers wi... by lostmsu on Thursday October 18, 2018 @12:59AM (#18246037)
What does git use?
Re:Trivial authentication bypass in libssh leaves servers wi... by dijit on Thursday October 18, 2018 @01:05AM (#18246060)
OpenSSH.
Re:Trivial authentication bypass in libssh leaves servers wi... by raimue on Thursday October 18, 2018 @02:10AM (#18246280)
Actually, just whatever 'ssh' binary is installed. That is not necessarily OpenSSH, but it is the most common choice.
Re:Trivial authentication bypass in libssh leaves servers wi... by informatimago on Thursday October 18, 2018 @04:30AM (#18246845)
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.

Re:Trivial authentication bypass in libssh leaves servers wi... by vbezhenar on Thursday October 18, 2018 @05:12AM (#18246983)
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.
Re:Trivial authentication bypass in libssh leaves servers wi... by XCabbage on Thursday October 18, 2018 @05:50AM (#18247104)
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.
Re:Trivial authentication bypass in libssh leaves servers wi... by empath75 on Thursday October 18, 2018 @07:34AM (#18247428)
Re:Trivial authentication bypass in libssh leaves servers wi... by syn0byte on Thursday October 18, 2018 @11:22AM (#18249043)
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.
Re:Trivial authentication bypass in libssh leaves servers wi... by kevin_b_er on Thursday October 18, 2018 @11:58AM (#18249388)
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.
Re:Trivial authentication bypass in libssh leaves servers wi... by vbezhenar on Thursday October 18, 2018 @06:01AM (#18247141)
Array of callbacks (or long switch which is essentially the same) is a standard method to implement state machine.
Re:Trivial authentication bypass in libssh leaves servers wi... by ernst_klim on Thursday October 18, 2018 @02:59PM (#18251126)
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.
Re:Trivial authentication bypass in libssh leaves servers wi... by kaoD on Thursday October 18, 2018 @07:04AM (#18247325)
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".

Re:Trivial authentication bypass in libssh leaves servers wi... by _pmf_ on Thursday October 18, 2018 @07:04AM (#18247324)
> 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?

Re:Trivial authentication bypass in libssh leaves servers wi... by buboard on Thursday October 18, 2018 @07:06AM (#18247333)
you 're assuming an incompetent programmer here, or just spreading FUD about non managed languages.
Re:Trivial authentication bypass in libssh leaves servers wi... by ploxiln on Wednesday October 17, 2018 @07:05PM (#18244584)
What makes this a bit more understandable is: almost nothing uses libssh server functionality. So most development was only focused on client functionality.

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

Re:Trivial authentication bypass in libssh leaves servers wi... by bigiain on Wednesday October 17, 2018 @07:29PM (#18244722)
Suspicious-me wonders who wrote/committed that code... Is it a "plausibly deniable mistake"?
Re:Trivial authentication bypass in libssh leaves servers wi... by pacaro on Thursday October 18, 2018 @02:26AM (#18246356)
Having implemented security protocols and used state machines to track state, this is a surprisingly easy (if embarrassing) mistake to make. It’s very easy to spend a lot of energy validating the documented state transitions and essentially forget to ban all other transitions.

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”

Re:Trivial authentication bypass in libssh leaves servers wi... by wepple on Wednesday October 17, 2018 @08:41PM (#18245058)
I guess you could say that about absolutely any bug though? This isn’t particularly underhanded, and it’s more of a broad design flaw than a subtle change. If you wanted a “backdoor” you could absolutely do 10x better than this.
Re:Trivial authentication bypass in libssh leaves servers wi... by lozenge on Thursday October 18, 2018 @03:24AM (#18246567)
How could you do 10x better? Because it's a broad design flaw there is no suspicious LOC or suspiciously overcomplicated code needed to hide the backdoor. You have to understand the whole context to notice the bug.
Re:Trivial authentication bypass in libssh leaves servers wi... by wepple on Thursday October 18, 2018 @08:18AM (#18247629)
But it’s still there in plain sight. I’d hazard a guess that this may be the first time a solid code reviewer looked at the code, and spotted it straight away*

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.

Re:Trivial authentication bypass in libssh leaves servers wi... by lrvick on Thursday October 18, 2018 @12:49PM (#18249894)
Make sure the PRNG does not source enough entropy thus dramatically weakening all session keys to a crackable level.

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.

Re:Trivial authentication bypass in libssh leaves servers wi... by foota on Thursday October 18, 2018 @03:49AM (#18246670)
I mean, a backdoor can just be flipping an if somewhere from && to ||, not exactly suspicious if it's mixed in with other stuff.
Re:Trivial authentication bypass in libssh leaves servers wi... by bigiain on Wednesday October 17, 2018 @09:30PM (#18245254)
Pretty sure it's not insane to wonder that about any bugs _that give you a remote authentication bypass_...
Re:Trivial authentication bypass in libssh leaves servers wi... by wepple on Thursday October 18, 2018 @08:25AM (#18247676)
Sure, you can wonder, but when I break it down, it’s either highly unlikely or highly clumsy.

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?

Re:Trivial authentication bypass in libssh leaves servers wi... by ummonk on Wednesday October 17, 2018 @09:24PM (#18245230)
Nope. It is so glaring it could only have been a mistake.
Re:Trivial authentication bypass in libssh leaves servers wi... by reitanqild on Thursday October 18, 2018 @04:25AM (#18246824)
Hehe, which makes it a perfect plausible deniable mistake ;-)
Re:Trivial authentication bypass in libssh leaves servers wi... by flukus on Wednesday October 17, 2018 @07:56PM (#18244864)
This is the code equivalent of being allowed to wander around in a restricted area because you're carrying a clipboard.
Re:Trivial authentication bypass in libssh leaves servers wi... by analogyexpert on Wednesday October 17, 2018 @11:38PM (#18245727)
or like the code equivalent of walking up to a locked door, shouting "let him in!" and being let in