Ok, one last message/
From: Alfred Huger (ah@securityfocus.com)Date: 02/12/02
- Previous message: Sam Bracke: "(no subject)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 12 Feb 2002 15:19:22 -0700 (MST) From: Alfred Huger <ah@securityfocus.com> To: pen-test@securityfocus.com
---------- 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/
- Previous message: Sam Bracke: "(no subject)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
