---------- Forwarded message ---------- Date: Tue, 12 Feb 2002 19:47:04 +0200 From: Sun <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Returned post for [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> > Date: > > Thu, 07 Feb 2002 15:06:57 +0200 > To: > > E <[EMAIL PROTECTED]> > > > 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/
