[langsec-discuss] state machine attacks against TLS (SMACKTLS)

travis+ml-langsec at subspacefield.org travis+ml-langsec at subspacefield.org
Thu Mar 5 23:22:55 UTC 2015


https://www.smacktls.com/

So, I haven't looked at the JSSE (that is, JDK) implementation of TLS,
but I'm guessing that based on the number of erroneous transitions,
they implemented an ad-hoc state machine interwoven with the code
rather than modeling the FSM abstractly with explicit calls to make
transitions.  I am sure this sounds familiar to the readers of this
list, as the state machine is the state of the network data parser.

My intuition tells me that a large number of protocols could be
handled in a much safer by encoding a formal FSM with named
transitions that are explicitly invoked from the software and which
throw exceptions back if the transition is not allowed.  Further by
decoupling the FSM & associated client state from the software it
should be much easier to drive multiple state machines at once with a
single network daemon*.

If you were to do that you might be able to factor the parser out
(possible also for formal treatment) and have a single daemon handling
multiple services for multiple clients (a la inetd and the old
stateless services it handled directly).  One could then potentially
limit resource consumption for a single client across services to
prevent resource consumption attacks.  This was a bigger deal when I
thought of it in the 90s; now most servers are single-purpose.

[*] OS interactions such as assuming a given effective userid, or
irrevocably dropping permissions would be difficult, but possible if
one factored the "OS actor" out into its own component (each FSM would
have exactly zero or one of these as appropriate for the service being
handled).

In the case of safe languages and frameworks (erlang?), one could run
the protocol parser in a common memory space and avoid security
(process) boundary transition overhead (e.g. IPC overhead, scheduler
latency, TLB flush).  Similarly the FSMs could be handled directly in
the process space as well.  In the case of the OS actor, that must
necessarily be its own process context, but shared memory or zero-copy
IPC like that used by L4 microkernel could reduce that overhead
significantly.  The entire ecosystem might be modelable as a message
passing architecture.

This idea's pieces have been sitting undone on my list here:
http://www.subspacefield.org/~travis/good_ideas.html

Specifically, the 90s-influenced use cases:

Write a network daemon in a "safer" language than C (java, perl,
python, ML). See privilege.py for example of how to drop privileges
safely.

Write something like tcpdump or wireshark, but write the protocol
decoding routines in a safer language. ruby and python come to mind,
but ocaml might be faster.
-- 
http://www.subspacefield.org/~travis/
"Computer crime, the glamor crime of the 1970s, will become in the
1980s one of the greatest sources of preventable business loss."
John M. Carroll, "Computer Security", first edition cover flap, 1977
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20150305/f396f84d/attachment.sig>


More information about the langsec-discuss mailing list