Ch. 14 Network Protocols
- Is the received packet too small?
- Must be at least 20 bytes.
- Does the IP packet contain options?
- Packets with options can be bigger than 20 bytes, up to 60.
- Is the IP header length valid?
- IP header length must be at least 5 (4*5=20).
- Is the total length field too large?
- Compared to the actual data received.
- Are all field lengths consistent?
- IP header length <= data available
- 20 <= IP header length <= 60
- IP total length <= data available
- IP header length <= IP total length
- Is the IP checksum correct?
- Is the option length sign-extended?
- It shouldn’t be. Byte to int promotion issues are common
- Is the header big enough to contain the IP option?
- Is the option length too large?
- Offset of IP option + IP option length <= IP header length
- Offset of IP option + IP option length <= IP total length
- Does the option meet minimum size requirements?
- Should be at least 2
- Are IP option buts checked?
- Most implementations ignore the separate bitfields without parsing
- Unique problems
- Solaris example
- Ensure that the pointer byte is within the specified bounds. During processing, an IP option often modifies bytes it pointing at.
- The pointer is a single-byte field - beware type conversions.
- Sign extensions could cause the offset to take on a negative value
- Check that the length of routing options is validated
- Data beyond the end of the final segment
- Attackers can put the final fragment (MF=0) in the middle or beginning of the set of fragments
- Multiple final fragments
- Overlapping fragments
- Us the UDP length field correct?
- The minimum value is 8 bytes (no data)
- Is the UDP checksum correct?
- Is the TCP data offset field too large?
- TCP header length <= data available
- 20 bytes (5 * 4) <= TCP header length <= 60 bytes
- Is the TCP header length too small?
- Id the TCP checksum correct?
- Is the option length field sign extended?
- It shouldn’t be, possibility of dangerous bugs
- For example, assigning char value to an int variable
- Are enough bytes left for the current option?
- Is the option length too large or too small?
- Compared to the size of the TCP header / packet
- 11 states: LISTEN, SYN_SENT, SYN_RCVD, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, CLOSING, TIME_WAIT, CLOSE_WAIT, LAST_ACK, CLOSED
- 6 flags: SYN, ACK, RST, URG, FIN, PSH
- Setting up, closing, tearing down of connections
- Handling pointers tint other packets
- Neglecting to check that the pointer is within the bounds of the current packet
- Recognising that the pointer is pointing beyond the end of the packet and trying to handle it (often incorrectly)
- Handling 0-offset urgent pointers
- 0 offset URG pointer is invalid
Stateless firewalls look for connection initiation packets - SYNs, and more or less let other packets go through.
Can be abused for FIN scanning (not sure this works anymore). Stateless FW has to let FIN and RST packets through.
Different stacks behave differently for weird combinations of flags. Eg. SYN-FIN may initiate a connection.
Only port-based rules. Return packets a big problem - e.g. DNS replies from servers. Effectively creates a hole for UDP scanning with a source port 53.
Active / passive FTP; active is a problem for stateless firewalls, similar to UDP above but with TCP.
Either deny completely or apply very simple set of rules to process. No tracking because stateless. Some rules:
- Fragments with low IP offset (1,2 etc) - drop as they will mess with TCP flags
- Fragments with 0 offset should contain the full header, otherwise drop
- Multiple offset 0 fragments - drop all after the full header
- Fragments with high offset can pass
- These days any issues are rare
- A common mistake is to allow responses from any UDP port
- Fragmentation handling
- Can be done better than with stateless FWs. Bugs existed
- Fooling virtual reassembly
- IP TTL field
- IP options
- Checkpoint’s original term - looking inside the packet
- Layering issues
- Firewalls are not doing full TCP/IP processing and so make mistakes because they peek at layer they do not understand
- For FTP, simplistic port lookup in the packet can be fooled into creating connections in the state table by faking 227 responses in the packet
- Spoofing from an internal trusted source
- Spoofing for a response
- Try to get hosts to respond to addresses you cannot reach otherwise
- Especially with source address 184.108.40.206 or 127.0.0.1
- Spoofing for a state entry - to get special entries added to the firewall state table for later use
- Spoofing from a network peer
- Spoofing destinations to create state table entries
- Source routing and encapsulation