OpenSSH sshd – memory leak

http://pastebin.com/raw.php?i=gjkivAf3

by jvehent • 12 years ago

116 42 12 years ago

pastebin.com

ricksta• 12 years ago

20 BTC seem quite cheap for these kind of bug no?

MichaelGG• 12 years ago

But a good price to scam people; not too expensive, so it'll get a few bites.

reedloden• 12 years ago

Folks on oss-security are skeptical about this (and rightly so, since posts like this have been showing up regularly since heartbleed). http://seclists.org/oss-sec/2014/q2/246

wfn• 12 years ago

  | 236kb of exploit source, must be written for enterprise.

ShaneCurran• 12 years ago

Maybe a crowdfund could be set up to gather together the 20 BTC and then open source it or distribute it to the backers

conductor• 12 years ago

It is probably a scam. They haven't provided any real evidence, only an imaginary PoC.

stormbrew3• 12 years ago

Someone could put 20btc on a machine that only exposes ssh and see if they can get in. Then they'd earn it. :P

icambron• 12 years ago

Could you image being the person who spends 20 BTC for an exploit without any evidence that it's real? "But look, there's console output right there!"

140am2• 12 years ago

a 236 kbyte C exploit code example - you defiantly get 'something' for your 20 BTC..

sp332• 12 years ago

Hey all that ANSI art takes a lot of space :p

Zancarius• 12 years ago

defiantly

I realize that was (probably?) a typo, but it's oddly amusing and strangely fitting.

140am2• 12 years ago

definitely fitting :P

phaer• 12 years ago

Probably because of all the documentation and unit tests ;)

mrbill• 12 years ago

It includes the pirated PDFs the "authors" used to learn C.

roeme• 12 years ago

It seems that once again, running services on non-standard ports where possible might have payed off.

Off to patching. Or rather, wait for eventual patches.

But you know what interests me the most about the whole thing? Theo de Raadts reaction. You know, after bashing OpenSSL heavily. And hinting at a SSH hole in FreeBSD, known to him but deliberately undisclosed.

Judging from the announcement's tested systems, it might be the exact hole he referred to. "...many more" sounds like they'd like to claim more successfully exploited platforms, but can't since they do something different, and the de facto reference implementation of OpenSSH on OpenBSD is suspiciously absent.

akerl_3• 12 years ago

I'm curious how running services on non-standard ports has an impact on anything like this.

This specific threat appears to be a hoax, but even if it wasn't, an attacker just portscans you and then targets your SSH service. Moving the port doesn't even buy you a few minutes.

marksamman2• 12 years ago

It helps against a masscan on the standard port. If the attacker is specifically targeting you or has the resources to masscan every port, then I agree that it's useless.

fleitz• 12 years ago

It doesn't. If anything change the line SSH emits and how it identifies itself. You want the automated tools to send the wrong exploits. If you can make your OpenBSD machine look like a Windows server running a commercial SSH server you're going to deflect a lot of attacks / attract the wrong kind of attacks.

The proper way to do something like this is generally three fold:

1) Trusted host (OpenBSD?) that runs only SSHD, and only allows users to run ssh from the shell. Log the fuck out of this server, and likely port mirror and record raw packet logs. Since no one should be talking to this machine except for SSH simply drop everything from those IPs when you recieve something other than SSH.

2) Ensure all other servers only accept SSH connections from the trusted host.

3) Restrict unconditional access to the trusted host to a list of trusted IPs, turn off all unused SSH options, you probably don't need that many if all it is doing is proxying connections to other hosts. Now that you have a list of trusted IPs you can be very aggressive in firewalling malicious connections from non-trusted IPs. (It's nice to have some way to getting back into your infrastructure when you're on vacation, etc)

Generally the best thing for security is a default deny rule. Chances are your database server doesn't really need to connect to the internet. Chances are your webservers only require inbound connections on ports 80 and 443, and only make outbound connections to your database & log server.

Fuckery with port numbers is generally a waste of time. The best thing for an attacker to do is extensive slow scanning in advance, then when an exploit comes out it's a quick lookup in a DB for likely vulnerable systems.

neoCrimeLabs• 12 years ago

What interests me is Theo de Raadt's reaction hearing about someone running a OpenSSH on a non-standard port paying off against a potential exploit.

tlongren• 12 years ago

Seems legit.

pera3• 12 years ago

https://blockchain.info/address/14PEL35LQf81oCvSPurhoyTSvosv...

Total Received 0 BTC

nullc2• 12 years ago

Well duh, ... of course if someone sent 20 BTC there you can bet they'd be flooded with emails of the form "my txid is {txid}, send it over to me".

This is one of multiple reasons why the Bitcoin system wasn't designed for people to reuse addresses.

pera3• 12 years ago

uh? you can sign the message to prove your identity

victormx• 12 years ago

Now two transactions of 0.0003 BTC

jwcrux• 12 years ago

This is garbage. Probably the same guys behind this other one recently (http://pastebin.com/qPxR9BRv).

One of the members of the full disclosure mailing list outed these guys here: http://seclists.org/fulldisclosure/2014/Apr/292

Only this time - they got smart:

Please note that we are busy and we will NOT answer to questions, social engineering tentatives or dumb comments.

AKA

Please note that we will not in any way prove this is legit (not falling for that again!)

jacquesm3• 12 years ago

Anybody that pays for this deserves exactly what they get. I also still have a bunch of lightly used one-time pads for sale...

__david__• 12 years ago

This vulnerability exploits a bad check on the network layer of the sshd server that we trigger to retrieve all children processes memory sections…

That's not making sense to me. I really thought that, and correct me if I'm wrong here, parents never had access to child process memory and that you had to go out of your way to do even limited memory sharing between processes.

stormbrew3• 12 years ago

If the parent process were deliberately sharing memory pages with the child it might be possible to get those pages (or, if the child process executes code from them, to do pretty much anything with it). These seem like pretty novice mistakes for the openssh team to make, though.

A more important issue is that the window in which your connection is actually being managed by the parent process of all sshd instances must be vanishingly small. More likely you'd be looking to access memory while the ssh process was still privileged. I'm still not sure what that'd get you, though.

djmdjm3• 12 years ago

So, there are usually four sshd processes involved in handling a connection:

1 - master sshd, listens for incoming connections. When it accepts one it forks and executes a new sshd to handle it. It executes a new sshd to ensure that each one gets different runtime randomisations (ASLR mappings, PRNG state, etc.)

2 - privileged sshd. This is the result of the fork+exec of (1) above. It does absolutely no packet processing and exists only to perform options that require privilege or access to sensitive data (e.g. the host keys). As soon as it starts, it forks an unprivileged process.

3 - pre-auth sshd. This is the first unprivileged process forked by #2. It is responsible for packet processing and most crypto (except that which touches sensitive data). This process runs in chroot, In recent OpenSSH versions, this process is sandboxed using systrace, seccomp-bpf, OS X seatbelt or (if none of these are supported) restrictive rlimits. It exits as soon as the user is authenticated.

4 - post-auth sshd. This is forked from the #2 process after authentication completes. It runs with the privileges of the user and handles network packets and crypto much like #3.

Most of this (except the re-exec and sandboxing) is described in Niels Provos' original privsep paper: http://www.citi.umich.edu/u/provos/ssh/privsep.html

jacquesm3• 12 years ago

Well, technically after a fork you have access to all the childs memory pages, they're identical to your own (that is, until any writes happen, usually that's when copies are made and each process ends up with a different version of that page). But then the 'exec' bit happens and it's a completely new process. Any access to memory of the child process thereafter would be through some deliberate mechanism unless there is a significant issue with the underlying operating systems ability to keep processes where they belong (separated).

The whole idea is that processes have separate memory spaces, debuggers, shared memory applications and IPC implementation work hard to do this on purpose.

If sshd really had unfettered access to its child processes then so would every other process that spawns some new process, init comes to mind as a nice candidate, cron as another (though neither exposes network sockets).

Of course, a process running as 'root' has technically access to all the other processes memory through (on Linux) /dev/mem (phys) and /dev/kmem (virt) but you have to open it first and as far as I'm aware sshd does not do this.

nitrogen• 12 years ago

...(though neither exposes network sockets).

I'm not sure, but that may no longer be true with systemd.

djmdjm3• 12 years ago

So:

1) this is probably bullshit. cf. http://seclists.org/oss-sec/2014/q2/247

2) from the memory dump, it looks like it is post-authentication so the impact would be quite limited (stealing the password hash of an account one already has access to)

3) we're (OpenSSH) going to check it out anyway

jacquesm3• 12 years ago

Kudos for playing it safe, this does open you up to the possibility of being DOS'd with fake vulnerabilities whilst exploiting a real one.

namuol• 12 years ago

236k for some exploit code. Okay.

djmdjm3• 12 years ago

IMO this isn't implausible - if I were making a single-file exploit then I'd probably just include most of OpenSSH in that single file.

OpenSSH sshd – memory leak

Related Stories