tag:blogger.com,1999:blog-25010298.post8504252890839307771..comments2008-01-27T21:35:41.334-08:00skapenoreply@blogger.comBlogger9125tag:blogger.com,1999:blog-25010298.post-69812151088373314982007-11-07T12:21:00.000-08:002007-11-07T12:21:00.000-08:00Using a receive loop is definitely an option if you can manage the extra size overhead (which I agree is fairly small). The out-of-order packets was meant to be more of an illustration of another way of going about it that wouldn't impact size :) Metasploit's current solution fixes the problem without adding any size overhead or the need for a receive loop (the intermediate stager).skapehttp://www.blogger.com/profile/16314095165651222279noreply@blogger.comtag:blogger.com,1999:blog-25010298.post-75128629605577057662007-11-07T08:16:00.000-08:002007-11-07T08:16:00.000-08:00It's not that much of an increase in size... ;(Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-25010298.post-9912783914442075002007-11-07T08:12:00.000-08:002007-11-07T08:12:00.000-08:00If you want to receive n bytes, then what's the problem of using recv() until you've received the n bytes...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-25010298.post-51841457710118333452007-11-06T00:54:00.000-08:002007-11-06T00:54:00.000-08:00Very interesting research!<BR/>Good job<BR/><BR/>/JAAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-25010298.post-46482288070792260892007-11-03T12:05:00.000-07:002007-11-03T12:05:00.000-07:00MSG_WAITALL is definitely an option on the POSIX side of the house. Unfortunately, Windows doesn't support MSG_WAITALL (last I checked).skapehttp://www.blogger.com/profile/16314095165651222279noreply@blogger.comtag:blogger.com,1999:blog-25010298.post-36281911180841431202007-11-03T10:52:00.000-07:002007-11-03T10:52:00.000-07:00Did you think about using the MSG_WAITALL flag for recv(2)? Seems to be the most obvious way to me.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-25010298.post-53519885105418595472007-11-03T10:41:00.000-07:002007-11-03T10:41:00.000-07:00Did you think about using the recv(2) flag MSG_WAITALL? Seems to be the most obvious way to me.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-25010298.post-42533235455307023982007-10-25T11:59:00.000-07:002007-10-25T11:59:00.000-07:00Yeah, I'd definitely agree that out or order packets are likely rare, though I don't have strong figures to prove this. An aggressive IDS could definitely signature on this behavior as potentially bad. Transmitting data as part of the initial SYN falls into a similar category -- it's valid, but uncommon. Still, it's definitely an option :)skapehttp://www.blogger.com/profile/16314095165651222279noreply@blogger.comtag:blogger.com,1999:blog-25010298.post-35714341066446092852007-10-25T10:55:00.000-07:002007-10-25T10:55:00.000-07:00Nice article Matt!<BR/><BR/>A couple of comments and then some ideas to possibly look into. <BR/><BR/>First, I'm surprised at how few out-of-order packets one really sees at their perimeter. Note that if you trace across multiple peered ASes then you will definitely see asymmetric routing (as you would expect)... but still seldom do you actually get packets out of order even in these cases. One might ascribe this to the over provisioning that has occurred over the last several years. Of course one will see even fewer out of order packets transmitted internally on ones networks.<BR/><BR/>So my comment is that while the non-loop read is a known issue and as we are concerned about any increase in payload size, it would seem this solution would not only fail in the cases you mention (statefull devices reassembling and reordering packets within streams), it would seem to be overly noisy to passive monitoring tactics (e.g. IDS and other monitors). <BR/><BR/>Have you thought about placing some of the data within the initial SYN packet (this is not disallowed in rfc 793) and it seems some stacks handle this just fine. It should not make it to the recv() function until the three way handshake has been completed at which point the data from the mbufs will have been handed over (including the data put in the initial SYN). In essence you would be using the kernel to buffer this first amount of data for you and combine it with the data in the first PSH packet after the 3-way. Thus getting the data portion of two packets in the first userland read.<BR/><BR/>Of course, there's the chance that after moving to connected state that recv is handed the initial data and your 1 shot read returns early after the SYN w/ data and prior to the first normal data packet, but it's worth a shot checking out which stacks handle this in which ways.<BR/><BR/>Then there's T/TCP and rfc 1644 (which is normally enabled or disabled through setting a sysctl kernel state). SYN with data is nothing new here and perhaps enabling net.inet.tcp.rfc1644 would be enough to have the first two packets (syn w/ data being pkt #1 and ack|psh w/ data #2) be buffered into your single read.<BR/><BR/>These other options will appear nonstandard to monitoring devices as well, but they might make it through statefull filtering ;)<BR/><BR/>Hey, you asked for ideas so I decided to ramble a bit. Keep up the great work!<BR/><BR/>cheers,<BR/><BR/>.mudgeAnonymousnoreply@blogger.com