Alright, I finally decided on my practicum subject. Together with my supervisor, we came up with the following exposé. I either wanted to do that or to do something in Mobile (Phone) OS security.
USB is omnipresent and so far, mostly Operating System behaviour has been exploited, i.e. automatically run an application off a CDROM. USB-Stack, USB-Driver or application security has not yet been in the focus of security research, probably because it is infeasible to create many USB test devices.
If various USB behaviour could be implemented easily and cheaply, a great diversity of maliciously acting USB devices could be tested with little effort.
The goal is to implement a USB fuzzing framework using a virtualisation software that allows to automatically test different USB behaviour to stress-test USB-Stacks, drivers and applications.
While hardware approaches would be possible, a virtual approach using virtualisation software will be taken. That allows any guest Operating System, including Windows and Linux, to be tested, as well as cheap and quick creation of tests and reliable reproduction of the obtained results.
Ideally, this results in exploits for each of the three identified vulnerable layers:
- USB Stack in the Operating System
- USB Driver for the attached device (i.e. Webcam)
- Application using data from the USB device
Thus following questions will be addressed:
- How secure are USB stacks when it comes to weird devices?
- How resistant are drivers when specially crafted payload is sent?
- How good are applications that act upon a new USB device and read its data?
For CA640 we were supposed to pick a paper from International Conference of Software Engineering 2009 (ICSE 2009) and critically review it.
I chose to review Tesseract: Interactive Visual Exploration of Socio-Technical Relationships in Software Development.
You can find the review in PDF here. Its abstract reads:
This critical review of a paper, which presents Tesseract and was handed in for the ICSE 2009, focusses on
strength and weaknesses of the idea behind Tesseract: Visualising and exploring freely available and loosly coupled fragments (mailing lists, bug tracker or commits) of Free Software development.
Tesseract is thus a powerful data miner as well as a GUI to browse the obtained data.
This critique evaluates the usefulness of Tesseract by questioning the fundamental motivation it was built on, the data which it analyses and its general applicability.
Existing gaps in the original research are filled by conducting interviews with relevant developers as well as providing information about the internal structure of a Free Software project.
Tesseract is a program that builds and visualises a social network based on freely available data from a software project such as mailing lists, bug tracker or commits to a software repository. This network can be interactively explored with the Tesseract tool. This tool shows how communication among developers relates to changes in the actual code. The authors used a project under the GNOME umbrella named Rhythmbox to show their data mining and the program in operation. GNOME is a Free/Libre Software Desktop used as default by many Linux distributions including the most popular ones, i.e. Ubuntu and Fedora. To assess Tesseracts usability and usefulness, the authors interviewed people not related to Rhythmbox asking whether Tesseract was usable and provided useful information.
The paper was particularly interesting for me because the authors analysed data from the GNOME project. As I am a member of that development community, I wanted to see how their approach can or cannot increase the quality of the project. Another focus was to help their attempt to improve GNOME by highlighting where they may have gaps in their knowledge of its internals.
During this critique, I will show that some assumptions were made that do not hold for Free/Libre and Open Source Software (FLOSS) in general and for GNOME in particular either because the authors simply did not have the internal knowledge or did not research carefully enough. Also I will show that the used data is not necessarily meaningful and I will attempt to complement the lacking data by presenting the results of interviews I conducted with actual GNOME developers. This will show how to further improve Tesseract by identifying new usage scenarios. Lastly, this text will question the general usefulness of Tesseract for the majority of Free Software projects.