A collection of random things

Here's a short summary of the things I'll cover:

• Using OOB data to bypass IDS OOB data is an obscure feature of TCP. Although there are RFC's describing how this should be handled, the implementations of it vary, and it makes for an excellent candidate to hide data from IDS'. The most common case with OOB data is that applications don't have any measures in place to handle them, and it's up to the OS to decide what to do with it. The RFC says to just queue it up till the next OOB you get and then discard it, but not all operating systems do this. Another case is where an application does handle OOB data, and it's delivered to the application, which'll deal with it in its application specific way, there is _NO_ way an IDS can predict how the application deals with it.

• /dev/[k]mem race conditions in suids Reading from /dev/[k]mem is tricky, it always has been. There is absolutely no way you can guarantee what you just read is still valid the nanosecond after you read it. Mostly because you can't lock the kernel from userspace (and rightfully so !). This leads to interesting synchronization issues where suid applications read certain kinds of data from /dev/[k]mem. Most interestingly it can lead to information leaks from the kernel, such as reading parts of the buffer cache, sniffing a person's tty, ...

• TCP Fuzzer that goes beyond the 3-way-handshake Ah, fuzzers, my favorite tools for easy bughunting. Somewhere last year it occurred to me that there really aren't any decent fuzzers for fuzzing low level TCP handling. At least nothing that goes beyond the 3-way-handshake (commercial fuzzers that cost a metric asston of money don't count), which is quite a shame since handling all the cases correctly is quite complex and difficult to accomplish, surely some bugs are still leftover in this department. In this part of the talk I'll give a rundown of all the things taken into consideration for TCP fuzzing, and I'll present the preliminary results. This part of my talk is a joint cooperation with Dan Kaminsky.

• snprintf() corner cases The safe alternative !!1! or maybe not. snprintf() is kind of an oddball. Certainly it's better than its older brother, but it does have its corner cases. The c99 spec is very clear on some of its properties (for example, guaranteeing 0-byte termination), but then also leaves open a lot (in case of errors occurring). Here I'll present all the corner cases I've ran into, some of them are very os specific, and show a couple of examples. c99 is assumed, any implementation that doesn't comply to it isn't considered (those are usually far more broken).