site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Microsoft-Entourage/11.1.0.040913
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.
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. 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. 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 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. If I knew there was no more data to come, I wouldn't want to hold the packet. Eric _______________________________________________ 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... This email sent to site_archiver@lists.apple.com
participants (1)
-
Eric Long