Finjan "SurfinGate"
Check out http://www.finjan.com and the stuff about "SurfinGate". The software supposedly can perform an on-the-fly inspection of a Java applet or ActiveX control, and then apply a signature to it along with a "safety" level qualifier to feed into a configurable policy mechanism. Any ideas as to how you can look at an ActiveX control and determine whether it's safe or not? -- ______c_________________________________________________________________ Mike M Nally * IBM % Tivoli * Austin TX * How quickly we forget that mailto:m5@tivoli.com mailto:m101@io.com * "deer processing" and "data http://www.io.com/~m101/ * processing" are different!
These thoughts are generic, and I haven't even looked at the surfgate web page. Does it access a file? winsock? hard coded memory addresses? Does it modify itself (Its code sections)? What system calls does it make? Are they all on the thought safe list? If it does not, then you have a first level analysis and can say that it might not be unsafe; you're a *LOT* better off than you were before. Trying to prove the code is safe is hard. Looking for obvious attacks (java that writes .rhosts, mails off /etc/passwd) is not very hard. It can lead to a false sense of security. Adam Mike McNally wrote: | Check out http://www.finjan.com and the stuff about "SurfinGate". The | software supposedly can perform an on-the-fly inspection of a Java | applet or ActiveX control, and then apply a signature to it along with | a "safety" level qualifier to feed into a configurable policy mechanism. | | Any ideas as to how you can look at an ActiveX control and determine | whether it's safe or not? | -- | ______c_________________________________________________________________ | Mike M Nally * IBM % Tivoli * Austin TX * How quickly we forget that | mailto:m5@tivoli.com mailto:m101@io.com * "deer processing" and "data | http://www.io.com/~m101/ * processing" are different! | -- "It is seldom that liberty of any kind is lost all at once." -Hume
Adam Shostack wrote:
Does it access a file? ...
Maybe I should have been more clear. It's certainly true that one could concoct software that looked for some tell-tale signs in Java applets or ActiveX controls (though it'd be a little tricker in the latter case, I suspect). What worries me is that this sort of tool might provide a false sense of security to corporate IS types (people who pay my company lots of money). (Oh, gee, I see now that the last line of your message was "It could lead to a false sense of security." Rare concensus on cypherpunks.) Anyway, there are lots of products like this (lots of virus scanners claim to defend against "all current and future viruses"), and they're not quite the same as sleazy snake-oil pseudo-crypto outfits. It worries me, if only as somebody with money in a bank that might be rendered vulnerable, that a tool like this might be installed under the illusion that an impenetrable wall has gone up around the network. Seems to me that putting together an ActiveX control that "sneaks" its way through the firewall risk policy wouldn't be hard. Unless the applet scanner actually simulates execution of the control under a variety of input conditions (and we know that's not likely) (but prove me wrong, please) there's not much it can do other than poke around and check what other DLL's the thing wants to access. It might be a bit harder to be sneaky in Java, but I certainly wouldn't bet I could look at an applet and guarantee its safety to any threshold (if I could, why not just do that in the browser?). Believing in the safety of precertified applets/controls is scary enough. Trusting yet another piece of software in the loop just seems a little wacky to me. (Oh, and in case Finjan is a Tivoli partner, or for all I know another IBM company, I'm not speaking for Tivoli.) -- ______c_________________________________________________________________ Mike M Nally * IBM % Tivoli * Austin TX * How quickly we forget that mailto:m5@tivoli.com mailto:m101@io.com * "deer processing" and "data http://www.io.com/~m101/ * processing" are different!
Mike McNally wrote: | Seems to me that putting together an ActiveX control that "sneaks" its | way through the firewall risk policy wouldn't be hard. Unless the | applet scanner actually simulates execution of the control under a | variety of input conditions (and we know that's not likely) (but prove | me wrong, please) there's not much it can do other than poke around and | check what other DLL's the thing wants to access. It might be a bit | harder to be sneaky in Java, but I certainly wouldn't bet I could look | at an applet and guarantee its safety to any threshold (if I could, why | not just do that in the browser?). Browsers are big, complex bits of technology. If you built an applet verifier that ran on a firewall, it could be substantially smaller than the 6mb of Netscape3.0 (SunOS). Smaller code is easier to verify, and less likely to contain bugs. In addition, you could be more confident that your policy goals are met in controlling what applets enter the perimiter that the firewall deliniates. Deploying new browsers to every desktop can be challenging. If you have a java-gw, there is a lesser need for new browsers everywhere in response to bugs. Also, you may be able to get the source to a verifier, but not to the browser. Doing a good job in real time would be very tough. We need signed capacity requirements, and an organization that will stand by its certifications of security. I have at least one client who would pay for certified ok applets. (Not certified origin, certified non-malicious, for various values of non-malicious). Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
participants (2)
-
Adam Shostack -
Mike McNally