On Sep 12, 2008, at 6:41 PM, Darrin Chandler wrote:
On Fri, Sep 12, 2008 at 05:42:08PM -0700, johan beisser wrote:
It's just a improbable attack. One that's easily defended against by
maintaining the interactive shell/echoback and simply push additional
Was it you who said earlier that you weren't a cryptanalyst? Well,
neither am I, but I have come away with one lesson from them: be on
the
attack. You are on the defense, and always putting forward reasons why
this isn't a quick total penetration. Instead, try thinking of what
information you can get by snooping, and what you might do with it.
It's
a whole different mindset.
Yes. I'm not sure why you assume to know how or what I'm thinking.
I'm saying what he's wanting to prevent - Eve watching input and
output to figure out passwords, based on keyboard timing and typing
patterns - isn't really an easy attack for Eve to accomplish without a
huge amount of data being collected first.
At no time did I say Eve couldn't figure out other bits of information
by treating the system as a black box and simply watching what goes in
vs what comes out, or quietly sending in her own inputs.
You can see this in Damien Miller's messages.
Rather than pooh-pooh this like you, he's considering the problems and
trying to think of ways to break openssh. This attitude of Damien (and
other obsd devs) is why openssh is so strong. If they thought only of
defense then openssh would have a track record similar to so many
other
programs.
I think it's less that I'm "pooh-pooh"ing an attack, than saying that
specific attack is easily thrown off without doing any protocol
revision and interactive session changes. Frankly, introducing noise
to the stream doesn't affect your session and would interfere with Eve
listening and trying to figure out outputs to inputs ("rush of inbound
characters just before an outbound ssh session may be a password").
That said, it's not even the cryptography I'm talking about. It's just
signal vs noise. Introducing noise is not changing the algorithm, it's
changing the patterns of packets preventing enumeration or viewing
pattern information for that session. It's essentially making it so
you can't enumerate input to the output anymore without specific
knowledge of what's going on.
Note that at no time is this attacking the transport protocol, or the
encryption. In the case of the SSH1 attack against the block cypher
used, part of it was a weak algorithm with insufficient padding for
the input.
Back when I did financial software we played a game of thinking of
ways
to steal money. We found several ways and plugged those holes, and
related holes. Most of the holes were never tried but some of them
were
(and people went to prison). If we had not played our game we *never*
would have found some of the holes.
Which is what you should do.
Let's play your game really quickly:
1. figure out how many packets would be sent for "du" and "df"
2. how many packets would be returned for each of those two commands?
That is, without the CRLF being punched in.
3. is each letter a single packet outbound? How many return packets
did you get for the echo back? Per letter.
4. if you hit enter, how many return packets did you get?
5. now, have two interactive shell sessions through the same tunnel.
Differentiate which one is active at any given time, and who is typing
on a per packet basis.
You should try this game. Not only can it be rewarding for your own
security, it can be fun as well.
I like you. You're amusing, and you missed the point I've made. Twice.
