> CVE-2016-0777 The irony is palpable. OpenBSD users

>>52418583
Both of them?

>>52418595
this

Fix it:

echo "UseRoaming no" >> /etc/ssh/ssh_config

Well it happens. The thing is it happens to OpenBSD far less frequently than basically every other project.

>>52419451
OpenBSD is an insecure piece of shit. It doesn't even have jails like freebsd has.

>>52419451
This.

>>52418839
Confirmed https://marc.info/?l=openbsd-misc&m=145278077920530&w=2

Also effects Linux users. Patches have already been pushed to the repositories for at least Ubuntu and Debian.

I seriously hope you read the actual CVE and are just baiting for replies.

>connecting to rogue ssh servers
>rogue servers
Literally who would do this

>>52419546
Suppose you run an IT support company
Rogue customer contacts you. Their server has a problem and they want you to give a cost estimate
>OK, can I look at it first?
Sure, here's the login info

>>52419583
You would be safer on windows than you would on openbsd.

>If a connection to an SSH server breaks unexpectedly, and if the SSH server supports roaming as well, the client is able to reconnect to the server and resume the interrupted SSH session. The roaming feature is enabled by default in OpenSSH clients, even though no OpenSSH server version implements the roaming feature.

So if both the client and server use OpenSSH then roaming wouldn't actually work. It's only when the OpenSSH client connects to something other than an OpenSSH server that this "feature" works.

>The OpenSSH server doesn't support roaming, but the OpenSSH client supports it (even though it's not documented) and it's enabled by default.
WTF

>>52419501
Oh hey I missed you.

Where were you for 1 month?

>>52418583
>>52418583
Your keys aren't vulnerable to this if you use ssh-agent.

Use ssh-agent. (And update and disable roaming... but use ssh-agent.)

>>52419501
FreeBSD is actually more vulnerable to this than OpenBSD, because of ASLR

>>52421311
Makes me wonder how the functionality was even added in the first place. It was never documented which means it shouldn't have been allowed through. OpenBSD treats undocumented code as a high level bug because it has a tendency to be abused for things exactly like this(see also: shellshock in bash).

>>52419682
It was never a feature, just experimental code but someone forgot to remove the client side of it.

> Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography.
> The project is also widely known for the developers' insistence on open-source code and quality documentation, uncompromising position on software licensing, and focus on security and code correctness.
ok

>>52422292
What's most strange about this is that it was enabled by default. These weird experiments should be off by default.

>>52422114
FreeBSD wouldn't make a stupid mistake like OpenBSD would.

>>52421311
That's more troubling than the bug itself, imh. Features should never be undocumented. And things should have defaults toward the most secure state (in this case, no roaming).

This bug is kind of interesting, it works similar to heartbleed but in reverse. The client's information gets leaked to the server.

Oddly enough OpenSSH's popularity may have actually helped to mitigate this bug though. OpenSSH's server doesn't support the functionality so the clients information can never be leaked to it. The only way for the bug to work is if the server happened to be using another implementation of SSH that supports roaming.

>>52422638
That's really not much of a factor here: if the endpoint is malicious they'll obviously be using a version that exploits it. What is a factor is the fact that it requires a malicious endpoint, and cannot be MitM'd because the bug can only happen after the host key is checked.

Nothing ever came out of Berkley but potheads and commies.

1. Law enforcement seizes your (v)server
2. Quietly and quickly replaces OpenSSH with a malicious version

3. You connect to your own server.
The host key is still the same. Nothing suspicious.

4. You are now owned

>>52422923
Better: They just take your SSH host key
MITM the connection

No traces on your system

>>52422114
Why not just jail it? OpenBSD doesn't even have any MACs, so you're safer on freebsd.

>>52419546
>Literally who would do this
Just the other day I saw threads on here by some guy posting SSH info to a server. One of his servers, I presume.

So I guess dumb fucks on /g/ would do this.

>>52422964
>dumb fucks on /g/ would do this
Now there, one should be able to assume that the OpenSSH client is secure.
I bet you did not jail every individual SSH connection in the past.

>>52422972
>I bet you did not jail every individual SSH connection in the past.
I did not, but I also did not connect to random SSH servers. Only my own.

So I'm glad I wasn't affected at least. If anything though, it'll make me be more cautious when actually connecting to unknown SSH servers.

>>52422923
Well you could always disable it now that we know it exists. The problem is figuring out how/why it was there to begin with.

>>52422956
i know you're trolling, but jailing wouldn't help, because the ssh key needs to be in the jail in question.

openbsd's security mitigations are designed to keep this kind of bug from being exploitable (still a really dumb bug though)

>>52418583
>>52422088
Reminder: USE SSH-AGENT. Seriously.

>>52422696
Then that begs another argument, who the hell would log on to an untrusted SSH server?

>>52423055
Bet those mitigations wouldn't protect you from the FBI back door

>>52423075
That makes me wonder: how exactly does it leak the keys and where does it look for them?

>>52423108
- Person X rents a server
- Law Enforcement Agency acquires a copy of the SSH host key.
- LEA sets up transparent MITM
- Person X connects to his server
- Notices nothing out of the ordinary
- The LEA now has his private keys

>>52423108
if you don't blindly ignore host key warnings then the risk is low. but if the endpoint is a server you trust, but has itself been compromised in some way (trojan, dumb mistake by administrator...) then your private key is at risk, so you should still enable the workaround/update your ssh.

>>52423108
I think the biggest problem here is with a compromised server. An attacker could take the keys and perhaps other data from one or more administrators and use that for malicious purposes.

>>52423120
the keys are leaked from the memory of the ssh client. if you run ssh-agent, it will perform all the private key operations itself and pass the results to the client, meaning the keys are never exposed to ssh. so ssh-agent prevents this bug (and is a better design in general).

telnet does not have this problems. Why are you not using telnet?

>>52423160
But for a server to be compromised, it requires them to use a server that's not openssh, that's my understanding of it.

I think you'd notice pretty well if someone just randomly swapped your ssh server.

>>52423203
see
>>52423146

Assume you have a (optionally virtual) server in a data center. LEAs can easily get access to it.

>>52423185
http://marc.info/?l=openbsd-tech&m=144744287025692&w=2

>>52423203
Yeah that's what I was thinking too. OpenSSH runs on like 9/10 servers or something so this bug is kinda hard to really take advantage of without a few different things happening, and now that the cover is blown the chances of it being used in the wild are pretty slim.

>>52423185
It's plaintext, nobody but a few MUD groups still use it

>>52423203
>I think you'd notice pretty well if someone just randomly swapped your ssh server.
They can create a fake OpenSSH server that behaves exactly like the real openssh, except it exploits the clients

>>52423160
there is also the risk of connecting to servers you don't have your key on and don't expect them to, but they can scrape your public key off github or some other sites and the ssh client will default to connecting with it without your knowledge. if your key has a passphrase and you see the prompt when you don't expect it, you know something's up, and if you use ssh-agent the key isn't exposed, so you're safe in that case too. but personally i recommend using a different filename for your private key than the default, and only enable it for the sites you want to use it on in .ssh/config. also, use separate private keys for separate sites, and use ssh-agent as additional security measures.

>>52423203
>I think you'd notice pretty well if someone just randomly swapped your ssh server.
you'd be surprised. a lot of compromises aren't immediately visible unless you look carefully.

for example, if you set up a honeypot with a weak root password, it will get compromised pretty quickly and one of the more common script kiddie toolkits contains a quick-and-easy openssh trojan. (setting up a honeypot like this is actually a pretty good learning experience, just make sure it can't initiate connections to your lan or the outside world)

>>52423307
Yeah well that's the thing I was thinking, if swapping openssh on your system is so easy, then you might have other things to worry about.

Security comes in layers.

>>52423344
yeah but the problem here is *you* are vulnerable when connecting to *someone else*'s server. so it's important that your client-side security is up to snuff.

>>52422964
See >>52423307
Pretty sure this was what was going on in that case.

>>52423381
I think he's talking about einchan.

I doubt it was harmful, it was just a test for a python based text board.

Honestly the weirdest thing about this new development is that there was no email sent out security-announce

>>52423619
Sorry, had a stroke, I meant -announce.

>>52423392
No, there was some other clown telling people to connect to his server that same week.

>>52422722
Berkeley. It's Berkeley.
I expected that your auto correct would fix that kind of mistake.

>>52422388
At least OpenBSD doesn't have Randi's Code of Conduct.
I was checking my usenet posts and the freebsd announce group said they have a fucking CoC now.

>>52423243
I miss MUDs. I only use 1 now.

>>52424355
this is why i want theo to live forever

it keeps people like that outside

>>52418595
Kek