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