This is pretty wild to think about. I am a fifth of the way through this challenge and already have results. I found a bug using the CLI fuzzer, and the TCP server actually causes multiple crashes in the BitchX IRC client.
I am curious to see what the remainder of this project will bring.
Real Life Happens
I didn’t get around to blogging yesterday. We had company over for dinner, so the free time for the evening was cut short. I still ended up getting in about an hour of programming and using this tool.
Some minor improvements to the TCP fuzzer class and the IRC example were made. The rest of the time was spent within Wireshark going through as many IRC commands as I could think of and adding them to the IRC script. I am still a long way from having complete coverage of the IRC protocol.I tested these incomplete scripts against epic4, epic5, Konversation,
I tested these incomplete scripts against epic4, epic5, Konversation, irssi, barnowl, HexChat, and BitchX. As mentioned above, I was able to cause multiple crashes within BitchX using this tool. Unfortunately, I didn’t have time to review all of the crashes, so I do not know if any of these bugs are exploitable or not. Furthermore, I don’t know if anyone even uses BitchX anymore.
Later in the evening, I ended up switching it up a bit and writing something unrelated to this project. I started writing a utility using inotify to notify me if certain files are accessed. I’d like this to be a daemon that utilizes syslog that can be used on my network to alert me when things like /etc/shadow get written to, someone executes whoami or a few others. So far, the inotify functionality works, but this needs to have a few features added before it is functional:
fork(), write PID file, etc to make it a daemon process that just runs in the background.
- Scripts to make sure it is running and starts up right
- Signal and atexit handlers to notify if the program exits abnormally or exits for whatever reason.
Configuration files. I may not care about certain files depending on the situation. A way to map the watch descriptor to it’s associated file name.
implementation. Makefile, git repository, license, and the related nonsense required of a project.
- Investigate ways to make this work on other systems that are not Linux. As far as I know, inotify is Linux-specific, but something similar exists for BSD systems. I saw a Windows inotify implementation on GitHub, but am unsure if it works as I expect or if there is some other way to accomplish this with Windows internals.
That’s it for today. I will polish this up a bit further tomorrow, but this works in its current form: https://github.com/droberson/inotify-watch