L35 slide update

lectures/L35-slides.tex

@@ -391,6 +391,71 @@
 
 \end{frame}
 
+\begin{frame}
+\frametitle{Supply Chain}
+
+Early in 2024, a vulnerability was discovered in the \texttt{xz} library.
+
+The library itself is used for data compression but some versions of \texttt{openssh} rely on it. 
+
+This is a strong example of what's termed a ``supply chain attack''. 
+
+\end{frame}
+
+\begin{frame}
+\frametitle{Supply Chain}
+
+Almost any modern piece of software is built in a compositional way.
+
+Compromising dependency $F$ means creating a vulnerability in $A$...
+
+
+If $A$ is \texttt{openssh} (\textit{secure} shell daemon) $\rightarrow$ BIG problem.
+
+\end{frame}
+
+\begin{frame}[fragile]
+\frametitle{How do you find it?}
+
+\begin{verbatim}
+before:
+[email protected]: Permission denied (publickey).
+
+before:
+real	0m0.299s
+user	0m0.202s
+sys	0m0.006s
+
+after:
+[email protected]: Permission denied (publickey).
+
+real	0m0.807s
+user	0m0.202s
+sys	0m0.006s
+\end{verbatim}
+
+\end{frame}
+
+\begin{frame}
+\frametitle{The Vulnerability in xz Explained}
+
+\begin{center}
+  \includegraphics[width=0.52\textwidth]{images/xz.png}
+\end{center}
+
+\end{frame}
+
+\begin{frame}
+\frametitle{How do you defend against it?}
+
+There's obfuscation in the source code, so analysis is hard.
+
+This also had a social engineering component.
+
+How do you validate transitive dependencies?
+
+\end{frame}
+
 
 \end{document}
 

lectures/L35.tex

@@ -133,7 +133,7 @@ \subsection*{Security, Report to the Bridge}
 
 The term comes from the logistical supply chain. Supply chains for physical products are often complicated; if you want to build a gaming PC you need a large number of different components and you only get the end product when you've got all the pieces at hand. The problem is recursive, though: how many different components and pieces did, for example, nvidia require to make your graphics card? If one of the components -- however small or seemingly-insignificant -- is unavailable for whatever reason, the device (or computer) can't be built. 
 
-Similarly, almost any modern piece of software that isn't a toy or academic application is built in a compositional way (app $A$ uses libraries $B, C, D$ each of which has dependencies $E, F, G, H...$), compromising any one of the dependencies $F$ could result in a vulnerability in $A$. But if $A$ is \texttt{openssh}, you know, the \textit{secure} shell daemon, being able to exploit that means being able to have root access on the vulnerable server and execute arbitrary code. 
+Similarly, almost any modern piece of software that isn't a toy or academic assignment is built in a compositional way (app $A$ uses libraries $B, C, D$ each of which has dependencies $E, F, G, H...$), compromising any one of the dependencies $F$ could result in a vulnerability in $A$. But if $A$ is \texttt{openssh}, you know, the \textit{secure} shell daemon, being able to exploit that means being able to have root access on the vulnerable server and execute arbitrary code. 
 
 Part of what makes this example so relevant for this course is that the problem was discovered via performance profiling! The backdoor makes the \texttt{openssh} server run much slower due to the injected code that is running before the authentication actually takes place; see the example from~\cite{xzlib}:
 
@@ -154,7 +154,7 @@ \subsection*{Security, Report to the Bridge}
 sys	0m0.006s
 \end{verbatim}
 
-There's a lot of obfuscation in the implementation and the conditions needed to trigger the vulnerability are very specific, to reduce the likelihood of discovery. The details of the vulnerability and the social engineering needed to land it in a library are better suited for a security course than this one -- but this is an important lesson in how it's not enough to just defend against vulnerabilities in the libraries or tools we know we use.
+The slides contain a graphic that gives a breakdown of the vulnerability in a (hopefully) concise way. There's a lot of obfuscation in the implementation and the conditions needed to trigger the vulnerability are very specific, to reduce the likelihood of discovery. The details of the vulnerability and the social engineering needed to land it in a library are better suited for a security course than this one -- but this is an important lesson in how it's not enough to just defend against vulnerabilities in the libraries or tools we know we use.
 
 
 \input{bibliography.tex}