site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Apr 27, 2006, at 10:14 AM, Eric Long wrote: If he's just monitoring data content, though, he should make a local copy for however big his buffer size is, and just let it through, unless he's trying to catch bad data before it gets in, and wants to check data spanning a buffer boundary, rather than just monitoring. But if the buffer that was swallowed doesn't itself contain the data you're trying to stop, then sending a partial buffer, and keeping a local copy in the kext for the spanning check, rather than swallowing it, is still an OK thing to do (assuming the data isn't malicious unless complete - and if it's malicious when incomplete, then the check should have matched already on the packet that was swallowed. This suggests that your "maliciousness" analysis could use some work. But if the socket closes and I don't get the data back into the stream before that, the transaction ends up incomplete and its my fault. I What sort of "match"? If I knew there was no more data to come, I wouldn't want to hold the packet. It sounds a lot to me like your basic analysis algorithm needs work. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... That's a bit broad of an assumption. The previous packet might have just a couple of bytes that match. It's hard to say how much data is quantitatively malicious if its sensitive data. I can thwart a transaction when I know I've matched a pattern I'm looking for, but if I don't hold packets, a partial data transfer might actually be detrimental. However, it also suggests that you are at least in part parsing a structured exchange between two parties. I'm scanning streams that other processes are conducting using an NKE socket filter. If I swallow a packet it is only intended to be temporary, until I can either get more data and determine to reinsert it based on the new data or arbitrarily set a timeout to reinsert it if no more data was received. I assume that there's more to it than this; if you decide to "thwart" the transaction you're not going to reinsert the packet. I think this is the part that's confusing us. Who is closing the socket? Are you talking about a remote close, or a local close? swallowed the packet only because I found a partial match at the end of its data holding out the possibility that more data was coming that might demonstrate a true match. Let me hazard a guess; you are trying to find specific data in email or HTTP transactions, perhaps as part of the "icSPYWARE & ANTI PHISHING" suite, using a naive string matching algorithm and attempting to avoid knowing anything about the framing of the data in these transactions. If you were to avail yourself of said framing information, or better still, do this at a level where the framing was implicit, none of this would be an issue. Information systems tend to be structured, and working within the structure is by definition easier than ignoring it. Frequently the answer to "why is X hard?" is "because you should not be doing X". This email sent to site_archiver@lists.apple.com