Re: Full-Disclosure Digest, Vol 65, Issue 8

[Valdis.Kletnieks () vt edu]

On Tue, 06 Jul 2010 21:27:52 EDT, Mary and Glenn Everhart said:

> (Several paragraphs inventing a new protocol elided)

Why do you go through all the effort of handwaving a new and untested way to
establish a secure communications channel from your token to the other end,
when you could just say "we diffie-hellman a session key across and use it to
encrypt everything after that" and be done with it?)

It's of course a tad more complicated than that - you want to also do the moral
equivalent of an SSL certificate check in *both* directions, so the token knows
it's talking to the desired destination and not a fake one, and vice versa.
This is stuff you'd usually do in the browser, but you can't because the
browser is potentially compromised and thus untrusted. Oh, and you're going to
want to have sane proper CRL checking as well. This is stuff you'd usually do
in the browser, but you can't because the browser is potentially compromised
and thus untrusted.

Oh fuck, that token just sprouted OpenSSL because we don't trust the
local system's copy anymore, and it just got a bit bigger.

That theme is going to come back and bite us some more later...

> However the details are less important than the question: what would be 
> needed to achieve e-commerce systems and protocols that can function 
> even in the presence of infected
> systems and that make it clear,when something interferes, that the 
> protocol has failed and that the transaction must be redone?

Since we're assuming that the local hardware/software is no longer trusted, we
have a problem - untrusted means we can't allow it to ever see the information
in plaintext, because then it can be screen-scraped or otherwise snarfed up.
We've already seen banking trojans that rewrite the bank statement on the fly
to cover its withdrawals - if it pilfered $78.34, that line item won't show up
on the screen and all the other numbers are adjusted so you still think you
have $78.34 more than you really do.

So we *really* can't let that untrusted computer ever see any of that sensitive
info in cleartext.  But that's OK, because we've OpenSSL'ed a secure connection
from the token to the remote end.  The issue is that if you want to do anything
interesting like actually *display* your bank statement webpage, it can't be
done on the hacked machine's display, it has to go back to the token and be
displayed there.

Oh fuck, the token just sprouted a web browser, a display, and an input device,
because we don't trust the local system's stuff, and got even bigger.

At that point, that token is pretty autonomous, and isn't using the resources
of the compromised computer for anything other than just being another router
of packets. So why not just make it a bit bigger, put an RJ45 or wireless on
it, and unplug the hacked box and plug your token into the net instead?

Oh fuck, we've just re-invented a smartphone. ;)

> Can anything be done without hardware? (I have my doubts, having found 
> ways only that are good for a few uses before they get compromisable.) 
> If hardware is needed, what is the
> simplest and most effective system that can be used? What would it look 
> like? Can it be used by most people?

Seems like a hell of a lot of work to avoid having to admit we need to
actually *fix* those 140 million zombied machines.  Just sayin',

Attachment: _bin
Description:

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/