Wireshark Substitute Encourages Defensible Software
Thanks to nikns in #snort-gui for pointing me towards this 23rd Chaos Communication Congress talk on an alternative to Wireshark created by Andreas Bogk and Hannes Mehnert. This blog post explains the rationale behind this new tool, still in its infancy and nowhere nearly feature-complete as Wireshark. Two implementations exist. Here is a screenshot of GUI-sniffer:
Here is a screenshot of Network Night Vision:
These applications are written in the Dylan programming language, which is new to me. There's a lang/dylan FreeBSD port, but as you can see I just tried running the Windows binaries.
The authors have written a paper (.pdf) that describes the project in detail. From the first part of the paper:
The security industry is in a paradox situation: many security appliances and analysis tools, be it IDS systems, virus scanners, firewalls or others, suffer from the same weaknesses as the systems they try to protect. What makes them vulnerable is the vast amount of structured data they need to understand to do their job, and the bugs that invariably manifest in parsers for complex protocols if written in unsafe programming languages.
Since we noticed a lack of a decent secure framework for handling network packets, we have designed and implemented major parts of a TCP/IP stack in the high level programming language “Dylan”, focusing on security, performance and code reuse.
Dylan is a high level language that provides a number of features to detect and prevent data reference failures, one of the most common sources of vulnerabilities in C software.
Bounds checks for array accesses are inserted where needed by the compiler. Also a garbage collector is used, avoiding the need to care about manual memory management, and preventing bugs from early frees or double frees. Dylan is strongly typed, so bypassing the type system by doing casts and pointer arithmetic is not possible.
Even though it is as easy to use as common scripting languages, Dylan programs are compiled to machine code. It bridges the world between dynamic and static typing by doing optimistic type inferencing: bindings can be type annotated, and types of expressions can be computed at compile time. This often eliminates type checks or function dispatch in the code.
I am not in a position to critique the programming language used or the authors' implementation. However, I think the idea of building "defensible software," or software that has the best chance possible of resisting intrusions, is a great idea. It's the software equivalent of my "defensible network architecture" idea, which describes how to build an enterprise with the best chance possible of resisting intrusions.
I will probably add this tool and approach to my classes. When I teach network forensics I describe the importance of being aware of handling malicious traffic that might seek to compromise analysis tools like Wireshark or Snort. Thus far the anti-forensics movement seems to have concentrated on denying host-centric forensics, but exploits have always been available for subverting network inspection tools.
Incidentally, there are a ton of interesting talks at the CCC this year.
Here is a screenshot of Network Night Vision:
These applications are written in the Dylan programming language, which is new to me. There's a lang/dylan FreeBSD port, but as you can see I just tried running the Windows binaries.
The authors have written a paper (.pdf) that describes the project in detail. From the first part of the paper:
The security industry is in a paradox situation: many security appliances and analysis tools, be it IDS systems, virus scanners, firewalls or others, suffer from the same weaknesses as the systems they try to protect. What makes them vulnerable is the vast amount of structured data they need to understand to do their job, and the bugs that invariably manifest in parsers for complex protocols if written in unsafe programming languages.
Since we noticed a lack of a decent secure framework for handling network packets, we have designed and implemented major parts of a TCP/IP stack in the high level programming language “Dylan”, focusing on security, performance and code reuse.
Dylan is a high level language that provides a number of features to detect and prevent data reference failures, one of the most common sources of vulnerabilities in C software.
Bounds checks for array accesses are inserted where needed by the compiler. Also a garbage collector is used, avoiding the need to care about manual memory management, and preventing bugs from early frees or double frees. Dylan is strongly typed, so bypassing the type system by doing casts and pointer arithmetic is not possible.
Even though it is as easy to use as common scripting languages, Dylan programs are compiled to machine code. It bridges the world between dynamic and static typing by doing optimistic type inferencing: bindings can be type annotated, and types of expressions can be computed at compile time. This often eliminates type checks or function dispatch in the code.
I am not in a position to critique the programming language used or the authors' implementation. However, I think the idea of building "defensible software," or software that has the best chance possible of resisting intrusions, is a great idea. It's the software equivalent of my "defensible network architecture" idea, which describes how to build an enterprise with the best chance possible of resisting intrusions.
I will probably add this tool and approach to my classes. When I teach network forensics I describe the importance of being aware of handling malicious traffic that might seek to compromise analysis tools like Wireshark or Snort. Thus far the anti-forensics movement seems to have concentrated on denying host-centric forensics, but exploits have always been available for subverting network inspection tools.
Incidentally, there are a ton of interesting talks at the CCC this year.
Comments
gui-sniffer was the former name for network night vision, so these are not two different implementations.
The GUI is currently only working on Win32, but we're heading for a gtk2 port.
Let's hope AV works well this year to, then anyone could download most of talks for viewing.
Last year events,
http://events.ccc.de/congress/2005/fahrplan/events.en.html
Video/audio available at,
ftp://ftp.ccc.de/congress/22c3/
Count some month(s) before content is out.. I'll be waiting since I'm not attending this year..
Merry Christmas / Niklas
Events (UTC+1)
https://events.ccc.de/congress/2006/Fahrplan/
Stream
http://events.ccc.de/congress/2006/Streams
/Niklas