Penetration Testing mailing list archives

Ok, one last message/


From: Alfred Huger <ah () securityfocus com>
Date: Tue, 12 Feb 2002 15:19:22 -0700 (MST)


---------- Forwarded message ----------
Date: Tue, 12 Feb 2002 19:47:04 +0200
From: Sun <pentest () sun consumer org il>
To: pen-test-owner () securityfocus com, ah () securityfocus com
Subject: Re: Returned post for pen-test () securityfocus com

  While I realize that you said this thread was dead, I am still
wondering what was the reason this post was not approved. If you find
that this has new angles on the matter, I will appretiate it if it would
be approved despite announcing the thread as dead.

Thanks,

Sun



Subject:

Re: Political Analysis of Security Products
From:

sun <pentest () sun consumer org il>
Date:

Thu, 07 Feb 2002 15:06:57 +0200
To:

E <j46 () btinternet com>


First - a disclaimer. I am a check point employee. Despite that fact,
the views presented here are my own, and do not represent anyone
else's, either individual or company. Last, I have opted for a
semi-anonymous way of posting this to emphesize the disclaimers given
above. I also have a @checkpoint email address.

E wrote:

It has occured to me that a much more insidious way to backdoor high
profile
software is to intentionally write remotely exploitable bugs into the
code.

...

The only problem with this idea is that a company who produces
commercial
security software does NOT want to have bugs discovered in its code,
it is
against its interest, because a remote security flaw doesnt do much
for their
reputation. On the other hand,when you have a big company whos software
regularly has security issues, these become the norm and noone questions
it when a new one appears.

This is a totally mute point in this context. When you evaluate a
security product (or indeed, any product) for usefulness, one of the
things you take into consideration is "how often does it appear on
BugTraq". Whether those bugs were random acts of negligance, or
deliberate acts of trojan is meaningless, if only because they are
indistinguishable as far as your'e concerned. This means that, in a
perfect world, a security company would have to either give up the
idea of backdooring their products, or release a product that is less
secure to begin with, thus risking not only losing money, but also not
having enough clients to have the back door mean anything. After all,
a back door is meaningless unless people (victims) are using your
product.


Frankly, you just cant trust closed source security products. This is
like
asking someone to install a home-made alarm in your house, without
knowing if
they
are a convicted thief...Its a question of trust, and if you dont
trust it, dont
use it.

I don't know. Did you perform a code audit of IPChains? IPTables? IP
Filter? The OpenBSD kernel? If you didn't, how can you tell whether
they are trojaned?

The reason you can tell is because you know that had there been
trojans there, someone would have told you about it by now. Thing is,
closed source products are being audited as well. Auditing process may
be a little more complicated, but the very fact that buffer overruns,
format strings, and other problems have been found in all sorts of
closed source security products, as well as licensing borken, means
that rev-enging a closed source product is not beyond the capability
of the community at large.

The net result is that you can trust a product to not have hidden
"features" (and by those I also mean buffer overruns, whether
intentional or accidental) the more the product is USED, because that
more or less guarentees that someone had a swip at it. The more used,
the more people.

One last note - I don't like the tone behind this thread. It seems
that most people here tend to ASSUME that FW-1 has a backdoor, and are
just looking for "how it's done". While I am far from objective, I
would suggest that suspecting a product that is software only, and
available in a software package for installment over a 100% standard
OS, and a multi-platform product at that (Check Point FW-1), makes
much less sense then suspecting a product that is an entire platform
rolled into one, which gets updates to the OS and the software at the
same service pack, and which runs on non-standard platforms (each and
every one of Check Point's competitors). The only reason I can see for
this is the paranoid assumption that, since it was manufactured in
Israel, the Mossad must have had something to do with it.

I was especially amused by the comparisson to Vaanunu, who was a
nuclear plant EMPLOYEE who went out and revealed things that were
classified as state secrets, given to him under confidance.

Just in case anyone didn't understand this from my previous comments,
I'll just make it clear that I have never ran across any code that
delibiratly left a back door in the product, never saw Mosad agents
walking in the corridors, and I know of no party outside of Check
Point that has made changes to our code. The reason this came at the
end is because you cannot trust me, I have, after all, identified
myself as a Check Point employee.

-Sun





----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/


Current thread: