
OpenSSH sshd – memory leak - jvehent
http://pastebin.com/raw.php?i=gjkivAf3
======
jwcrux
This is garbage. Probably the same guys behind this other one recently
([http://pastebin.com/qPxR9BRv](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](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!)

------
djmdjm
So:

1) this is probably bullshit. cf. [http://seclists.org/oss-
sec/2014/q2/247](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

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

------
reedloden
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](http://seclists.org/oss-
sec/2014/q2/246)

~~~
wfn

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

------
icambron
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_!"

------
pera
[https://blockchain.info/address/14PEL35LQf81oCvSPurhoyTSvosv...](https://blockchain.info/address/14PEL35LQf81oCvSPurhoyTSvosvtQT7u3)

> Total Received 0 BTC

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

~~~
pera
uh? you can sign the message to prove your identity

~~~
nullc
Maybe you can, not always.

Did you issue the payment from your account a service? Did you issue it from a
hardware wallet? Did you, by chance, happen to decide that you want to use an
anonymization tool when buying your exploit? Perhaps, you have a strict
retention policy and destroy keys which are no longer used and can't sign for
it anymore…

~~~
pera
If you are paying 20btc for a zero day exploit I suppose you know what you are
doing. Either way everything you had mentioned are not deficiencies of Bitcoin
per se.

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

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

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

~~~
jacquesm
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
_...(though neither exposes network sockets)._

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

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

~~~
Zancarius
> defiantly

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

~~~
140am
definitely fitting :P

------
ShaneCurran
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
It is probably a scam. They haven't provided any real evidence, only an
imaginary PoC.

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

------
namuol
236k for some exploit code. Okay.

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

------
tlongren
Seems legit.

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

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

~~~
akerl_
[https://zmap.io/](https://zmap.io/) /
[https://github.com/zmap/zmap](https://github.com/zmap/zmap)

It's pretty crazy to think about, but a portscan of the IPv4 space isn't that
hard to do in practice:

"On a typical desktop computer with a gigabit Ethernet connection, ZMap is
capable scanning the entire public IPv4 address space in under 45 minutes."

~~~
marksamman
It isn't clear whether that is on a specific port or every port. The
documentation[1] makes it look like it's on a specific port since it requires
a target port to run. If it's on a specific port, you might want to multiply
45 minutes with 65535, if not I'm impressed. Thanks for sharing, I had not
heard about ZMap before.

[1] [https://zmap.io/documentation.html](https://zmap.io/documentation.html)

EDIT: The research paper says that it's on a particular port, from page 3:
"The architecture allows sending and receiving components to run
asynchronously and enables a single source machine to comprehensively scan
every host in the public IPv4 address space for a particular open TCP port in
under 45 mins using a 1 Gbps Ethernet link."

~~~
phil21
> If it's on a specific port, you might want to multiply 45 minutes with
> 65535, if not I'm impressed.

You're not? I am. Or would be if this wasn't known info yet.

Think about it for a bit - you can narrow down your search area quite a bit by
excluding huge swaths of the Internet such as consumer ISPs. Focus on the
target-rich environments like EC2 space, hosting providers, enterprises, etc.
You also can not scan any unassigned v4 space (admittedly getting smaller),
multicast addresses, RFC1918, etc. The usable pool of v4 is actually quite a
bit smaller than 32 bits, and the interesting parts are even less. I would be
surprised if you couldn't come up with a list of interesting space to scan
that you couldn't do within 15 minutes per port. You aren't using this tool to
pwn Joe nerd who runs a Linux NAT box off his cable modem.

From there, you just need a few hundred compromised servers (not difficult
this day in age) and you can probably scan the entirety of "rich" space on all
ports rather quickly via a distributed manner.

The only downside is such scans tend to generate complaints, so you'll need to
balance your loss of compromised hosts with the expected payoff.

