[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Tor in Haskell and Other Unikernel Tricks
This was an informative video, especially wrt unikernels. Certainly this
Haskell implementation can be a useful research tool.
However, the author strongly implies that it would/could be a "good thing"
having this other implementation running in the wild, side by side with the current implementation. But doesn't research suggest multiple
implementations tend to widen the attack surface.
Unfortunately I don't have access to academic research. Does anybody have relevant citations? I only have a reference to a video of Patterson/Sassaman talking about it wrt langsec:
https://www.youtube.com/watch?v=Rk0vpTGFr9Y
And here's the relevant snippet:
Meredith: ...another boundary that tends to be ripe for problems is when you
have multiple implementations of the same protocol. This was what we had
a lot of fun with last year between nss, cryptoapi and openssl.
Len: Because you wind up with a situation where they're not all speaking the
same protocol. They're all speaking versions of the same protocol in-- in most
cases-- mutually intelligible dialects. However, if you can wind up with
situations where one implementation of the same protocol parses the same
input data in a different way than a second implementation of this same protocol
parsing this same input data, you now have-- first of all-- proved that they're not
identical-- and secondly you've got a point of weakness. We refer to this as "differential parse string attacks." We'll have a slide on that later, but this allows
you to pinpoint the area where there's likely to be some manoeuvrability to build
an attack. This is where your attack vector is likely to be because you can
confuse the recipient by crafting an expression of some sort of payload for this
packet so it means one thing that's safe to the one implementation.
In x509 we had the problem of-- as we mentioned before-- openssl pretty much
doing things correctly: parsing things as they were-- we've got string literals
here, we've got this null character-- obviously that's a character and we're going
to treat it as such and validate against everything after it. We were not going to
ignore it. The problem, though, was we got special rights based on that-- the
signing of our csr. And then we turned around and had a different
implementation parse those same parts. They parsed them differently, and
differently in such a way that it escalated privilege for us.
So had openssl been doing things as identically but as haphazardly as the browsers, the attacks probably would not have been possible. Or, most of them.
Meredith: It's a little bit unexpected, but if everybody's doing something wrong the same way, then it's actually not as bad. if one person is doing things right and everybody else is doing things wrong, then you actually end up playing them off each other.
***
-Jonathan
On Friday, March 18, 2016 12:19 AM, grarpamp <grarpamp@xxxxxxxxx> wrote:
On 3/17/16, Erik de Castro Lopo <mle+tools@xxxxxxxxxxxxx> wrote:
>Â Â http://www.infoq.com/presentations/tor-haskell
> an implementation of Tor written in Haskell and running on a
> Haskell unikernel called HaLVM.
Add it here, and get this page linked to the front, or at least not orphaned...
https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk