Vulnerability could allow discover all honeypots if at least one has been identified already

[PherricOxide]

This needs more investigation and was discovered when I was running experiments an Honeyd 1.5c (with none of our changes). It's a bit complicated to explain, so I'll start with the setup that I had when I discovered it.

Machine1: 192.168.42.1  with /16 netmask
   sudo route add -net 172.16.0.0 netmask 255.255.255.0 gw 192.168.52.1 dev eth0

Machine2: Running honeyd with the configuration,
    Honeypot on 192.168.52.1 with MAC 5c:26:0a:a8:3a:75
    Honeypot on  172.16.0.42 with MAC a4:ba:db:7d:27:5e

Machine1 can now ping 172.16.0.42 (it shouldn't be able to). Furthermore, the TTL values are set such that it shows there were no hops inbetween, which would be the case if 192.168.52.1 was actually configured in honeyd as a router.

It goes something like this: the potentially hostile machine Machine1 configures itself to think that the already known honeypot 192.168.52.1 is a router (even though the honeyd config file has no routing commands being used). When the hostile machine tries to send a packet to 172.16.0.42, it resolves the MAC address of the gateway 192.168.52.1 and sends a packet destined to 172.16.0.42 with the dstmac set to the MAC of 192.168.52.1 (5c:26:0a:a8:3a:75). Honeyd sees a packet destined to one of it's honeypots and replies (reply with IP/MAC 172.16.0.42/a4:ba:db:7d:27:5e). If this was a real machine, the request would have never been seen and no reply would be sent.

The problem is that honeyd will respond to messages with dstip = honeypot and dstmac = ANY honeypot's IP. Once a single honeypot MAC address has been determined, an attacker could send ICMP ping messages with dstip equal to say 192.168.52.0-192.168.52.254. Honeypots will respond, real hosts will not (the packet's MAC address is that of a honeyd node afterall, they would never see it.)