Look in the dusty corners!

A prediction (which you can help to make self-fulfilling): we will find security holes in implementations of protocol features which are

  1. hardly ever used
  2. not really understood
  3. underspecified

Possible targets:

HTML & data: URLs

RFC 2397 defines a URL type which carries its own content. This could play havoc with HTML content filters, filtering proxies, and so-called "browser security settings". Simply base64 the exploit and put it in a <a href="data:base64...">. You can also put iframes in data: URLs, which in turn …


After a list of devious attacks on TCP (e.g. Stefan Savage's Congestion Control Attack, Timestamp problems and ICMP based attacks), it seems as if even the basic protocols are not really well understood (or implemented). What happens in each of the thousands of TCP/IP stack implementations if they receive

  • ICMP Redirect (perhaps as part of a DDoS attack)?
  • ICMP EchoReq with a multicast source address (and they joined that< group)?

IPv6 options
I looked over the basic IPv6 RFCs ( 2460, 2461, 2462, 2463)

recently. Very impressive, they defined a lot of really incredible stuff. For example

  • the IPv6 Destination Options Header (RFC2460, Section 4.6) is an optional header that allows to pad datagrams with zeros. Glorio!

  • the IPv6 Routing Header (RFC2460, Section 4.6) defines up to 127 hops through which a datagram should travel. It specifies the hops by addresses, so that the header alone can be up to 16 * 127 + 4 = 2036 bytes long. The routing header may not be fragmented (RFC2460, Section 4.5), and the minimum MTU is 1280 (RFC2460, Section 5). It makes the mind boggle.

  • to compute the UDP body checksum, an IPv6 pseudo-header has to be constructed in memory. The UDP checksum ignores the headers between the address part and the UDP header, except when there's a routing header present, in which case it has to be parsed for the final hop, which will then be included in the pseudo-header. Simple, fast, efficient.

While there are some compliance testing efforts, there seem to be no checks about handling of non-compliant datagrams. What happens if a datagram carries two routing headers, three destination option headers, undefined NextHeader values, or a Jumbogram header indicating a payload of 4 Gigabyte on an ordinary ether interface?


Diverse pranks with Unicode are making the round (e.g. shoestringfoundation's very own UTFbiffier), and the various hacks to get wide-char support in standard applications, and then there's Internationalized Domain Names (RFC 3490) and useful character encodings in X509 (for example Teletext and T61Sting which includes really suprising chars, see Peter Gutmann's highly readable X.509 style guide). All that calls for further interesting exploits on the user interface.

ANSI terminal viruses (ok, it's viri, but tell that to the walri)

We terribly ε¦ïʈè ɦaϲќҽrႽ tend to use command line interfaces on terminals, consoles, xterms or even screen. But there's been lots of interesting attacks involving magic escape sequences. A recent paper by H.D. Moore points out that this is a pending threat still.

URG flags and pointers

The TCP urgent feature implements the strange ITU-y idea of sideband signaling. It basically tells the socket that there's much more interesting data somewhere later in the TCP stream. Practically no program uses this, but who knows what shenanigans might be caused by an URG pointer in a Jumboframe …

Enough for now …

Thu, 09 Jun 2005
[/projects] permanent link