[HN Gopher] OpenSSH Keystroke Obfuscation Bypass
___________________________________________________________________
OpenSSH Keystroke Obfuscation Bypass
Author : pabs3
Score : 133 points
Date : 2024-09-11 06:19 UTC (16 hours ago)
(HTM) web link (crzphil.github.io)
(TXT) w3m dump (crzphil.github.io)
| thadt wrote:
| Good work. But - this is an implementation bug right? If the
| underlying stream of packets gives you a distinguisher (in this
| case, slightly larger packets), then this attack works. So
| adjusting the chaff and payload packet sizes to some fixed
| capacity restores obfuscation, if I'm understanding this
| correctly. And response packets - those also have to be managed
| to prevent leakage.
| KyleSanderson wrote:
| The implementation is just wrong from what's been presented.
| basic jitter (20-100ms), and a dynamic payload size are what's
| actually missing here. The question now becomes though how
| interactive should your session be. Timing the connection
| latency might help to an extent, but this is about mitm and you
| don't necessarily know where your adversary is (first hop, or
| towards the end). Batching keystrokes would also help here.
| tialaramex wrote:
| Basically there are two "modes" in normal mode OpenSSH is
| content to idle with no packets moving except any requested
| keepalives. In "chaff mode" currently they try to send a
| chaff packet every time they can to disguise your keypresses,
| but they forgot keystrokes will just get bundled into the
| existing chaff packet, growing it, so it stands out as
| special.
|
| All they need to do is retain the "chaff mode" but when they
| have a keystroke ready to be sent they should suppress the
| chaff that would otherwise go in the same packet.
|
| No need for "basic jitter" or "dynamic payload size" that I
| can see, with this change the packets are indistinguishable
| in terms of size or (encrypted) content, and they have no
| more or less jitter than would be normal for the network
| they're traversing.
|
| [Various small edits to clarify]
| SoftTalker wrote:
| I'm not an expert in this area at all but I recall reading that
| trying to hide a signal in random noise doesn't really work, as
| you can still find the signal with statistical analysis or
| looking for distingishing characteristics that are not obscured.
| That was my first thought when I read about this new feature in
| OpenSSH, and it seems to have proven correct.
|
| Edit: wanted to add that I recognize that the people working on
| OpenSSH know a lot more about this than I do, and I had assumed
| they wouldn't bother implementing this if it wasn't a good idea,
| so willing to accept that "proven correct" may be an
| overstatement or even flat-out wrong.
| milliams wrote:
| The advantage that OpenSSH have here is that they don't have to
| just hide the signal using noise, they can actually change the
| signal to look like the noise (or vice versa). For example they
| are making the signal packets some at a regular interval (since
| the "signal" being discussed is the timings). That alone would
| not hide the number of keypresses, but adding the chaff should
| do so.
|
| In this case, as said above, it seems like there's an
| implementation issue with actually doing those obfuscations,
| allowing the signal to be identified.
| qhwudbebd wrote:
| This was present in versions 9.5 - 9.7 of OpenSSH and fixed in
| 9.8p1 released at the beginning of July. Philippos (along with
| others) is credited for reporting it in the release notes:
| https://www.openssh.com/releasenotes.html#9.8p1
| keyboardcaper wrote:
| There is a market for keyboards which obscure keypress timings.
| gunapologist99 wrote:
| Yet another reason to switch to SSH keys instead of passwords
| wherever possible. Simple and bulletproof, with a minimum of
| footguns.
|
| EDIT: @tedunangst is right, wouldn't have helped. Even so, switch
| to keys!
| tedunangst wrote:
| Does nothing here.
| hi-v-rocknroll wrote:
| Perhaps instead shooting off individual keypresses with some
| random chaff packets, it would be wiser to have constant
| interval, constant low data rate, (say 8 KBps) data rate
| trickling packets through and let the other side throw away pick
| out the needles from the haystack of no ops. Good luck finding a
| side-channel in that.
| pshc wrote:
| Sounds good until (for example) you find out the SSH client
| library wasn't queueing up packets ahead of time, but instead
| building them at send time, and a chaff packet takes less time
| to build than a real packet... so many ways to get side-
| channeled.
| mrguyorama wrote:
| Regardless of what the "cause" of this is (ie bug or bad design),
| it's obvious nobody even took a look at this after it was coded
| up and merged in. The larger packets and double server ACKs are
| very clearly obviously giving the game away. This feature just
| doesn't even come close to what it supposedly does, was it even
| shipped as a feature or something that wasn't yet done?
|
| Not exactly encouraging, to see a system so integral to security
| seemingly shipping code without even a minor test of intended
| function.
| tedunangst wrote:
| I think it's worth asking how important the feature is in the
| grand scheme of things. But what about the CIA timing my
| keystrokes is more of a nerd forum thing than an actual attack
| vector you read about in intrusion post mortems.
| jonmon6691 wrote:
| Most people would consider streaming music to be a negligible
| amount of bandwidth. Seems to me like SSH in a "high security
| mode" could just send X Kbps of bi-directional pad at a layer
| directly above encryption but below application. Then just use
| that channel for all the normal SSH traffic. You could either
| treat this as a bandwidth limited channel or do some slow time-
| constant ramping up and down at the risk of leaking information
| about file downloads or large command outputs.
___________________________________________________________________
(page generated 2024-09-11 23:00 UTC)