Bad handling of UDP sockets
opened this issue · comments
Hello,
I've been playing several days with sulley for fuzzing TFTP servers and I noticed a weird UDP communication behaviour badly handled by Sulley.
When making a TFTP request, a random source port is used for sending a packet to tftp port (69). For the answer, the TFTP server will not use the TFTP port but another random port. Example here :
01:45:40.774198 IP 10.1.1.1.44412 > 10.1.1.2.tftp: 18 RRQ "uname.txt" octet 01:45:40.776609 IP 10.1.1.2.38667 > 10.1.1.1.44412: UDP, length 80 01:45:40.776665 IP 10.1.1.1.44412 > 10.1.1.2.38667: UDP, length 4
While it is not documented (to my knowledge) when using socket.connect on an UDP communication, the next socket.recv will not receive the packet if the source port is different.
Thus using socket.sendto only for UDP seems to fix this problem.
Here is a small diff of modifications I made :
Index: sulley/sessions.py
===================================================================
--- sulley/sessions.py (revision 162)
+++ sulley/sessions.py (working copy)
@@ -436,7 +436,8 @@
try:
sock.settimeout(self.timeout)
- sock.connect((target.host, target.port))
+ if self.proto == socket.SOCK_STREAM:
+ sock.connect((target.host, target.port))
except Exception, e:
error_handler(e, "failed connecting on socket", target, sock)
continue
@@ -804,7 +805,10 @@
data = data[:MAX_UDP]
try:
- sock.send(data)
+ if self.proto == socket.SOCK_STREAM:
+ sock.send(data)
+ else:
+ sock.sendto(data,(self.targets[0].host, self.targets[0].port))
except Exception, inst:
self.log("Socket error, send: %s" % inst[1])
Thanks for the bug report, I'll clear this with @pedramamini, then merge your diff with master!
Good catch :)