%====================================================================
%
% WHAT THIS FILE IS AND WHO WROTE IT
%
% This is the LaTeX template for the student papers of course
% T-110.5230 'Special Course in Practical Security of Information
% Systems' ('Hakkerikurssi') of the Telecommunications Software and
% Multimedia Laboratory of Helsinki University of Technology
%
% Free use and adaptation for academic purposes are hereby granted,
% provided that appropriate credit is given to this original document
%
% More information about the course, our laboratory and our university:
% http://www.tml.hut.fi/Opinnot/T-110.5230/
% http://www.tml.hut.fi/
% http://www.hut.fi/
%
% This file was created by Linda Staffans for seminar T-110.551 (2002)
% Modified by Teemupekka Virtanen for T-110.501 (2002)
% Modified by Ronja Addams-Moring for T-110.501 (2003)
% Reformated by Pasi Eronen and Nadja Kasinskaja for T-110.551 (2004)
% Revised by Ronja Addams-Moring for T-110.557 and T-110.501 (2004)
% Modified by Sami Vaarala for T-110.452 (2005)
% Revised  by Sami Vaarala for T-110.5230 (2006)
%
% Last revised: 2006-01-16
%  by Sami Vaarala
%
%====================================================================
%
% HOW TO TURN THIS FILE INTO PS and PDF
%
% To produce PostScript (PS or ps) and Portable Document Format
% (PDF or pdf) when you have used BibTeX to create your reference
% list REMEMBER to run BOTH the 'latex' and the 'bibtex' commands
% in some UNIX computer:
%
% NOTE! you may have to run the latex+bibtex command pair even
% THREE times to get rid of all unnecessary error messages
%
% REMEMBER TO USE YOUR OWN FILENAMES IN THESE COMMANDS!
% (note that typos in filenames make all these programs go haywire)
%
%   latex yourfile; bibtex yourfile
%   latex yourfile; bibtex yourfile 
%   latex yourfile; bibtex yourfile 
%  
%   dvips -o yourfile.ps yourfile
%   ps2pdf -dCompatibilityLevel=1.3 yourfile.ps
%
%====================================================================
%
% OTHER ADMINISTRATIVE INFORMATION
%
% Tested on the cc.hut.fi student computers as follows
%
% hostname: kosh.hut.fi
% OS: Compaq Tru64 UNIX V5.1B (Rev. 2650)
% HW: AlphaServer ES40, 4, Alpha EV67
% date & time: Mon Oct  4 10-11 AM
% who tested: ronja
% test result: OK
%
% hostname: vipunen.hut.fi
% OS: SunOS 5.8
% HW: UltraSPARC III  
% date & time: Mon Oct  4 10-11 AM
% who tested: ronja
% test result: OK
%
% Tested on the cs.hut.fi student computers as follows
%
% hostname: 
% OS: 
% HW:
% date & time: 
% who tested: 
% test result: 
%
% hostname: 
% OS: 
% HW:
% date & time: 
% who tested: 
% test result: 
%
%
%====================================================================
% BEGIN TEMPLATE
%====================================================================

\documentclass{ps2006}
%\documentclass[cameraready]{ps2006}

%====================================================================

\usepackage{url}

%====================================================================

\begin{document}

%====================================================================


\title{Exploiting Linux USB driver vulnerabilities}

\author{Tuure Laurinolli, Timo Lindfors \\
        Helsinki University of Technology \\
        \texttt{http://www.tml.hut.fi/Opinnot/T-110.5230/}}
\maketitle

%=====================================================================

\begin{abstract}
\label{abstr}

We plan to find exploitable bugs in Linux USB drivers and implement exploits in hardware.

\vspace{5mm}

KEYWORDS: USB, Linux, Denial of service, Arbitrary code execution

\end{abstract}

%====================================================================


\section{Introduction}
\label{sec:intro}

USB is a peripheral bus widely used for attaching all kinds of devices
to modern computers. There are some standard standard device classes
but many devices require a model-specific driver. In Linux USB device
drivers traditionally run in kernel space, making them a
security-critical components. When combined with the fact that many
USB device drivers in Linux are reverse-engineered and of low quality
the potential for exploitation is obvious.

USB is asymmetric in nature - devices (such as USB memory sticks) and
hosts (such as PCs) are separate entitites. Bugs in Linux USB device
drivers haven't got much attention since the drivers will only talk to
hardware that looks right, and emulating arbitrary USB devices has
traditionally been difficult, requiring a fragile hardware
setup. Nowadays small programmable USB devices are widely available,
and some mobile devices even offer user-space interface for emulating
almost arbitrary USB hardware.

%====================================================================

\section{Vulnerabilities in Linux USB drivers}

Kinds of vulnerabilities that likely exist in Linux USB drivers, plans
on how to find them. Descriptions of vulnerabilities found will be
here in the final document.

\subsection{Kinds of vulnerabilities}
Kinds of vulnerabilities we are looking for:

\begin{itemize}
\item
  Buffer overflows
\item
  Integer overflows
\item
  Race conditions
\end{itemize}

It seems that at least some protocols used by USB devices to chat with
the driver contain message sizes separate from the buffer size - there
are probably places where recipient allocates buffer according to
actual size but copies according to announced size or vice versa.

Buffer overflows on stack would be preferable but kmalloc buffers are
probably much more common.

\subsection{Finding vulnerabilities}

We aleady started looking for bugs by reading source code of linux usb
drivers. There were some obvious buffer handling issues.

We have also set up qemu so that we can easily debug the kernel with
gdb.

\subsection{Exploiting vulnerabilities}

We plan to verify suspected vulnerabilities by writing code that acts
as a USB device. This way we can pass anything we please to the driver
as long as we have proper vendor id, device id and endpoints
configured.

We found dummy\textunderscore{}hcd that can act as ``loopback'' USB
host, allowing us to write USB device simulators without needing
actual hardware. We can later migrate to real hardware, and plan to do
so once we have found promising exploits. Openmoko Freerunner has such
USb hardware, and we plan to port our exploit code to it once we have
some.

We found gadgetfs API for implementing USB devices in
userland. Gadgetfs can be tied to real hardware or dummy\_{}hcd. Thus
we can write USB device emulators that work entirely in software, or
given compatible hardware, can also attach to a physical USb port.

\subsection{General plans}
If we have time we also plan to port some exploit to Atmel AVR or
ARM. This would enable smaller portable exploits (About the size of
USB connector if designed from scratch).

If we have time we plan to write some general purpose tools for usb:
\begin{itemize}
\item
  Pretty printer for /dev/usbmon traffic
\item
  Easier library for using gadgetfs
\end{itemize}


\subsection{Findings so far}

Qemu usb proxying support was buggy. It uses blocking calls so the
whole virtual machine can stop with buggy usb devices.

We identified a buffer handling bug in stv680 webcam driver by
studying its code. We also wrote a device simulator that looks like an
stv680 webcam to the kernel.

Since dummy\_{}hcd/stv680 was quite buggy we briefly used a userland
port of the stv680 driver to get our device smulator to speak
correctly to the driver.

Also, we plan to investigate the possibility of using the Coccinelle
semantic patch framework to find usb bugs. This framework was used to
fix linux usb drivers when the in-kernel USB API changed.

\section{Impact}

Forms of impact we are looking to achieve. Description of impact of
found vulnerabilities will be here in the final document.

\subsection{Information disclosure}
\begin{itemize}
\item
  Read from kernel memory into structure going into user space,
because of improper bound checks
\end{itemize}

\subsection{Denial of service}

Possibilities of DoS:
\begin{itemize}
\item
  Memory exhaustion
\item
  Writing garbage over kernel data structures (improper bounds checks)
\item
  Infinite loop in IRQ handler
\end{itemize}

\subsection{Arbitrary code execution}
\begin{itemize}
\item
  Writing code into appropriate location in kernel memory 
\end{itemize}

\section{Protection}

\subsection{Disabling vulnerable drivers}
\begin{itemize}
\item
  Either reacting to vulnerability reports
\item
  Or disable everything
\item
  Or perhaps allow some well-known drivers (such as mass storage)
\end{itemize}

\subsection{Confirm modprobe}
\begin{itemize}
\item
  When a USB device is attached, the kernel could request user confirmation for loading its driver
\item
  "Press F11 to authorize device 'USB keyboard'" ;)
\item
  Would offer some security: for example unable to attach driver to computer that has its screen locked, or no user logged in in the first
\item
  Assumes there is a local user to approve modprobe
\end{itemize}

\subsection{Fix the drivers}
\begin{itemize}
\item
  Develop future drivers with better tools (for example, prove that URBs are not accessed beyond boundaries)
\item
  Automated fuzzing of arbitrary USB data would make it easier enhance driver quality
\end{itemize}

\section{Conclusions}

\section{Future developments}
\begin{itemize}
\item
  How well do file systems deal with malicious block devices? Modern
user interfaces tend to mount USB devices automatically, making
vulnerabilities in FS code easy to exploit
\end{itemize}

\section{Acknowledgements}

Acknowledgements, if any.

Dummy citations to show the cited material in the bibliography section.

\cite{usb2}
\cite{libusb-guide}
\cite{ldd3}
\cite{freerunner-usb}
\cite{AT90USB}
\cite{AT91SAM7S-EK}
\cite{stacksmashing}
\cite{exploiting-kmalloc}
\cite{kmalloc-internals}
\cite{coccinelle}
\cite{cve-2009-0243}
\cite{cve-2006-2935}
\cite{cve-2006-1368}



%====================================================================

\bibliography{ps2006}

%====================================================================

\end{document}

%EOF
