synchronous/korg-paper
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

more

Browse Source
This commit is contained in:
Your Name
2025-02-23 17:28:08 -05:00
parent cc322832e2
commit 965446ee62
20 changed files with 6464 additions and 10312 deletions
Download Patch File Download Diff File Expand all files Collapse all files

444
sections/design.tex
View File

@@ -1,21 +1,11 @@
%!TEX root = ../main.tex
In this section we discuss the details behind the design, formal guarantees, implementation, and usage of \korg.
\subsection{Mathematical Preliminaries}%
\label{sub:Mathematical Preliminaries}
Linear Temporal Logic (LTL) is a model logic for reasoning about program executions. In LTL, we say a program $P$ \textit{models} a property $\phi$ (notationally, $P \models \phi$). That is, $\phi$ holds over every execution of $P$. If $\phi$ does not hold over every execution of $P$, we say $P \not\models \phi$. The LTL language is given by predicates over a first-order logic with additional temporal operators: \textit{next}, \textit{always}, \textit{eventually}, and \textit{until}.
An LTL model checker is a tool that, given $P$ and $\phi$, can automatically check whether or not $P \models \phi$; in general, LTL is a \textit{decidable} logic, and LTL model checkers will always be able to decide whether $P \models \phi$ given enough time and resources.
We use $\mid \mid$ to denote rendezvous composition. That is, if $S = P \mid \mid Q$, processes $P$ and $Q$ are composed together into a singular state machine by matching their equivalent transitions.
\textit{LTL program synthesis} is the problem of, given an LTL specification $\phi$, automatically deriving a program $P$ that satisfies $\phi$ (that is, $P \models \phi$). \textit{LTL attack synthesis} is logically dual to LTL program synthesis. In attack synthesis, the problem is flipped: given a program $P$ and a property $\phi$ such that $P \models \phi$, we ask whether there exists some "attack" $A$ such that $(P \mid \mid A) \not\models \phi$. Fundamentally, \korg is a synthesizer for such an $A$.
\subsection{High-level design}%
\label{sub:High-level design}
As aforementioned, \korg is based on \textit{LTL attack synthesis}; in particular, \korg synthesizes attacks with respect to \textit{imperfect} channels. That is, \korg is designed to synthesize attacks that involve replaying, dropping, reordering, or inserting messages on one or more communication channels.
%As aforementioned, \korg is based on \textit{LTL attack synthesis};
\korg is designed to synthesize attacks with respect to \textit{imperfect} channels. That is, \korg is designed to synthesize attacks that involve replaying, dropping or reordering messages on one or more communication channels relied upon by the victim protocol.
%The methodology behind the construction of \korg is based on \textit{LTL attack synthesis}.
@@ -36,180 +26,11 @@ A high-level visual overview of the \korg pipeline is given in Figure \ref{fig:k
\end{figure}
\subsection{Supported Attacker Models}%
\label{sub:Supported Attacker Models}
%\korg supports the automatic synthesis of attacks with respect to four general pre-defined attacker models applicable to any communication channel:
%\begin{itemize}
%\item \textbf{Drop Attacker Model}. Drop attackers are capable of dropping a finite number of messages off a channel.
%\item \textbf{Replay Attacker Model}. Replay attackers are capable of replaying previously seen messages back onto a channel.
%\item \textbf{Reorder Attacker Model}. Reorder attackers are capable of reordering messages on a channel.
%\item \textbf{Insert Attacker Model}. Insert attackers are capable of inserting arbitrary messages (as specifiable by the user) onto a channel.
%\end{itemize}
\korg supports four general attacker models: an attacker that can drop, replay, reorder, or insert messages on a channel. In this section we discuss the various details that went into the implementation of the gadgets that encapsulate the behavior of the respective attacker models.
% Additionally, \korg supports user-defined attacker that insert arbitrary messages onto a channel. In this section we discuss the various details that go into each attacker model.
\textbf{Drop Attacker Model Gadget}
The most simple attacker model \korg supports is an attacker that can \textit{drop} messages from a channel. The user specifies a "drop limit" value that limits the number of packets the attacker can drop from the channel. Note, a higher drop limit will increase the search space of possible attacks, thereby increasing execution time.
The dropper attacker model gadget \korg synthesizes works as follows. The gadget will nondeterministically choose to observe a message on a channel. Then, if the drop limit variable is not zero, it will consume the message. An example is shown in Figure \ref{lst:korg_drop}.
\begin{figure}[h]
\begin{lstlisting}[caption={Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}, label={lst:korg_drop}]
chan cn = [8] of { int, int, int };
active proctype attacker_drop() {
int b_0, b_1, b_2;
byte lim = 3; // drop limit
MAIN:
do
:: cn ? [b_0, b_1, b_2] -> atomic {
if
:: lim == 0 -> goto BREAK;
:: else ->
cn ? b_0, b_1, b_2; // consume message on the channel
lim = lim - 1;
goto MAIN;
fi
}
od
BREAK:
}
\end{lstlisting}
\end{figure}
\textbf{Replay Attacker Model Gadget}
The next attacker model \korg supports is an attacker that can observe and \textit{replay} messages back onto a channel. Similarly to the drop limit for the dropping attacker model, the user can specify a "replay limit" that caps the number of observed messages the attacker can replay back onto the specified channel.
The replay attacker model gadget \korg employs works as follows. The gadget has two states, \textsc{Consume} and \textsc{Replay}. The gadget starts in the \textsc{Consume} state and nondeterministically reads (but not consumes) messages on the target channel, sending them into a local storage buffer. Once the gadget read the number of messages on the channel equivalent to the defined replay limit, its state changes to \textsc{Replay}. In the \textsc{Replay} state, the gadget nondeterministically selects messages from its storage buffer to replay onto the channel until out of messages. An example is shown in Figure \ref{lst:korg_replay}.
\begin{figure}[h]
\begin{lstlisting}[caption={Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}, label={lst:korg_replay}]
chan cn = [8] of { int, int, int };
// local memory for the gadget
chan gadget_mem = [3] of { int, int, int };
active proctype attacker_replay() {
int b_0, b_1, b_2; int i = 3;
CONSUME:
do
// read messages until the limit is passed
:: cn ? [b_0, b_1, b_2] -> atomic {
cn ? <b_0, b_1, b_2> -> gadget_mem ! b_0, b_1, b_2;
i--;
if
:: i == 0 -> goto REPLAY;
:: i != 0 -> goto CONSUME;
fi }
od
REPLAY:
do
:: atomic {
// nondeterministically select a random value from the storage buffer
int am;
select(am : 0 .. len(gadget_mem)-1);
do
:: am != 0 ->
am = am-1;
gadget_mem ? b_0, b_1, b_2 -> gadget_mem ! b_0, b_1, b_2;
:: am == 0 ->
gadget_mem ? b_0, b_1, b_2 -> cn ! b_0, b_1, b_2;
break;
od }
// doesn't need to use all messages on the channel
:: atomic {gadget_mem ? b_0, b_1, b_2; }
// once mem has no more messages, we're done
:: empty(gadget_mem) -> goto BREAK;
od
BREAK:
}
\end{lstlisting}
\end{figure}
% \subsection{Supported Attacker Models}%
% \label{sub:Supported Attacker Models}
\textbf{Reorder Attacker Model Gadget}
\korg supports synthesizing attackers that can \textit{reorder} messages on a channel. Like the drop and replay attacker model gadgets, the user can specify a "reordering limit" that caps the number of messages that can be reordered by the attacker on the specified channel.
The reordering attacker model gadget \korg synthesizes works as follows. The gadget has three states, \textsc{Init}, \textsc{Consume}, and \textsc{Replay}. The gadget begins in the \textsc{Init} state, where it arbitrarily chooses a message to start consuming by transitioning to the \textsc{Consume} state. When in the \textsc{Consume} state, the gadget consumes all messages that appear on the channel, filling up a local buffer, until hitting the defined reordering limit. Once this limit is hit, the gadget transitions into the \textsc{Replay} state. In the \textsc{Replay} state, the gadget nondeterministically selects messages from its storage buffer to replay onto the channel until out of messages. An example is shown in Figure \ref{lst:korg_reordering}.
\begin{figure}[h]
\begin{lstlisting}[caption={Example reordering attacker model gadget with the selected replay limit as 3, targetting channel "cn"}, label={lst:korg_reordering}]
chan cn = [8] of { int, int, int };
chan gadget_mem = [3] of { int, int, int };
active proctype attacker_reordering() priority 255 {
byte b_0, b_1, b_2, blocker; int i = 3;
INIT:
do
:: { // arbitrarily choose a message to start consuming on
blocker = len(cn);
do :: b != len(c) -> goto INIT; od
}
:: goto CONSUME;
od
CONSUME:
do
// consume messages with high priority
:: c ? [b_0] -> atomic {
c ? b_0 -> gadget_mem ! b_0; i--;
if
:: i == 0 -> goto REPLAY;
:: i != 0 -> goto CONSUME;
fi }
od
REPLAY:
do
// replay messages back onto the channel, also with priority
:: atomic {
int am;
select(am : 0 .. len(gadget_mem)-1);
do
:: am != 0 ->
am = am-1;
gadget_mem ? b_0 -> attacker_mem_0 ! b_0;
:: am == 0 ->
gadget_mem ? b_0 -> c ! b_0;
break;
od }
:: atomic { empty(gadget_mem) -> goto BREAK; }
od
BREAK:
}
\end{lstlisting}
\end{figure}
\begin{figure}[h]
\begin{lstlisting}[caption={Example I/O file targetting channel "cn"}, label={lst:io-file}]
cn:
I:
O:1-1-1, 1-2-3, 3-4-5
\end{lstlisting}
\begin{lstlisting}[caption={Example gadget synthesized from an I/O file targetting the channel "cn"}, label={lst:io-file-synth}]
chan cn = [8] of { int, int, int };
active proctype daisy() {
INIT:
do
:: cn ! 1,1,1;
:: cn ! 1,2,3;
:: cn ! 3,4,5;
:: goto RECOVERY;
od
RECOVERY:
}
\end{lstlisting}
\end{figure}
\textbf{Insert Attacker Models}
\korg supports the synthesis of attackers that can simply insert messages onto a channel. While the drop, replay, and reordering attacker model gadgets as previously described have complex gadgets that \korg synthesizes with respect to a user-specified channel, the insert attacker model gadget is synthesized with respect to a user-defined \textit{IO-file}. This file denotes the specific outputs and channels the attacker is capable of sending, and \korg generates a gadget capable of synthesizing attacks using the given inputs. An example I/O file is given in Figure \ref{lst:io-file}, and the generated gadget is given in Figure \ref{lst:io-file-synth}.
These attacker models can be mixed and matched as desired by the \korg user. For example, a user can specify a drop attacker and replay attacker to target channel 1, a reordering attacker to target channel 2, and an insert attacker to target channel 3. If multiple attacker models are declared, \korg will synthesize attacks where the attackers on different channel \textit{coordinate} to construct a unifying attack.
\input{sections/examples}
% \input{sections/examples}
@@ -247,7 +68,10 @@ These attacker models can be mixed and matched as desired by the \korg user. For
\subsection{\korg Implementation}%
\label{sub:impl}
We implemented \korg on top of the \spin, a popular and robust model checker for reasoning about distributed and concurrent systems. \spin has existed for over 40 years, and has been applied to dozens of real systems including the Mars Rover \cite{Holzmann_2014}, Path-Star Access server \cite{Holzmann_Smith_2000}, and an avionics operating system \cite{mcp}. Additionally, \spin has spawned a dedicated formal methods symposium, currently in its 32nd year\footnote{\url{https://spin-web.github.io/SPIN2025/}}, and earned the 2002 ACM Software System award.
\textbf{The SPIN Model Checker}.
We choose to implement \korg on top of the \spin, a popular and robust model checker for reasoning about distributed and concurrent systems. \spin has existed for over 40 years, and has been applied to dozens of real systems including the Mars Rover \cite{Holzmann_2014}, Path-Star Access server \cite{Holzmann_Smith_2000}, and an avionics operating system \cite{mcp}. Additionally, \spin has spawned a dedicated formal methods symposium, currently in its 32nd year\footnote{\url{https://spin-web.github.io/SPIN2025/}}, and earned the 2002 ACM Software System award. Alternatively, the \korg could easily be built on top of other automated reasoning tools besides \spin, including TLA+ using the methodology described in \cite{message_queues_TLA}, Dafny using the formulation of I/O automata described in \cite{Hsieh_Mitra_2019}, and mCRL2 using its process algebra-based modeling framework \cite{mCRL2}. We choose \spin over these options due to its historical popularity and robustness.
%TLSMIN \cite{TLSMIN}, and mCRL2 \cite{mCRL2}
Intuitively, models written in \promela, the modeling language of \spin, are communicating state machines whose messages are passed over defined \textit{channels}. Channels in \promela can either be unbuffered \textit{synchronous} channels, or buffered \textit{asynchronous} channels. \korg generates attacks \textit{with respect} to these defined channels.
@@ -268,22 +92,34 @@ active proctype Peer2() {
\korg is designed to parse user-chosen channels and generate gadgets for sending, receiving, and manipulating messages on them. \korg has built-in gadgets that are designed to emulate various real-world attacker models.
%Additionally, users can explicitly define which messages a generated gadget can send and receive.
Once one or multiple gadgets are generated, \korg invokes \spin to check if a given property of interest remains satisfied in the presence of the attacker gadgets.
\textbf{Preventing \korg Livelocks}
In general, there are two types of LTL properties: safety, and liveness. Informally, safety properties state "a bad thing never happens," and liveness properties state "a good thing always happens."
Therefore, safety properties can be violated by finite traces, while liveness properties require infinite traces to be violated.
When evaluating a \korg attacker model gadget against a \promela model and a liveness property, it is crucial to ensure the gadget has no cyclic behavior. If a \korg gadget has cyclic behavior in any way, it will trivially violate the liveness
property and produce a garbage attack trace. To prevent this, we make the following considerations.
First, we design our \korg gadgets such that they never arbitrarily send and consume messages to a single channel. Second, we allow \korg gadgets,
which are always processing messages on channels, to arbitrarily "skip" messages on a channel if need be. To demonstrate the latter, consider the extension of the drop attacker model gadget in Figure \ref{lst:drop_passer}. We implement message skipping by arbitrarily stopping and waiting after observing a message on a channel; once the channel is observed changing lengths, the message is considered skipped and future messages can be consumed.
%\korg supports the automatic synthesis of attacks with respect to four general pre-defined attacker models applicable to any communication channel:
\textbf{Attacker Gadget Implementations}.
\korg supports synthesizing three general attackers, implementing the gadgets as described in section \ref{sec:Attacker Gadgets}: attackers that can drop, replay, or reorder messages on a channel. We now discuss the various details that went into the implementations of the various attacker gadgets within \spin.
% an attacker that can drop, replay, reorder, or insert messages on a channel. As aforementioned, they
% In this section we discuss the various details that went into the implementation of the gadgets that encapsulate the behavior of the respective attacker models.
% Additionally, \korg supports user-defined attacker that insert arbitrary messages onto a channel. In this section we discuss the various details that go into each attacker model.
\textbf{Drop Attacker Gadget Implementation}.
The most simple model \korg implements is an attacker that can \textit{drop} messages from a channel. The gadget works as follows. A pre-defined limit value \texttt{lim} is set, and the attacker begins in the \texttt{MAIN} state. Whenever a message is observed on a channel, if \texttt{lim == 0} the gadget progresses to the \texttt{BREAK} state. Otherwise, the observed message is consumed, \texttt{lim} is decremented, and the gadget returns to the \texttt{MAIN} state. An example \textit{drop} gadget automatically synthesized with \korg against the channel \texttt{cn} is shown in figure \ref{lst:korg_drop}.
% An example of a gadget attacking a channel transmitting three integers is shown in Figure \ref{lst:korg_drop}.
% The most simple attacker model \korg supports is an attacker that can \textit{drop} messages from a channel. The user specifies a "drop limit" value that limits the number of packets the attacker can drop from the channel. Note, a higher drop limit will increase the search space of possible attacks, thereby increasing execution time.
% The dropper attacker model gadget \korg synthesizes works as follows. The gadget will nondeterministically choose to observe a message on a channel. Then, if the drop limit variable is not zero, it will consume the message. An example is shown in Figure \ref{lst:korg_drop}.
\begin{figure}[h]
\begin{lstlisting}[caption={Example dropping attacker model gadget with message skipping}, label={lst:drop_passer}]
\label{lst:korg_drop}
\begin{lstlisting}[]
chan cn = [8] of { int, int, int };
active proctype attacker_drop() {
int b_0, b_1, b_2, blocker;
int b_0, b_1, b_2;
byte lim = 3; // drop limit
MAIN:
do
@@ -292,25 +128,213 @@ MAIN:
:: lim == 0 -> goto BREAK;
:: else ->
cn ? b_0, b_1, b_2; // consume message on the channel
lim = lim - 1;
goto MAIN;
fi
}
// pass over a message on a channel as needed
lim = lim - 1; goto MAIN;
fi }
od
BREAK: }
\end{lstlisting}
\caption{Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}
\label{lst:korg_drop}
\end{figure}
\textbf{Replay Attacker Gadget Implementation}.
The next model \korg implements is an attacker that can \textit{replay} messages on a channel. The gadget works as follows. The attacker model gadget comes with a pre-defined message limit value \texttt{lim}, which defines the length of the gadget storage FIFO buffer \texttt{gadget\_mem}. Then, the gadget enters the \texttt{CONSUME} state and nondeterministically chooses messages on the channel \texttt{cn} to copy into \texttt{gadget\_mem}. Once \texttt{lim=0}, the gadget transitions into the state \texttt{REPLAY}, where items are randomly selected from \texttt{gadget\_mem} to be replayed back onto the channel. Note, because \texttt{gadget\_mem} is a FIFO buffer, we must rotate messages within the channel in order to randomly select a value from it. Additionally, messages can also be nondeterministically removed from \texttt{gadget\_mem}, as all messages do not necessarily need to be replayed. Once \texttt{gadget\_mem} is empty, the gadget transitions to the \texttt{BREAK} state. An example gadget automatically synthesized with \korg against the channel \texttt{cn} is shown in figure \ref{lst:korg_replay}.
% The next attacker model \korg supports is an attacker that can observe and \textit{replay} messages back onto a channel. Similarly to the drop limit for the dropping attacker model, the user can specify a "replay limit" that caps the number of observed messages the attacker can replay back onto the specified channel.
% The replay attacker model gadget \korg employs works as follows. The gadget has two states, \textsc{Consume} and \textsc{Replay}. The gadget starts in the \textsc{Consume} state and nondeterministically reads (but not consumes) messages on the target channel, sending them into a local storage buffer. Once the gadget read the number of messages on the channel equivalent to the defined replay limit, its state changes to \textsc{Replay}. In the \textsc{Replay} state, the gadget nondeterministically selects messages from its storage buffer to replay onto the channel until out of messages. An example is shown in Figure \ref{lst:korg_replay}.
\begin{figure}[h]
\begin{lstlisting}[]
chan cn = [8] of { int, int, int };
// local memory for the gadget
chan gadget_mem = [3] of { int, int, int };
active proctype attacker_replay() {
int b_0, b_1, b_2; int lim = 3;
CONSUME:
do
// read messages until the limit is passed
:: cn ? [b_0, b_1, b_2] -> atomic {
// wait for the channel to change lengths
// then, once it does, go to MAIN
cn ? <b_0, b_1, b_2> -> gadget_mem ! b_0, b_1, b_2;
lim--;
if
:: lim == 0 -> goto REPLAY;
:: lim != 0 -> goto CONSUME;
fi }
od
REPLAY:
do
:: atomic {
// nondeterministically select a random value from the storage buffer
int am;
select(am : 0 .. len(gadget_mem)-1);
do
:: am != 0 ->
am = am-1;
gadget_mem ? b_0, b_1, b_2 -> gadget_mem ! b_0, b_1, b_2;
:: am == 0 ->
gadget_mem ? b_0, b_1, b_2 -> cn ! b_0, b_1, b_2;
break;
od }
// doesn't need to replay all stored msgs
:: atomic {gadget_mem ? b_0, b_1, b_2; }
// once mem has no more messages, we're done
:: empty(gadget_mem) -> goto BREAK;
od
BREAK: }
\end{lstlisting}
\caption{Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}
\label{lst:korg_replay}
\end{figure}
\textbf{Reorder Attacker Gadget Implementation}.
The final and most complex gadget \korg implements is an attacker that can \textit{reorder} messages on a channel. The gadget works as follows. The attacker model gadget comes with a pre-defined message limit value \texttt{lim}, which defines the length of the gadget storage FIFO buffer \texttt{gadget\_mem}. The gadget also has the highest \textit{execution priority} in the system, which ensures the gadget can always reorder messages on the victim channel without other processes interfering. The gadget first enters the \texttt{INIT} state --- in this state, the gadget non-deterministically chooses to pass messages on the victim channel, or transition to the \texttt{CONSUME} state. In the \texttt{CONSUME} state, the gadget consumes each message it sees and stores them in \texttt{gadget\_mem}, a FIFO buffer. Upon consuming each message from the victim channel, \texttt{lim} is decremented. Once \texttt{lim=0}, the gadget transitions to \texttt{REPLAY}. Then, messages are randomly selected from \texttt{gadget\_mem} to be replayed back onto the channel. Note, because \texttt{gadget\_mem} is a FIFO buffer, we must rotate messages within the channel in order to randomly select a value from it. Additionally, messages can also be nondeterministically removed from \texttt{gadget\_mem}, as all messages do not necessarily need to be replayed. Once \texttt{gadget\_mem} is empty, the gadget transitions to the \texttt{BREAK} state. An example gadget automatically synthesized with \korg against the channel \texttt{cn} is shown in figure \ref{lst:korg_reordering}.
% The attacker model gadget comes with a pre-defined message limit value \texttt{lim}, which defines the length of the gadget storage FIFO buffer \texttt{gadget\_mem}. Then, the gadget enters the \texttt{CONSUME} state and nondeterministically chooses messages on the channel \texttt{cn} to copy into \texttt{gadget\_mem}. Once \texttt{lim=0}, the gadget transitions into the state \texttt{REPLAY}, where items are randomly selected from \texttt{gadget\_mem} to be replayed back onto the channel. Note, because \texttt{gadget\_mem} is a FIFO buffer, we must rotate messages within the channel in order to randomly select a value from it. Additionally, messages can also be nondeterministically removed from \texttt{gadget\_mem}, as all messages do not necessarily need to be replayed. Once \texttt{gadget\_mem} is empty, the gadget transitions to the \texttt{BREAK} state.
% \textbf{Reorder Attacker Model Gadget}
% \korg supports synthesizing attackers that can \textit{reorder} messages on a channel. Like the drop and replay attacker model gadgets, the user can specify a "reordering limit" that caps the number of messages that can be reordered by the attacker on the specified channel.
% The reordering attacker model gadget \korg synthesizes works as follows. The gadget has three states, \textsc{Init}, \textsc{Consume}, and \textsc{Replay}. The gadget begins in the \textsc{Init} state, where it arbitrarily chooses a message to start consuming by transitioning to the \textsc{Consume} state. When in the \textsc{Consume} state, the gadget consumes all messages that appear on the channel, filling up a local buffer, until hitting the defined reordering limit. Once this limit is hit, the gadget transitions into the \textsc{Replay} state. In the \textsc{Replay} state, the gadget nondeterministically selects messages from its storage buffer to replay onto the channel until out of messages. An example is shown in Figure \ref{lst:korg_reordering}.
\begin{figure}[h]
\begin{lstlisting}[]
chan cn = [8] of { int, int, int };
// local memory for the gadget
chan gadget_mem = [3] of { int, int, int };
active proctype attacker_reordering() priority 255 {
byte b_0, b_1, b_2, blocker; int lim = 3;
INIT:
do
:: wait_until_pass(ch);
:: goto CONSUME;
od
CONSUME:
do
// consume messages with high priority
:: c ? [b_0] -> atomic {
c ? b_0 -> gadget_mem ! b_0; lim--;
if
:: lim == 0 -> goto REPLAY;
:: lim != 0 -> goto CONSUME;
fi }
od
REPLAY:
do
// replay messages back onto the channel, also with priority
:: atomic {
int am;
select(am : 0 .. len(gadget_mem)-1);
do
:: am != 0 ->
am = am-1;
gadget_mem ? b_0 -> attacker_mem_0 ! b_0;
:: am == 0 ->
gadget_mem ? b_0 -> c ! b_0;
break;
od }
:: atomic { empty(gadget_mem) -> goto BREAK; }
od
BREAK: }
\end{lstlisting}
\caption{Example reordering attacker model gadget with the selected replay limit as 3, targetting channel "cn"}
\label{lst:korg_reordering}
\end{figure}
% \begin{figure}[h]
% \begin{lstlisting}[caption={Example I/O file targetting channel "cn"}, label={lst:io-file}]
% cn:
% I:
% O:1-1-1, 1-2-3, 3-4-5
% \end{lstlisting}
% \begin{lstlisting}[caption={Example gadget synthesized from an I/O file targetting the channel "cn"}, label={lst:io-file-synth}]
% chan cn = [8] of { int, int, int };
% active proctype daisy() {
% INIT:
% do
% :: cn ! 1,1,1;
% :: cn ! 1,2,3;
% :: cn ! 3,4,5;
% :: goto RECOVERY;
% od
% RECOVERY:
% }
% \end{lstlisting}
% \end{figure}
% \textbf{Insert Attacker Models}
% \korg supports the synthesis of attackers that can simply insert messages onto a channel. While the drop, replay, and reordering attacker model gadgets as previously described have complex gadgets that \korg synthesizes with respect to a user-specified channel, the insert attacker model gadget is synthesized with respect to a user-defined \textit{IO-file}. This file denotes the specific outputs and channels the attacker is capable of sending, and \korg generates a gadget capable of synthesizing attacks using the given inputs. An example I/O file is given in Figure \ref{lst:io-file}, and the generated gadget is given in Figure \ref{lst:io-file-synth}.
% These attacker models can be mixed and matched as desired by the \korg user. For example, a user can specify a drop attacker and replay attacker to target channel 1, a reordering attacker to target channel 2, and an insert attacker to target channel 3. If multiple attacker models are declared, \korg will synthesize attacks where the attackers on different channel \textit{coordinate} to construct a unifying attack.
\textbf{Preventing \korg Livelocks}.
In general, there are two types of LTL properties: safety, and liveness. Informally, safety properties state "a bad thing never happens," and liveness properties state "a good thing always happens."
Therefore, safety properties can be violated by finite traces, while liveness properties require infinite traces to be violated.
When evaluating a \korg attacker model gadget against a \promela model and a liveness property, it is crucial to ensure the gadget has no cyclic behavior. If a \korg gadget has cyclic behavior in any way, it will trivially violate the liveness
property and produce a garbage attack trace. To prevent this, we make the following considerations.
First, we design our \korg gadgets such that they never arbitrarily send and consume messages to a single channel. Second, we allow \korg gadgets,
which are always processing messages on channels, to arbitrarily "skip" messages on a channel if need be. To demonstrate the latter, consider the extension of the drop attacker model gadget in Figure \ref{lst:drop_passer}. We implement message skipping by arbitrarily stopping and waiting after observing a message on a channel; once the channel is observed changing lengths, the message is considered skipped and future messages can be consumed.
\textbf{Passing Messages On Channels}.
In order to arbitrarily pass messages on channels in \spin, required functionality for all three gadgets we present, we exploit the finite channel length assumption. Our \spin gadget is shown below.
\begin{quote}
\begin{lstlisting}
inline wait_until_pass(chan ch){
cn ? [b_0, b_1, b_2] -> {
// wait for chan to change lengths. then, exit the loop
blocker = len(cn);
do
:: blocker != len(cn) -> goto MAIN;
od
}
:: goto BREAK;
od
BREAK:
:: blocker != len(cn) -> break;
od }
}
\end{lstlisting}
\end{figure}
\end{lstlisting}
\end{quote}
That is, when we enter \texttt{wait\_until\_pass}, we track the length of the channel \texttt{cn} and wait until \texttt{len(cn)} changes. This allows us to arbitrarily pass messages on a given channel \texttt{cn} without reasoning directly about the message.
% \begin{figure}[h]
% \begin{lstlisting}[caption={Example dropping attacker model gadget with message skipping}, label={lst:drop_passer}]
% chan cn = [8] of { int, int, int };
% active proctype attacker_drop() {
% int b_0, b_1, b_2, blocker;
% byte lim = 3; // drop limit
% MAIN:
% do
% :: cn ? [b_0, b_1, b_2] -> atomic {
% if
% :: lim == 0 -> goto BREAK;
% :: else ->
% cn ? b_0, b_1, b_2; // consume message on the channel
% lim = lim - 1;
% goto MAIN;
% fi
% }
% // pass over a message on a channel as needed
% :: cn ? [b_0, b_1, b_2] -> atomic {
% // wait for the channel to change lengths
% // then, once it does, go to MAIN
% blocker = len(cn);
% do
% :: blocker != len(cn) -> goto MAIN;
% od
% }
% :: goto BREAK;
% od
% BREAK:
% }
% \end{lstlisting}
% \end{figure}
\subsection{Usage}%